RE: [idn] Comments on IDNA/stringprep/nameprep

["Kent Karlsson" <kentk@md.chalmers.se>]

> Adam M. Costello

> Kent Karlsson <kentk@md.chalmers.se> wrote:
> 
> > A *delta* of the hostnameprep whould/should be used for SRV records;
> > i.e. it would use hostnameprep with a specified modification:  "LOW
> > LINE is not prohibited"
> 
> But what about when the exact classification of a domain name is
> unknown?  Maybe the software knows that it's a textual domain name but

draft-ietf-idn-nameprep-07.txt has the title "Stringprep profile for
Internationalised ***Host Names***" (my emphasis)...


> does't know whether it's a host or a SRV or something else that was
> invented after the software was written.  Should the software 
> err on the
> side of being too lenient or too strict?  Should it default 
> to enforcing
> the hostname syntax, which is probably the most restrictive 
> syntax there
> will ever be?  

You have a point there.  But then the "nameprep" document should
say that this is the "default table" (or "tailorable template"
which is politically correct ISO-speak for that) and "default
normalisation".  Another document should then define the "host name
delta", This should be quite separately from IDNA, which talks about
other things like the use of "punnycode" [I liked that misspelling...;
or was that "pennycode" ;-); sorry], something most users should
(though they will not) be shielded from.

However there is a problem with that: one has to decide *now* what
additions are allowable in the "textual formal Internet names",
and which are not.  With the approach I favor (most restrictive,
i.e. hostnames as "default", and no punctuation/symbols in the hostnames,
with deltas adding permissions to use) additional characters allowed
in "deltad" names or instead used for future IDN embedding syntaxes
can be decided as one goes along with this at future times.



> Nameprep defines a least common denominator--the most lenient
> restrictions that *all* textual domain names must adhere to.  Software
> can always apply those restrictions without fear of disabling 
> legitimate
> domain names, and software can depend on the fact that all legitimate
> domain names adhere to those restrictions.  Hostnameprep 
> would not have
> those useful properties.
> 
> Your idea of having one basic preparation for domain names and deltas
> against it for particular kinds of domain names is a good idea, but I
> think the deltas should always add restrictions, never remove 
> them.  In
> this model, the host restrictions in step 3 of ToASCII are a delta.

See above, on both issues.


> > I'm not sure why the document was split into "stringprep" and a
> > "profile".
> 
> So that the stringprep framework could be reused for other things
> (things that are not domain names at all).

I'm all in favour of reuse; note that a "deltas" approach has a much
higher degree of reuse!


> > If fullwidth letters are perfectly ok to enter (mapped to 
> normal width
> > by nameprep), why is not FULLWIDTH FULL STOP ok?  I think most users
> > that encounter that or similar (IDEOGRAPHIC FULL STOP in particular)
> > will find the currently specified behaviour idiosyncratic.
> 
> What currently specified behavior?  IDNA says nothing about the
> separators between labels except that they are "usually" dots.  IDNA
> says nothing about how to split domain names into labels, or 
> join labels
> into domain names.  It neither requires nor prohibits the 
> acceptance of
> fullwidth full stop as a domain label separator.

Hmmm, this kind of contradicts your statements in your other e-mail.
I think something should be said about this, namely that the entier
IDN is processed the same way before any kind of part splitting.
When everything else is so detailed about mappings etc., this should
be the same.  Otherwise how does anyone know if FULLWIDTH STOP is
allowed (as a part separator) in an IDN or not?


		Kind regards
		/kent k