Another Transition Plan Proposal

[Debbie Garside]

Gervase wrote:

>>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.

Not necessarily...

Bundling could (and in my opinion should) mean that if someone purchases 
haßle.com they also get hassle.com (for the foreseeable future) with each 
resolving to a different IP address. It would be up to the end user to use a 
"pointing" facility for the second domain. If hassel.com is already taken then 
haßle.com is offered to the owner of hassle.com or made unavailable for 
registration for a set time (transition) period.

I am not sure what the future implications would be if two domain names 
resolve to the same IP address.  I thought the idea was to get away from the 
possibility that two domain names could resolve to one IP address? For future 
interoperability they surely need to start (as soon as possible) resolving to 
separate IP addresses.

However, maybe I am misunderstanding all this. I have to say I am now lost in 
all the different (proposed) transition/bundling plans and without reading 
through the 50+ emails I am unlikely to regain understanding of this thread in 
the near future.

Debbie

> -----Original Message-----
> From: idna-update-bounces at alvestrand.no
> [mailto:idna-update-bounces at alvestrand.no] On Behalf Of
> Gervase Markham
> Sent: 10 December 2009 23:13
> To: idna-update at alvestrand.no
> Subject: Re: Another Transition Plan Proposal
>
> 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
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>