Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stewart Bryant <stbryant@xxxxxxxxx> writes:

> Indeed an interesting additional question.

> My view is that you MUST NOT use RFC2119 language, unless you MUST use 
> it, for exactly that reason. What is important is "on the wire" (a term 
> that from experience is very difficult to define) inter-operation, and 
> implementers need to be free to achieve that though any means that suits 
> them.

The latter goes without saying. It's one of the "obvious" assumptions
that underlies all IETF protocols. It may not be written down, but its
always been an underlying principle.

E.g., from RFC 1971:

   A host maintains a number of data structures and flags related to
   autoconfiguration. In the following, we present conceptual variables
   and show how they are used to perform autoconfiguration. The specific
   variables are used for demonstration purposes only, and an
   implementation is not required to have them, so long as its external
   behavior is consistent with that described in this document.

Other document (that I've long forgotten) say similar things.   

That sort of language was put into specific documents specifically
because some individuals sometimes would raise the concern that a spec
was trying to "restrict" an implementation.
   
IETF specs have always been about describing external behavior
(i.e. what you can see "on the wire"), and how someone implements
internally to produce the required external behavior is none of the
IETF's business (and never has been).

(Someone earlier on this thread seemed to maybe think the above is not
a given, but it really always has been.)

Thomas



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]