[as an author] > From: "DRAGE, Keith (Keith)" <[email protected]> > > > > 13. User Agent Behaviour > > > > > > The User Agent (UA) MUST produce a reasonable rendering > > > regardless of the combination of URIs (of any schemes) in the > > > Alert-Info header field. > > > > > > This MUST is not well defined to be implementable. How can > > > conformance or violation of this requirement can be tested? I > > > suggest you avoid using RFC 2119 language here. > > > > The authors agree and will change the MUST to "must". > > Can we avoid lower case forms of RFC 2119 language as this just > leaves the reader with the question as to whether there was an > editing error. > > I would suggest "The User Agent (UA) is expected to produce..."
It's a tricky matter. What we really want is MUST, that this is a constraint on the UA, particularly that it must be prepared to cope with any sequence of syntactically-correct URIs, and it must do something that is reasonable in the eyes of the user. The problem is that this criterion isn't testable in any absolute way, despite the fact that there are a large number of actions that "everybody" would agree are violations. So the Gen-Art reviewer didn't like "MUST". Unfortunately, he didn't suggest an alternative. As far as I can tell, "must" is fairly common in RFCs. Over half the RFCs from 6000 to 6999 use "must" (outside of boilerplate language). Many of them use it in a more-or-less normative way. RFC 2119 gives this guidance, for what it's worth: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for At this time, I prefer "must" over "MUST", but I prefer "MUST" over "is expected to" or anything that is similarly indirect. Dale _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
