RE: Protocol: control specifications.

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
> >>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 3/9/04 1:03:48 PM
> >Jim Sermersheim writes:
> >> 
> >> 1) the old text can be read to imply that the control spec can mandate
> >> the criticality, and the server should validate the criticality
> >
> >Not quite. I thought - and still think - this meant a wrong criticality
> >is an error, so server MAY validate it, and thus a good quality server
> >would do so. I asked for a SHOULD, but have lost that argument.
> 
> (...)
> 
> >(1) as in "MAY" - the arguments against the "SHOULD" seem to have become
> >the reason for even removing the "MAY". I've argued against that, but
> >the change happened without response to my arguments, except some
> >misunderstandings about why I thought it said that.
> 
> I would just add that a MAY will cause differing implementations, and
> it would seem better in this scenario to have consistent implementations
> and lose the benefit of having the server validate.

I don't see that.  The only difference is that some servers will catch
more client errors than other servers.  Which is true anyway.

> Also, adding the MAY
> will cause rewrites of other text (Regardless of the value of the
> criticality field, if the server recognizes the control type and it is
> appropriate for the operation, the server is to make use of the control
> when performing the operation.)

Well, rewriting the draft is what we are discussing in this forum.
s/when performing/if it performs/, I guess.

>>> (2) in my mind is still allowed by the new text.
>>
>> It can be read that way, but "direction" can also be seen as saying the
>> spec may recommend a criticality, but that it does not say anything
>> about allowing the spec to mandate a criticality. So I've asked
>> for a clarification.
> 
> Does it help to explicitly state that a spec can mandate criticality?

Yes.

> If so, we can add it, but I worry about getting too far into the realm
> of writing a 'specification for control specifications' (as if we're not
> already too far into that realm already). Frankly, I feel that the
> community's experience in writing control specifications is still very
> limited, so I hesitate to add anything here that's not very general in
> nature.

The current text is:

   - direction as to what value the sender should provide for the 
     criticality field (note: the semantics of the criticality field 
     are defined above should not be altered by the control's 
     specification),  

Would s/direction/direction or requirements/ be OK?

-- 
Hallvard