|
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" <Kurt@OpenLDAP.org> 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. |