comments on the document set

[John C Klensin]

Again, usual disclaimers -- things that have been changed are
reflected in the documents and Change Logs; this note comments
only on things that have not been changed or that seem to
require comments and does not address Tables (or Bidi).

--On Monday, October 19, 2009 11:26 -0600 Peter Saint-Andre
<stpeter at stpeter.im> wrote:

>...
> RATIONALE
> 
> 1.3.2.
> 
> The term "IDNA-landr" is used here but undefined.

Stupid cut and paste error.  My apologies.  Fixed.

>...
> 6.
> 
> This text is a bit of a teaser:
> 
>    While there are strong arguments for any
>    domain name that is placed "on the wire" -- transmitted
> between    systems -- to be in the zero-ambiguity forms of
> A-labels, it is    inevitable that programs that process
> domain names will encounter    U-labels or variant forms.
> 
> At the least, it would be helpful to either spell out those
> "strong arguments" or provide a pointer to a document that
> makes those arguments. And does this apply only to DNS
> applications (e.g., registration and lookup in the DNS itself)
> or also to applications that use IDNA (e.g., email, XMPP,
> IRIs)?

I don't know quite what to do with this and so left it alone.
The "strong arguments" are tied to the potential ambiguities
comment.  Even U-labels, while unambiguous when one has them as
machine-readable Unicode strings, are subject to transcription
issues when one sees them on the side of the proverbial bus and,
potentially, to transcoding problems if they are in
machine-readable form in a non-Unicode character set.  But I
fear that trying to say anything much more specific will get us
into a state in which no specific statement can achieve WG
consensus.

>...
> 14.1.
> 
> Is RFC 3490 truly a normative reference?

Well, this is an Informational document, so "normative" doesn't
mean "required to implement".  But one clearly has to understand
3490 to understand some of the comments about IDNA2003 in the
Rationale spec, so I think so.  The RFC Editor may well have a
different opinion (or may remind us that they have been
questioning, for some years, whether the Normative/Informative
distinction is really useful in Informational documents.

> DEFS
> 
> 2.3.1.
> 
> It's not clear here whose responsibility it is to determine
> that a "Fake A-Label" is truly fake.

Nor should it necessarily be.  "Fake A-Label" is a definitional
artifact; all references to the term in Protocol have been
eliminated.

> 2.3.2.1.
> This is a bit unclear:
> 
>    U-labels can appear, along with the other two, in
>    presentation and user interface forms and in selected
> protocols other    than those of the DNS itself.
> 
> It might be clearer if this text specified what those selected
> protocols are, or how such protocols might be selected.

Same problem as in Section 6 of Rationale.  I've rewritten the
sentence a little bit to get rid of "selected".

>...

> PROTOCOL
>...
> Appendix A.
> 
>    4.   Remove the mapping and normalization steps from the
> protocol and         have them instead done by the
> applications themselves, possibly         in a local fashion,
> before invoking the protocol.
> 
> It is unclear here, and throughout the document set, what
> precisely is meant by "application". Does this mean a DNS
> application such as a registration interface or a resolver, a
> using protocol (i.e., an application protocol that makes use
> of IDNs, such as EAI or XMPP), or both? IMHO this could be
> clarified in, for example, section 1.1. of the Rationale
> document (which uses the term "client applications"), section
> 1.1.1 and section 2 of the Definitions document, section 3.2
> of the Protocol document (which speaks of "protocols" instead
> of "applications"), and section 2 of the Mapping document.

See my earlier note to someone else about unnecessary messing
with terminology at this stage.   If there is WG consensus that
it is necessary to try to fix this, I'm happy to try to do that,
but I hope everyone who thinks that is important will sign up to
check for unintentional side-effects.

best,
   john