Subject: Re: clarifications (Was: protocol-27 comments#2)

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 13:05:54 -0700

I have either swapped out 'clarified' for 'specified' or 'disambiguated'
(as applicable), or left it where it mades sense, and added supporting
text to sentences containing 'clarified' which seemed to need it.
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/29/04 7:26:13 PM >>>
At 10:09 AM 10/29/2004, Hallvard B Furuseth wrote:
>What is a "clarification"?

A clarification can be regarded as a change which makes clear
which of the many possible (reasonable) interpretations of the
original specification is the proper interpretation. That is,
a clarification can be regarded as removing some ambiguity found
in the previous specification. This is how I used the term in
[Models]. There can, of course, be disagreement as to whether
an interpretation of the original specification is reasonable
or not, hence to whether the use of the term clarification is
appropriate or not.

Anyways, if we were to apply this definition to say:
Clarified that the messageID of requests MUST be non-zero.

I would have to agree that addition of this MUST was not a
clarification but a substantive change. Hence, I would
rather this be worded:
Added a requirement that the messageID of requests be non-zero.

And it might be appropriate to say why the change was made:
Added an requirement that the messageID of requests be non-zero
to ensure clients can distinguish unsolicited notifications
from solicited responses.

Kurt

>I thought it meant it is not intended to
>change what the spec means, but it is used differently several places
>here. I remember Kurt insisted that something was a clarification
while
>I insisted it was a change some time ago, too. E.g. at least these
look
>like changes to me:
>
>> C.1 Changes made to RFC 2251: 
>> C.1.3 Section 4 
>> - Clarified where the extensibility features of ASN.1 apply to the 
>> protocol. This change also affected various ASN.1 types. 
>> C.1.4 Section 4.1.1 
>> - There was a mandatory requirement for the server to return a 
>> Notice of Disconnection and drop the connection when a PDU is 
>> malformed in a certain way. This has been clarified such that the 
>> server SHOULD return the Notice of Disconnection, and MUST drop 
>> the connection. 
>> C.1.5 Section 4.1.1.1 
>> - Clarified that the messageID of requests MUST be non-zero. 
>> - Clarified when it is and isn't appropriate to return an already 
>> used message id. RFC 2251 accidentally imposed synchronous server 
>> behavior in its wording of this.