State that transfer codings should not use parameters named "q" (closes #15)

[reschke]

No description provided.

[royfielding]

That needs some tweaks ... the action words like SHOULD are supposed to be targeted to implementation roles, not protocol extensions. Can we just copy the same Note from the Accept section?

[reschke]

I can avoid the SHOULD NOT.

I used different text because for transfer codings "we" actually own the registry, while for content types we do not...

[royfielding]

Heh, I think it's a stretch of the imagination to think that we control the registry even when we define it ... people still deploy first and register later. In any case, a simple

If possible, avoid defining transfer codings with parameters; if you have no choice, don't use "q" as a parameter name because it will be confused with the quality ranking parameter of that name.

should be sufficient.

[reschke]

I actually reverse my opinion about the SHOULD NOT - we already use BCP14 keywords in the paragraphs before and after this one. So please consider again the pull request.

[mnot]

My .02 - acknowledging that 2119 keywords are only intended for implementations roles, I don't think that throwing up our hands and saying "people will do what they will" is productive.

While some people ignore (or just don't read) the RFCs, many do, and when they do, we owe it to them to communicate in the clearest, concise way possible. 2119 keywords are a fantastic tool for doing that.

[reschke]

@mnot - so are you ok with this change?

[mnot]

I am - although if we come up with a unified way to deal with requirements consistently across the documents, it might change.