Misuse of MUST/SHOULD/etc in spec

[GoogleCodeExporter]

SUMMARY:

The spec says in its opening that it uses the keywords "MUST", "SHOULD", "MAY", 
etc as defined 
in RFC2616. The keywords have definitions very specific to interoperability, 
and differ 
significantly from the standard English meanings of the words. However in 
various places in the 
spec these keywords are used to have their standard meaning.

RELEVANT SECTION:  

An example:
re: hub.lease_seconds: "Hubs SHOULD make this equal to whatever the subscriber 
passed in their 
subscription request but MAY change the value depending on the hub's policies."

COMMENT/REQUEST:

Under RFC2616, "MAY" means the choice is entirely up to the client with no ill 
effect either way. 
"SHOULD" means there's a chance things will break if the rule is not followed. 
So the first part of 
the above example is saying "Supply the same value unless you're happy to break 
some 
subscriber implementations" while the second part is saying "supply whatever 
value you fancy". 
I'm not sure which is the intention, but the spec needs to pick one keyword and 
one keyword only 
for this sentence.

And as I say, this is only one example. The author(s) need to go through each 
sentence 
containing one of these keywords and double check it makes sense when read in 
the context of 
the RFC2616 definition.

Original issue reported on code.google.com by graham.p...@utsire.com on 9 Aug 2009 at 3:07

[GoogleCodeExporter]

(sorry - I mean RFC2119. Too many tabs open)

Original comment by graham.p...@utsire.com on 9 Aug 2009 at 3:08

[GoogleCodeExporter]

If you have any more concrete examples of this mistake from the spec, I'd 
appreciate
you pointing them out. It's hard to go through with a fine-tooth comb alone. 
Thanks!

Original comment by bslatkin on 27 Aug 2009 at 3:14

• Changed state: Accepted
• Added labels: spec0.2

[GoogleCodeExporter]

All of them. Every single time you use one of these keywords they're at least 
one or two notches too high. 

Get an editor. A proper editor who has written IETF specs before.

I can't help you if you're not interested in reading your own spec.

Original comment by graham.p...@utsire.com on 29 Aug 2009 at 11:43

[GoogleCodeExporter]

Original comment by bslatkin on 30 Aug 2009 at 7:46

• Changed state: WontFix

[GoogleCodeExporter]

Addressed in 0.2

Original comment by bslatkin on 2 Sep 2009 at 1:21

• Changed state: Fixed