RE: [ws-rx] i140 - Add new sub-headings to each fault described insectio

Doug,

It is probably needs not very much change; more of a reorganization really.

Since the state tables are non-normative, all normative behavior ought to be contained in the normative text. I am beginning to think that the main objection I have is that the description of fault origins and behavior are divided between the fault section and Section 3. I would prefer that faults be discussed in one place or the other. For example, the implications of the Sequence Closed fault is described redundantly in Section 3 and Section 4 whereas Invalid Acknowledgement is described only in Section 4 with only an admonishment in Section 3 that ack ranges SHOULD not overlap,

If Section 4 contained only the description of fault detail elements and the faults were all completely described elsewhere I would be happy, but there are faults described only in Section 4 which actually do not seem to fit well into the “document” oriented Section 3.

It would be far preferable IMO to describe the fault completely in Section 4 and in Section 3 to mention merely that a fault be generated and to point to Section 4 for the description.

If there are cases where there are “too many variables” to describe the meaning of a fault to endpoint then I have deeper concerns.

Thanks

-bob

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006 10:23 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i140 - Add new sub-headings to each fault described in section 4.

Bob,
I was looking at this issue again and I'm not very comfortable with the idea of this. I think I understand your goal (trying to make sure everything in the state table has a clear line of text in the spec that it derived its info from), but this issue seems to try to replicate it - just in the inverse direction. By adding headings like "Generated By" or "Action upon generation" it feels like we're just duplicating what the state table already has, just in normative text - something which should already be there since we were able to put something in the state table to begin with. And, I wonder whether we can really be any more prescriptive than we already are? Take, as an example, the receipt of a Message Number Rollover Fault (something you already have an issue for) - I don't know what we could say for the action upon receipt or generation of this fault. There are just too many variables involved in what an endpoint may choose to do with each possible fault. Some may be very obvious, and in those cases I think the text is already very clear what should happen - do we really need this?

thanks,
-Doug

ws-rx message