> you're not the first person to be confused by that construct. i will change instances of > "MUST ONLY" to "is allowed only if" (or similar) and remove the definition for "MUST > ONLY" from Section 1.2. I think this is an excellent idea. RFC 6919 aside (ahem), it's rarely a good idea to try to define new 2119-ish key words. Speaking of which (my comments after a bunch of quotes)... >> -- section 3.2: "Multiple endpoints SHOULD NOT have the same identity." >> >> Why not MUST? Will things not break if two endpoints do have the same identity? > > this should be "It is RECOMMENDED that multiple endpoints not have the same > identity." if two endpoints have the same identity, then they will be indistinguishable. > this will not break RTMFP, but might confuse an application. that being said, there > could potentially be reasons to have different endpoints with indistinguishable identities > and that potential should not be normatively prohibited. ... >> -- "A test SHOULD comprise testing whether the certificates are identical." >> >> What if it doesn't? > > again, that SHOULD should be reworded to RECOMMENDED. ... >> -- 3.5.1.1.1, 3rd paragraph: >> >> What are the consequences of having a tag with less than 8 bytes of length? >> Is the SHOULD reasonable here? > > both of those SHOULDs should be RECOMMENDEDs. ... >> -- 3.6.2.3.2, 2nd paragraph: "...an implementation SHOULD encode a Next >> User Data chunk instead of a User Data chunk" >> >> I'm not sure why this needs to be normative, as I assume its just normal >> behavior. But if it does need to be normative, why not a MUST? Can the far >> endpoint reasonably handle things if the SHOULD is violated? > > this should be a RECOMMENDED. the far end will work just fine if Next User > Data is never used. In RFC 2119, "SHOULD" and "RECOMMENDED" are synonymous (they're just covering different parts of speech; they fit differently into sentences). Changing "SHOULD" to "RECOMMENDED" (and, of course, rewording the sentences accordingly) doesn't affect Ben's comments on the points. "MUST" means that the protocol will not work properly unless you do this. You just have to, without fail. "SHOULD" (and "RECOMMENDED") is really only a *little* lighter: it still means that the protocol requires that you do this, but that there might be good reasons not to -- you have to fully understand what will happen if you don't do this before you can consider not doing it. To my mind (and I consider this when I do IESG Evaluation on documents with SHOULD), whenever a document uses SHOULD (or RECOMMENDED) it needs to (one might say "SHOULD") make it very clear what will happen if you don't do this, so that implementors can have that necessary understanding. Perhaps the protocol will fail in some unusual situations. Perhaps it will break compatibility with older clients. Perhaps it will still work, but will adversely affect performance. But without an explanation, there's no way for implementors to meet the terms in RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. If something is simply a suggested value or response, the text should say it that way. If it's a suggestion that really is a best-practice recommendation that comes from a lot of experience with the protocol, the text should say that, without the 2119 key words. For the first item, in Section 3.2, for example, you say: > this should be "It is RECOMMENDED that multiple endpoints not have the same > identity." if two endpoints have the same identity, then they will be indistinguishable. > this will not break RTMFP, but might confuse an application. that being said, there > could potentially be reasons to have different endpoints with indistinguishable identities > and that potential should not be normatively prohibited. That might well be a valid "SHOULD". Don't change it to "RECOMMENDED" (or do, if you like), but put in the explanation that you have here. It would be especially helpful if you can also include an example of a reason, and/or say something about the consequences of the confusion it will cause. For the cases of 3.5.1.1.1 and 3.6.2.3.2, it seems that you don't want 2119 key words there at all: these look like recommendations (not in the 2119 sense) that are based on what's been deployed already, and it would simply be good to make that clear: "implementation experience suggests [x]". Barry