On 2010-02-06 13:19, Bob Hinden wrote:
> Doug,
>
> On Feb 5, 2010, at 3:59 PM, Doug Barton wrote:
>
>> On 2/5/2010 2:37 PM, Brian E Carpenter wrote:
>>> Oh, OK, that is fine for conformance of course, but leaves things
>>> open when you are talking about generating strings. If we want the
>>> new recommendation to be a MUST, we may have to consider wording to
>>> make it clear how widely it applies. Many existing specs may be
>>> affected implicitly.
>> Would something like this work?
>>
>> In the absence of a conflicting specification, ... MUST ... At the time
>> of this writing the following specifications are known to conflict: <list>
>
> That's essentially the definition of SHOULD. It's what you do unless there
> is a compelling reason not to do it.
[Digression: a sad fact of life is that this is what MUST means
in practice. And SHOULD means "product managers who are short
of programmers MAY leave this out".]
I was rather thinking that we have to say MUST (as the IESG
wishes) and then add something like:
The following specifications, among others, are affected by
this requirement: RFC 3986, ...
I think this will demonstrate the scope of this change from
SHOULD to MUST.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
