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

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:] 

Sent: Wednesday, July 05, 2006
10:23 AM

To: 

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