protocol-15

[Vint Cerf]

Andrew,

I think we intended that our definition of A-label excluded presence  
of upper case ASCII.
So the presence of such characters makes the object NOT an A-label.

an A-label is a subset of allowed DNS labels (see Non-Reserved LDH- 
labels).
The labels with the xn--prefix but which contain upper case ASCII  
where the
punycode representation of the U-label appears are not A-labels by  
definition.

any clarification we can manage on this point will likely be helpful.

v

On Sep 3, 2009, at 11:41 AM, Andrew Sullivan wrote:

> Dear colleagues,
>
> I have reviewed the changes in draft-ietf-idnabis-protocol-15.  I
> think we have closed the gap about which we were worried, but I want
> to confirm we've got it quite right.
>
> Protocol-15 does not actually forbid the registration of A-labels
> containing upper case ASCII characters.  Section 4.1 says that
> registries sSHOULD accept registrations onlt for A-labels (with maybe
> some related U-labels).  Section 4.2.1 is a little more encouraging of
> accepting the U-label form as well, but still regards the A-label form
> as primary.  However, it only requires the downcasing of the A-label
> form in case both forms are available; otherwise, if the A-label form
> is accepted at all it is apparently accepted as provided.
>
> Protocol-15 does not actually forbid the lookup of A-labels containing
> upper case ASCII characters.  Section 5.3 says that if the input
> starts with xn--, then the application MAY do some conversion
> (although it now specifies that the conversion should start by
> downcasing the entire A-label).  The document is entirely silent on
> what an application does with an A-label in case it does not convert
> the label to a U-label for validation, &c.
>
> As John suggested in the discussion leading up to this, I think the
> above is correct: A-labels are, in one sense, just plain DNS names,
> and I am pretty sure we don't want to be making changes to the rules
> about what may be entered or looked up in the DNS in every case.
> Nevertheless, since this is what people were worried about, I want to
> draw attention to it.
>
> Given the results of the previous discussion, I'm still fairly certain
> that the existing definitions prohibit A-labels that have any upper
> case letter in them.  But I concede that this depends on certain
> non-obvious premises, and therefore an implementer who really wanted
> to get upper case ASCII into an apparent A-label would have an
> argument that they were conforming with the protocol as it stands.  I
> therefore think it would be nice to add a sentence to Defs that
> reminds the reader that A-labels turn out always to be lower case,
> (maybe it ought to go in Rationale instead).  My suggestion is
> something like the following: "A consequence of the restrictions on
> valid characters in U-labels turns out to be that mixed-case
> annotation, of the sort outlined in [RFC3492] Appendix A, is never
> useful.  Therefore, since a valid A-label is the result of Punycode
> encoding of a U-label, A-labels always happen to be only lower case,
> despite matching other (mixed- or upper-case) potential labels in the
> DNS."
>
> In any case, I think the changes made to Protocol are all that are
> needed for the purposes of addressing the issue of upper case in the
> A-label.
>
> Best regards,
>
> A
>
> -- 
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update