AW: Mappings - some examples

Wed Dec 2 06:27:31 CET 2009

Google already today "correct" my spellings in a way so that it is  
increasingly (yes, it is getting worse) hard to search for words that  
are correctly spelled in Swedish, but Google think it is a misspelling  
in English.

I have wanted for some time an ability to turn off Googles "help" ;-)

And broken links...happens all the time although I understand you try  
to detect them.

    Patrik

On 1 dec 2009, at 21.22, "Georg Ochsner" <g.ochsner at revolistic.com>  
wrote:

> Hello Mark,
>
>
>
> I don’t understand why it would cause problems for search engines. W 
> hich would they be more in detail? In the organic Google results you 
>  can link to the punycode version for the new ß hosts. And you can s 
> till link to ASCII ss domains as well. I think this is very clean ac 
> tually, really everybody will get to the same hosts from the same se 
> arch results. Or is it about crawling or duplicate content, what you 
>  mean?
>
>
>
> Thanks
>
> Georg
>
>
>
>
>
>
>
> Von: mark.edward.davis at gmail.com  
> [mailto:mark.edward.davis at gmail.com] Im Auftrag von Mark Davis ?
> Gesendet: Dienstag, 1. Dezember 2009 21:03
> An: Georg Ochsner
> Cc: Alexander Mayrhofer; Patrik Fältström; Michael Everson; IDNA upd 
> ate work; Andreas Stötzner
> Betreff: Re: Mappings - some examples
>
>
>
> I think this is somewhat like the TRANSITIONAL strategy that I  
> suggested. The intermediate browser feature you suggest wouldn't  
> work, however.
>
> A UI would be really ugly in practice. The venders have found that  
> simple icons don't alert people - what you have to do is go to a  
> special intermediate page with strong warnings, and have a Continue  
> and Back button.
>
> If you are on an old browser, of course, you'd still go to 'ss'.
>
> And it won't work with search engines (we don't have little men in  
> our servers at Google who can decide what's real and what's not.
>
> And it won't work for email (without some really ugly bounceback).
>
> Mark
>
>
> On Tue, Dec 1, 2009 at 06:45, Georg Ochsner  
> <g.ochsner at revolistic.com> wrote:
>
> Hello Mark,
>
> what about a fourth scenario?
>
> 1. IDNA2008 clearly says that ß is PVALID an shall not be mapped to  
> ss anymore.
> 2. Browsers get an additional feature. It informs users when typing  
> a hostname with ß that previously they would have been redirected to 
>  the ss sibling. And that they now need to use ss in order to get to 
>  the old destination.
>
> 3. Registries wait until IDNA2008 is spread, let’s say more widely t 
> han IDNA2003 is until now. (That is 6 years and with still xx% IE6s  
> out there)
> 4. Registries inform the registrants and offer a grandfathering  
> registration (like the .mx registry recently did) that allows all  
> registrants of domain names with ss to register the ß sibling if the 
> y like.
> 5. Registration is opened to the public and people realize that  
> "machines" now distinguish ß from ss like humans do.
>
> Please add more useful steps between 1. and 5. :-)
>
> Best regards
> Georg
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: mark.edward.davis at gmail.com  
> [mailto:mark.edward.davis at gmail.com] Im Auftrag von Mark Davis ?
> Gesendet: Montag, 30. November 2009 19:01
> An: Georg Ochsner
> Cc: Alexander Mayrhofer; Patrik Fältström; Michael Everson; IDNA upd 
> ate work; Andreas Stötzner
> Betreff: Re: Mappings - some examples
>
>
> Even for English, IDNA does not permit all valid words: "Joe's Bar"  
> will not work, because of both the space and the apostrophe and  
> "Joe'sBar" because of the apostrophe. IDNA2008 explicitly does not  
> permit all sequences that would be valid words in all languages; nor  
> could it do otherwise.
>
> There are two compatibility problems:
>
> 1. Existing web pages and other documents that contain ß and expect  
> to go to location X and not Y.
> 2. There is still an existing body of billions of browsers that will  
> take years to disappear (as Erik points out, something like 20% of  
> browsers are still IE6).
>
> Let's suppose that IDNA2008 allows ß, and that the newer browsers us 
> e it (and not a compatibility scheme like http://unicode.org/reports/tr46/ 
> ). The only real purpose to allowing ß is so that you can distinguis 
> h from ss. But what happens when Herr Stosser gets stosser.at and He 
> rr Stoßer gets stoßer.at?
>
> Initially, 100% of all browsers will go to the ss form. Nobody will  
> go to Stoßer's site; his email won't work, etc.: href="stoßer.at" go 
> es directly to "stosser.at". Even on Stoßer's site, absolute intrapa 
> ge links will go to the 'wrong' place. After a while, some newer bro 
> wsers will take page href="stoßer.at" and go to stoßer.at, while all 
>  the other browsers will go to href="stosser.at". The same goes for  
> email. So access to all of those links (and mail, etc.) will be unre 
> liable, and the subject of security and compatibility problems. As a 
>  result, practically, people would be unable to use href="stoßer.at" 
>  in their web pages or in email until essentially all existing brows 
> ers were supplanted, which will be maybe 5 years down the line. And  
> during that time, these will also bollux up all the search engines,  
> since indexing assumes that links don't have ambiguous targets.
>
> And that assumes that nobody does use a compatibility mechanism.  
> Another, more likely, alternative based on our conversations with  
> vendors is that people disregard that part of IDNA2008, and use a  
> compatibility mechanism like http://unicode.org/reports/tr46/; that  
> allows the browsers, emailers, search engines and others to keep  
> functioning correctly - there is no transition. The downside is that  
> you can't register both stosser.at and stoßer.at. So of the thousand 
>  Herr Stoßers, instead of one of them getting that name, none of the 
> m do; it's like "Joe'sBar". And, of course, there is the disadvantag 
> e of having UTS46 have to exist in the first place.
>
> The third alternative is the really awful one: the "let a thousand  
> flowers bloom" scenario. In this scenario, there is no single  
> compatibility mechanism like http://unicode.org/reports/tr46/;  
> instead, we get different variants from different vendors, and the  
> situation is chaotic. That is the scenario that the Unicode  
> consortium's members are really concerned with. While the ideal  
> solution would be an IDNA2008 that maintained compatibility with  
> IDNA2003, the second best solution is only one compatibility  
> mechanism; not dozens.
>
> Mark
>
> On Mon, Nov 30, 2009 at 07:55, Georg Ochsner  
> <g.ochsner at revolistic.com> wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: idna-update-bounces at alvestrand.no [mailto:idna-update-
> > bounces at alvestrand.no] Im Auftrag von Alexander Mayrhofer
> > Gesendet: Montag, 30. November 2009 15:57
>
> > > I would though be more "on your side" if the number of domain
> > > names that contained ß where say 100 times higher than today
> > > in published documents. Because then people would be TOLD to
> > > type in something (ß) that mapped to something else (ss) that
> > > was registered. That, I claim, is not the case. At least not
> > > "heavily".
> >
> > I understand that. And i'm saying that the potential of around 500
> > useful "ß" registrations (based on looking through our inventory o 
> f 900k
> > domains) is by far not worth the effort.
> In several talks with people from the Austrian registry I've now  
> heard this
> argument. But I think this decision should not be made depending on
> commercial factors. IDNA is in my eyes not a question of return on
> investment but about the native use of language in domain names  
> around the
> globe. Once more, the Austrian registry can still refuse to have  
> sharp s
> registered within their namespace, but maybe other registries pay more
> attention to the language aspect than to commercial calculations.
>
> Best regards
> Georg
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091202/097cb04f/attachment.htm 