(disclaimer: This landed in my inbox on the gen-art list, so I'm responding from that perspective. I was _not_ involved in the review. I haven't followed the draft, so my comments may be completely off-base due to lack of context.)
On May 7, 2014, at 10:55 AM, Dale R. Worley <[email protected]> wrote: > [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. It may not be "absolutely" testable, but one can do some degree of testing by supplying weird URLs and seeing what happens. If people have a sense of "a large number of actions that 'everybody' would agree are violations", can the language be recast in terms of those actions? > > 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 If an implementation does things "unreasonable in the eyes of the user" when receiving a perfectly valid URL, is that not an interop problem? > > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
