- From: Barry Leiba <barryleiba@computer.org>
- Date: Wed, 30 Oct 2013 11:04:05 -0400
- To: Richard Barnes <rlb@ipv.sx>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Stephen Kent <kent@bbn.com>, secdir <secdir@ietf.org>, "fielding@gbiv.com" <fielding@gbiv.com>, "mnot@pobox.com" <mnot@pobox.com>, Pete Resnick <presnick@qti.qualcomm.com>, "Mankin, Allison" <amankin@verisign.com>, HTTP Working Group <ietf-http-wg@w3.org>
>>> Why do you feel the need to avoid SHOULD and MAY here? They don't place >>> any more burden on implementors than "ought" and "might". >>> --Richard >> >> I believe in following the guidance in RFC 2119: > > The key word there, though, is "imperatives". Nothing we're talking about > here is an imperative, just a recommendation (or RECOMMENDATION). Skimming > through the instances of "ought to" in the document, it seems like they all > meet the definition of "SHOULD" in 2119, i.e., things that implementations > should only diverge from if they have a good reason. (In fact, there are > some that seem like they should be "MUST", but that's a different topic.) First: I think it's a good idea, in a document that defines protocol, to separate the requirements for the protocol from the recommendations for implementation aspects that speak to quality of implementation and user experience, but that don't affect protocol operation (and interoperation). Second, because the use of "should", "must", "may", and "recommended" in lower case is controversial (for reasons that I don't agree with, but never-you-mind that), I think using alternatives (as, for example, proposed here, which was not intended for 1 April publication: http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119 ) is a fine thing. Third, these situations in the httpbis documents *are* things that don't affect the protocol. How should a browser treat [whatever]? Well, a browser that makes bad choices could be considered a crummy browser, so giving advice is good and useful. But the server won't know nor care, so this isn't a protocol issue. I don't think, therefore, that in a protocol document we should use 2119 language for that. Save the 2119 language for the protocol. Fourth, this is starting to get into nitty wordsmithing (the part about whether "ought" is a good word... not the part about whether it's normative or not), which I don't think is really appropriate at this stage of document development. That is, it's fine to bring it up editorial things for the editors to consider, but pushing on them at the expense of time spent on substantive issues doesn't seem wise at this stage. Barry
Received on Wednesday, 30 October 2013 15:04:36 UTC