From: JP Blankert (thuis & PC based) (jpblankert@zonnet.nl)
Date: Mon Nov 01 2010 - 12:53:48 CST
Excellent remark! Fu*ß*ball.de was my hope of last week....now with
everybody of us jumping on it, I can 'forget it'. I will have to go for
a more modest name ;)
Yes, I think the current owners of Fussball.de will be notified that
they have 'sunrise period' (=priority period, on new domains, like often
brands have), and are given the choice whether they want to have Fußball
as well. If the reader of the email to them thinks 'What a details, I
think our directors are happy with Fussball.de, DELETE' one of us can be
lucky. Although I have no German domain names at the moment, I think I
will pick one this evening (no matter how bad the name - condition: it
must be a potential ß) to see what happens: whether I am offered *ß,
*and later: having totally different websites on XXXXXXXXXss.de and
XXXXXXXXXß.de . That will hopefully be the start of awareness that in
future, and certainly re. internationalised domain names, people need a
(paid) IDN consultant. And in my heart, that is what I want to be
(rather than building a huge business or trading 'empty' domain names).
People who are also interested, can join (of course also 2011+). To have
credibility as IDN consultant, one needs illustrating examples, and know
about IDN, extensions, punycode and unicode as well. And web data mining ;)
By the way, on some extensions a mix of lettertypes is possible....like
HTML/editor./com, the cursive being Chinese. And on the new Russian
Federation extension, sometimes I managed to register Ukraine instead of
Russian, and sometimes Ukraine was rejected. Interesting times ahead!
And good to put unicode and IDN knowledge together. I will of course be
back to you when I manage to have a ss-ß**'twin' and two different
websites on it.
BR!
Philippe
( On 1-11-2010 18:41, Shawn Steele wrote:
>
> What about fussball.de? Certainly they want fußball.de to continue to
> point to them, as it did in IDNA2003.
>
> What’s really needed is a “display form” and a “matching form”.
> Linguistically, ss is nearly always identical to ß for matching,
> particularly if you want both german and swiss users. However the
> preferred “display” form is always one or the other. Eg: Nobody’s
> going to expect fussball != fußball; however it’s supposed to be
> spelled fußball in Germany and fussball in Switzerland. Although the
> fussball.de owners have clearly taken the ss variation as their own,
> despite the linguistic rule.
>
> The other cases are similar: there’s little linguistic value in the
> variations, but the differences are even more important for correct
> rendering of names using those characters.
>
> IDNA2003 favored matching, IDNA2008 favors exact display forms (sort
> of, AAA, the automotive club, still gets stuck in a less-preferred
> display form of aaa).
>
> -Shawn
>
> *From:*unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
> *On Behalf Of *JP Blankert (thuis & PC based)
> *Sent:* Saturday, October 30, 2010 12:32 PM
> *To:* Mark Davis ☕
> *Cc:* "Martin J. Dürst"; Markus Scherer; unicode@unicode.org;
> stichtingburnout; "Blankert (privé), Jean Philippe"
> *Subject:* ss and ß
>
> Nice thought...on the other hand: would it be honest to automatically
> double the worth of existing 'Straße.de' owners?
>
> They could sell off Strasse.de and re-start exploiting Straße.de
> (selling off: it are 2 different punycodes, difficult to forbid an
> owner to sell one of them).
>
> Your solution is known to me in the case of Taiwan, IDN, there they
> choose the solution: if you get the name in simplified Chinese, you
> get it in traditional Chinese as well.
>
> The joiners I have to study, I found
> http://www.google.com/support/forum/p/Chrome/thread?tid=64832607ce9c5637&hl=en
> <http://www.google.com/support/forum/p/Chrome/thread?tid=64832607ce9c5637&hl=en
>
> Above is not mentioned to trigger an ethical discussion on 'doubling
> the ownership or not', it was just a different kind of thought to your
> proposed solution, for which: thanks. Am curious how registrants will
> go about it. Nice to have found this mailing list, because otherwise I
> would have nobody to discuss this with.
>
> Br,
>
> Philippe
>
> On 30-10-2010 20:52, Mark Davis ☕ wrote:
>
> Whether or not it was a good idea to have ß in domain names
> (post-mapping) is moot at this point, given IDNA2008. The key will be
> to manage the transition well. For many years, client software
> (browsers, etc.) will be converting ß to ss in domain names. To
> prevent serious problems, it's recommended that any registrar that
> allows ß to do the following:
>
> If someone attempts to register a label with any ß, check if the
> corresponding label with all ss's is registered.
>
> 1. If so, reject the registration unless the registrant is
> precisely the same.
> 2. If not, automatically give the registrant both labels.
>
> That way both new and old browsers will continue to work, and security
> and operability problems will be avoided: (1) avoids security
> problems, while (2) gives correct results for both new and old client
> software.
>
> If client software knows that a registrar follows this policy, then it
> can then allow ß to be unmapped for that registrar.
>
> The same goes each of the 4 transition characters: /ß, ς, /and the
> two/ joiners./
>
>
> Mark
>
> /— Il meglio è l’inimico del bene —/
>
> On Sat, Oct 30, 2010 at 04:57, "Martin J. Dürst"
> <duerst@it.aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>> wrote:
>
> On 2010/10/30 9:17, Markus Scherer wrote:
>
> On Fri, Oct 29, 2010 at 3:57 PM, JP Blankert (thuis& PC based)<
> jpblankert@zonnet.nl <mailto:jpblankert@zonnet.nl>> wrote:
>
>
> Dear unicode.org <http://unicode.org> interested,
>
> I discovered at least 1 flaw in the converter tools I used so far (as
> Verisign's IDN to punycode converter): none of the ones I checkes
> recognises
> the German character
>
> ß
>
> (the sz, as from 'Straße' )
>
> correctly, the sign is always dissolved in ss.
>
>
> This is standard IDNA2003 behavior.
>
> Yes.
>
>
> It is usually desirable
>
>
> It is desirable in searching, but it wasn't desirable in domain names.
> The reason it got into IDNA2003 is because the IETF was looking for
> data to do case mapping beyond ASCII, and the data available from the
> Unicode consortium included the 'ß' -> ss mapping, and the IETF didn't
> want to change it because they feared that might start all kinds of
> discussions on all kinds of (essentially unrelated) issues.
>
>
>
>
> because a) many
> German speakers are unsure about when exactly to use ß vs. ss,
>
> Yes, but for many names, it's either one or the other. Essentially, no
> rules.
>
>
>
>
> b) the
> spelling reform a few years ago changed the rules,
>
> Yes. They got way easier and more straightforward.
>
>
>
>
> and c) Switzerland does
> not use ß at all in German.
>
> Yes. But that's no reason to take it away from those who use it.
> (at least myself being Swiss I don't think so)
>
>
>
>
> This means that for most purposes it is
> counter-productive (and can be a security risk) to distinguish ß and ss.
>
> Well, it can be a security risk to distinguish between 'i' and 'l' and
> '1', and so on, and nevertheless, it's being done for good reasons all
> the time.
>
>
>
>
> IDNA2008, an incompatible update, by itself does not map characters.
>
> What's more important, IDNA2008 allows the 'ß' as is.
>
>
>
>
> UTS #46
> provides a compatibility bridge for both IDNA2003 and IDNA2008, and the ß
> behavior is an option there.
>
> Yes. The basic idea in TR #46 is that in a first phase, 'ß' is mapped
> to 'ss' for lookup, to give registries with German clients a chance to
> their clients to register true 'ß' where necessary. After that, the
> mapping can be dropped, so as in the (somewhat distant) future to
> allow for cases where a name with 'ß' and a name with 'ss' are
> resolved differently.
>
> Regards, Martin.
>
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
> <mailto:duerst@it.aoyama.ac.jp>
>
>
>
>
> Geen virus gevonden in het binnenkomende-bericht.
> Gecontroleerd door AVG -www.avg.com <http://www.avg.com>
> Versie: 9.0.864 / Virusdatabase: 271.1.1/3227 - datum van uitgifte: 10/30/10 08:34:00
>
>
>
>
> Geen virus gevonden in het binnenkomende-bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 9.0.864 / Virusdatabase: 271.1.1/3231 - datum van uitgifte: 11/01/10 08:35:00
>
This archive was generated by hypermail 2.1.5 : Mon Nov 01 2010 - 12:56:56 CST