Another Transition Plan Proposal

[Gervase Markham]

On 10/12/09 13:33, John C Klensin wrote:
>> 1) Make the characters final-sigma and sharp-S usable ASAP.
>> 2) Avoid as much as possible the situation where the same URL
>> goes to  two locations in two different clients.
>
> I note that you say "URL" here.

Yes; shorthand from my world. Sorry about that :-)

> A strategy that necessarily "sticks" mail-related URLs with
> constraints that come mostly from web deployment may not be an
> optimal strategy.  And it might be ignored as a result.

Let me then rephrase 2) as:

2) Avoid as much as possible the situation where the same domain
is resolved to two different IP addresses (not controlled by the same 
entity) by two different clients/resolvers.

Specifying this principle in a watertight way which covers all the bases 
might require further elaboration, but I hope everyone knows what I mean.

> Final sigma in its normal context is fairly easy.  One might
> sensibly infer that any Greek string obtained by
> back-translating an existing A-label that has lower case sigma
> as the last character was intended to be final sigma.  Because
> of the word-joining problem, one cannot as safely make the
> reverse assumption --that lower-case sigma inside a label was
> not intended to be final sigma-- but perhaps it is close enough.
>
> But Eszett is complex enough that I'm not sure that I even
> understand what the above is proposing.

Actually, what happens could be even simpler than that. What would be 
the downside, apart from perhaps the increase in size of the zone file, 
of just doing bundling for every possible instance of the characters?

So as well as the obviously-correct cases, hassle.com would also have an 
alias as haßle.com. No-one will ever type haßle.com into their browser, 
but that's OK. Similarly, γλώσσα.com would also have γλώςςα.com, which 
is entirely wrong. But again, no-one would type it, so it just sits 
there. The price of having some obviously-odd domain names in the file 
is that we make sure that all the edge cases are covered, and we don't 
have to draw a line between "this one over here needs an alias, and this 
one over there does not".

Also, this is such a simple substitution that a script could be written 
to do it, or an option to do it automatically could even be included in 
DNS resolvers. All this would make it much more likely that people would 
do it.

(Oops, just noticed I didn't replace all the placeholder Bs with ß in my 
previous message. Apologies to anyone who found that distracting or 
insensitive.)

> Not to be negative, but I am no longer certain what "bundle"
> means because it has been used in many different ways on this
> list.  In a way, that is an advantage, because I think giving
> registries choices of which interpretation of "bundle" then
> intend to use is an advantage as long as the general objectives
> can be met.

I am not closely acquainted with the technical details, but if two 
domains are, in my terminology, "bundled", it means that they both 
resolve to the same (set of) IP address(es) in all circumstances.

> Cary and others may be able to calibrate this better, but my
> understanding from discussions with various ccTLD operators that
> sunrise procedures have been much more effective, much more
> widely used, and _far_ less complicated to administer than
> JET-like variant procedures, especially when there is a
> reasonable expectation that one "form" and another may diverge
> over time.

You mean give owners of domains in .gr six months to register the 
final-sigma versions of their existing domains, should they choose to, 
rather than enforce bundling? That sounds like it would be more 
expensive in terms of administration and publicity.

> Please also don't forget the fact that there are German and
> Greek registrations in various gTLDs.  I don't know whether the
> same principles would usefully apply, but I think we need to at
> least consider the issue rather than assuming it is limited to
> ccTLD registries whose primary language of interest is Greek or
> German.

Of course. My view is that registries who don't want to break the world 
for their customers using these characters will do the 
search-and-augment (like a search-and-replace, but with additions :-) on 
their zone files. Other ones will get shouted at when their customers 
domains stop working in some browsers.

> I also imagine, although local circumstances may differ, that,
> if I were administrator far down in a subtree that expected lots
> of Greek or German registrations, I might simply avoid
> registering strings containing the new characters if there were
> any possible conflicts until I was convinced that applications
> software had been converted.  Again, blocking particular
> characters, or blocking them in some contexts, is another form
> of bundling because it recognize the possible relationships.

I prefer to distinguish the two, but I have no preference as to which a 
particular registry implements. It's not my place to say.

Gerv