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

[Erik van der Poel]

Just an afterthought, but if it really is impossible to add a new
field to DNS, one might imagine a new HTTP response header that
contains the hint. Of course, one would have to come up with other
ideas for protocols other than HTTP, but I hope you get the gist.

Erik

On Thu, Feb 26, 2009 at 9:53 PM, Erik van der Poel <erikv at google.com> 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
> - Show quoted text -
> 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
>>
>>
>