Final Sigma (was: RE: Esszett, Final Sigma, ZWJ and ZWNJ)

[JFC Morfin]

Eric,
the only possibility so far we have, because it does not change the 
DNS, does not extend the prefix, respects IDN2003 and does not 
confuse IDN2003, is to use the 35 possibilities of the second prefix 
position ("x.--" form "x0"-- to "xz--").

However, this possibility is _outside_ the WG Charter and considers 
IDNA's "xn--" as a default case. The only difference in supporting it 
for Internet PLUS IDN modules will be to look for "x.--" and 
discriminate on the second position. "n" in second position will mean 
IDNA2008, other second position values, will mean other format 
rendering than pure lower cases based upon a regular or an extended 
punycode use.

This puts the problem outside of the IDNA2008 solution what 
simplifies the debate. It would also be simpler if the Unicode space 
remains neutral. The remaining unknown is the number of typographic 
algorithms to be needed. This calls probably for a further 
optimization analysis.
jfc

At 06:53 27/02/2009, Erik van der Poel wrote:
>Hi John,
>
>The idea was not a fully fleshed out proposal, as I'm sure most people
>are aware. I have no idea whether we can add any more "fields" (for
>lack of a better term) to the relevant part of the DNS, but I was
>simply imagining that one could add a new, optional field that would
>only serve as a hint to the software that is attempting to decode the
>Punycode and display the resulting Unicode on some device. In the
>absence of the hint, the software would simply display the Unicode as
>is, i.e. in the case of Greek, probably lower-case characters without
>tonos, and normal, lower-case sigma instead of final sigma. If the
>software was able to retrieve the hint for a particular label (if not
>FQDN), the hint would indicate which characters should have a tonos,
>and which sigmas should be final.
>
>I certainly do not want to give anybody the impression that fields can
>be added to DNS willy-nilly. Such endeavors must be carefully
>considered, preferably by DNS experts. :-)
>
>You're probably right that one of the original goals of IDNA was to
>avoid "changes" to DNS itself, but given that one can retrieve e.g. A
>for IPv4 and AAAA for IPv6, I don't consider it so outrageous to store
>yet another piece of info about a label (or FQDN) in the DNS.
>
>If people outside Greece want to use Greek characters but don't mind
>the way IDNA2003 maps sigmas (and doesn't map characters with tonos),
>then they could of course just use IDNA2003 with xn--. One of the
>difficulties with this idea is to come up with a clean way for an
>implementation to decide which mapping spec and prefix to use (xn-- vs
>xo--) when the user is typing the label on the keyboard (given that
>labels inside e.g. HTML files would always be processed the IDNA2003
>way). One very simple and probably silly idea is: if the label is
>being typed on the keyboard, and if the TLD is .com, then use IDNA2003
>with xn--. If the TLD is .gr, then use the new Greek mapping spec with
>xo--.
>
>Does this explain my thinking a bit better? Again, I don't really want
>to go down this path because of the difficulties of multiple prefixes.
>
>I apologize for sending out half-baked ideas. I was only wondering
>what we might be able to do for the Greeks, other than DNAME or a new
>*NAME that actually solves their problem neatly.
>
>Erik
>
>On Thu, Feb 26, 2009 at 7:45 PM, John C Klensin <klensin at jck.com> wrote:
> >
> >
> > --On Wednesday, February 25, 2009 09:48 -0800 Erik van der Poel
> > <erikv at google.com> wrote:
> >
> >>...
> >> Then there could be an extra field in the DNS that indicates
> >> how to display those names in Unicode form. I.e. it would tell
> >> you which sigmas are supposed to be final, which characters
> >> should have a tonos, and so on.
> >>...
> >
> > Erik,
> >
> > Could you please explain "extra field in the DNS" to those of us
> > who are under the impression that
> >
> >        * that there are no places to put extra fields in any RR
> >        type in CLASS IN
> >
> >        and/or
> >
> >        * that the primary premise of IDNA is to avoid making
> >        any changes to the DNS.
> >
> > ... just trying to understand what you are proposing.
> >
> > I hope it is not to encourage Greece to do something that would
> > not be interoperable with the rest of the Internet, including
> > people outside Greece that are using Greek characters?  That
> > would rather defeat one of the advantages of IDNs as well as
> > having other bad consequences.
> >
> > best,
> >     john
> >
> >
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update