Stop me if I've misunderstood...

Paul Hoffman phoffman at imc.org
Sat Jul 11 00:55:59 CEST 2009


At 3:02 PM -0700 7/10/09, Kenneth Whistler wrote:
> > At 7:02 PM +0000 7/10/09, Shawn Steele wrote:
>>> I agree with Mark that browsers MUST map, otherwise you have chaos,
>>> however I'm not sure I want to say "X, Y & Z" must map and "A, B & C"
>>> must not map.  I think saying that some applications SHOULD map
>>> is sufficient.
>
>and Paul Hoffman responded:
> 
>> Stop right there. Read the definition of "SHOULD" in RFC 2119.
>
>O.k.:
>
>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.
>
>> Come up with a proposed sentence (not idea) that expresses what
>> you want that meets the RFC 2119 rules.
>
>There may exist valid reasons in particular circumstances for
>some applications to not casefold domain names, but the full
>implications of not casefolding must be understood (i.e., that
>there may be other strings, with different casing of letters,
>which if casefolded, would resolve to the same DNS record)
>and carefully weighed before choosing not to casefold.
>
>The browser implementers seem to be saying (and I agree) that
>they would always casefold, but if we define casefolding as
>a SHOULD for the protocol, as I read RFC 2119, that would
>not then be a MUST (i.e. an absolute requirement of the
>specification).

What I am asking for is the text that would, for every SHOULD that is desired, explains the full implications that implementers need to understand.

Further, I don't think that we're talking about casefolding, but all the mapping. Casefolding is far simpler to explain the implications of than, say NFC or the characters that differ between IDNA2003 and IDNA2008.

>I don't see "MAY" as at all easy in the context of discussing
>what to do for IDNA 2008, because:
>
>5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>   truly optional. ... An implementation which does not include a
>   particular option MUST be prepared to interoperate with another
>   implementation which does include the option, though perhaps
>   with reduced functionality....
>  
>And what Mark and Shawn and Gervase seem to be saying, at least
>as I understand it, is that if you do not require casefolding
>(and the other kinds of mapping needed for at least minimal
>backwards compatibility with IDNA 2003), then you simply do
>not have interoperability. You have different browsers resolving
>to different locations, based on optional choices and levels
>of IDNA library support, among other things. And if you
>can't guarantee interoperability of implementations (though
>perhaps with reduced functionality), then you cannot make
>such an element an OPTIONAL part of the specification.

Ah, there we go. The definition of MAY is easy, it is just not what they want. I fully agree there.

>I just don't see any way that we can have casefolding (at
>least) be a "MAY", and end up with a coherent, usable
>protocol that will actually be implemented and used.

It would be implemented and used; the result would definitely not be coherent. Having said that, I also believe that it would not be coherent with "SHOULD" either.


More information about the Idna-update mailing list