Shawn Steele | 1 Dec 2009 01:04
Picon
Favicon

RE: Consensus Call on Latin Sharp S and Greek Final Sigma

Sorry for the partial sentence.

 

And that’s the problem J

 

In Switzerland users would certainly expect eszett to map to ss.  In Germany and Austria they wouldn’t be too surprised by the behavior.

 

So if, in the “contextual user interface” (& IDNA2003), the eszett is mapped to ss, then there’s no point to having it be PVALID.  So the problem here is that the lack of mapping IS related to the PVALID decision.  And that’s the big change from IDNA2003 that’s causing problems.

 

If there is no mapping, then PVALID makes a little bit of sense.  If you want discrete, unique ID’s for IRI’s, then I’m not sure you want fussball and fuβball to go to different places.  If you do want mapping at some level, then mapping these and keeping IDNA2003 behavior is logical.

 

So I think these behavior of these 2 characters also depends on the mapping behavior.  IDNA2008 took a different direction in mapping, and that led to this behavior for these characters.  IDNA2003 went a different direction with mapping and that led to a different place.

 

-Shawn

 

From: Vint Cerf [mailto:vint <at> google.com]
Sent: ,  30,  2009 1:51
To: Shawn Steele
Cc: Mark Davis ☕; Harald Alvestrand; idna-update <at> alvestrand.no; lisa Dusseault
Subject: Re: Consensus Call on Latin Sharp S and Greek Final Sigma

 

the distinction is not between mapping.

 

the distinction is between allowing or not allowing these two characters as PVALID.

 

Mapping is not part of the IDNA2008 proposed standard. The mapping document and other references to mapping in rationale are not normative. Mapping may very well occur in consequence of contextual user interface treatments but such handling is outside the scope of the base standard.

 

vint

 

 

On Nov 30, 2009, at 2:45 AM, Shawn Steele wrote:



I agree with Mark that this is very badly worded.  Also, as Mark alludes, the distinction is between mapping.

 

(2) Both characters should be disallowed.  (and mapped as in 2003).

 

One would expect a swiss person typing "fussball.de" to continue to get to the expected site, even though the spelling isn't perfect by "de" standards.  The ONLY place where a distinction is interesting is in Germany and Austria, however Mark points out both of those NICs are against this change.

 

-Shawn

From: idna-update-bounces <at> alvestrand.no [idna-update-bounces <at> alvestrand.no] on behalf of Mark Davis ☕ [mark <at> macchiato.com]
Sent: Sunday, November 29, 2009 9:35 AM
To: Harald Alvestrand
Cc: idna-update <at> alvestrand.no; Vint Cerf; lisa Dusseault
Subject: Re: Consensus Call on Latin Sharp S and Greek Final Sigma

(2) Both characters should be DISALLOWED

I think the way the question is phrased may mislead some people on this list. The real choice is between having them mapped to "ss" vs having them distinguished from "ss", because all browser vendors are planning to provide mappings, and I think all other vendors will be drawn down that path, for compatibility with the browsers.

This standard is not written in a vacuum; whether or not eszett and final-sigma would have been a better choice 7 years ago, billions of current browsers and other programs use the 2003 policies, and those would take years to change. In the meantime, a change of this magnitude from 2003 will cause significant problems.

The people on this list need to carefully consider their positions, since they will not have to live with the compatibility and security problems; German and Greek speakers will. And it is telling that representatives like the German and Austrian NICs are in favor of continuing the 2003 policies of mapping the characters.

Mark

 

_______________________________________________
Idna-update mailing list
Idna-update <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
Shawn Steele | 1 Dec 2009 02:45
Picon
Favicon

RE: Mapping?

> I don't want anything, anywhere, to suggest that I have registered three 
> domains, one of which is "paß.alvestrand.no, another one is 
> "PASS.alvestrand.no" and a third one is "pass.alvestrand.no".

Assuming the rules are applied consistently, then they would be clearly understood by all.  If ß is mapped
to ss as in 2003, and if we continue having case mapping for ASCII, then it is clear that you have only one
registered domain.

Should the rules change so that ß no longer maps to ss, then it is no longer clear.  Depending on the browser
and usage it might appear that you have 1 or 2 domains.  That's part of why the rules need to be stable and
applied consistently.

-Shawn
_______________________________________________
Idna-update mailing list
Idna-update <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
Picon

Re: [iucg] consensus over PVALIDs

I am afraid we also have traveling linguists to consider.
I am quite unatease with specfic cases.
I would prefer to discuss PVALIDIty criteria.
What is we miss equivalent issues in less familiar languages?
Why would the .gr Manager or the youth of Martin be of a particular impact on a global Internet protocol?

Portzamparc


2009/11/30 jefsey <jefsey <at> jefsey.com>
Dear all,

Vint Cerf has called for a consensus. Actually we are in a multiconsensus configuration that the IETF does not support. We have three different trade consensuses (see below) which might conflict. In such a situation multiconsensus rules say that:

1. each group should define its own consensus
2. document the way each group's solution can interoperate with the two other groups.
3. document their consensus over that interoperation being possible or not possible.

I read at least three different trade visions which are:

1. the internet designers : this is the bulk of the participants since we are on an IETF list. They consider the IDNA support of IDNs through LDH domain names. They wants a better performing IDNA because making the Internet working better is the mission of the IETF, and that is why the Internet work. Consensus is for PVALID.

2. the manufacturers : Unicode people (Mark, Shawn, etc). They know that  costs and pains are higher in adaptation than in development. Also that small changes at the network level may imply big changes at the production and operation level. I note that (1) they worry about one letter (having an alternative) in two languages but do not care about Latin majuscules which represent 26 (no alternative) semantically damaging letters in a dominant set of languages (2) hence a necessary alternative or alteration to IDNA; (3) the real cost is in the delays.

3. the internet users : these are ccTLDs and lead users ( <at> larges). We are used to work on a multiconsensus basis by necessity. We consider IETF Internet layers as value added dumb bandwidth we can use the way we need. We oppose mapping at protocol level as it impacts on the IDNA orthotypographic neutrality (and probably on network neutrality due to possible poor understandings by some developpers or too good understanding by some hackers.). We certainly share the concerns of Mark and Shawn, but we only are interested in them being _supported_when_ we need it, not _enforced_. Supported means at a layer we control. Enforced means at a layer we do not control. This is why we want the network layers to stay as dumb as they should be (RFC 1958, this is the whole IDNA2008 purpose as we see it); and why we include in our machines two extra layers for a smart pseudo-network (Interplus) where we can do everything we want (including ML-DNS transcoding and DNS resolution). 

I know the Interplus may represent at protocol and naming layers far worse a nightmare than NATs represent at addressing layer. But I did not develop it. I do think that it might be worth to address the danger it may represent if poorly used/governed rather than to oppose the messenger.

jfc

_______________________________________________
iucg mailing list
iucg <at> ietf.org
https://www.ietf.org/mailman/listinfo/iucg


_______________________________________________
Idna-update mailing list
Idna-update <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
Shawn Steele | 1 Dec 2009 03:02
Picon
Favicon

RE: Consensus Call on Latin Sharp S and Greek Final Sigma

On 2009/11/30 16:45, Shawn Steele wrote:
>> I agree with Mark that this is very badly worded.

> Can you propose (in your eyes) better wording?

It's easier to say it is badly worded :)  I'll try:

(1) Both characters should be PVALID, the 2003 mappings will break.
(2) The 2003 mappings MUST be applied to both characters, and both characters should be DISALLOWED.
(3) The 2003 mapping for Greek Small Letter Final Sigma MUST be applied, but not the Latin Small Letter Sharp
S mapping.  The Latin Small Letter Sharp S should be PVALID.
(4) The 2003 mappings for Latin Small Letter Sharp S MUST be applied, but not the Greek Small Letter Final
Sigma mapping.  The Greek Small Letter Final Sigma should be PVALID. 

There's a fundamental problem with my wording; it presumes we have to have mappings, which opens a
different set of problems.  Perhaps we should start with a consensus call on mappings first:

(A) No mappings are permitted.
(B) Only ASCII case mappings are permitted.
(C) Any mapping MAY be used.
(D) Only IDNA standard mappings MAY be used, other mappings are disallowed.
(E) IDNA standard mappings SHOULD be used, other mappings are disallowed.
(F) IDNA standard mappings MUST be used, other mappings are disallowed.

That leaves open what an "IDNA standard mapping" is, however I would suggest that it be as close to IDNA2003
as possible, eg: UTR46.  Presumably if we knew mappings MUST NOT, MAY, SHOULD, or MUST be used, then we could
better agree on what exactly those mappings should be.

As everyone knows already, I would prefer (F) or (E), or reluctantly (D).  IMO (A) is not practical, (B) is not
internationalized, & (C) is chaos.

-Shawn
Kenneth Whistler | 1 Dec 2009 03:50
Picon
Favicon

Re: Consensus Call on Latin Sharp S and Greek Final Sigma


> (2) Both characters should be DISALLOWED

And following Shawn Steele's logic: "(and mapped as in 2003)"

--Ken
Shawn Steele | 1 Dec 2009 03:56
Picon
Favicon

RE: Mappings - some examples

> Yet your example contains a case where Herr Stosser and Herr Stoßer are
> different people, with different spellings of their names.  

If Herr Stoßer moved to Switzerland from Germany, then they may be the same person.  And Fussball.de is
clearly "correctly" spelled Fußball.de (since it's not fussball.ch), yet I don't think you'll find any
German speaker in any country that thinks fussball and fußball mean different things.  There may be
disagreement in the preferred spelling, but, even in Germany, the spellings are effectively
interchangeable.  I also seriously doubt you'd find a German speaker that'd mispronounce fussball either.

For Herrs Stoßer and Stosser, there's no guarantee that some other Herr Stosser didn't beat him to the
registrar.  I certainly can't register Steele.com.  DNS certainly has no guarantees of preferred
uniqueness.  I also can't register fluke.com in English for a lucky web site if you've already registered
fluke.com as a save-the-whales web site.  A coking plant can't even register coke.com to talk about their
petroleum products.  The risk of pointing to the "wrong" web site for ß and ss outweighs the ability to make
them different web sites in the fairly rare cases when the difference is linguistically interesting.

Note I don't say that ß and ss shouldn't be presented "correctly" for the web site owner, just that they can
be reasonably expected to go to the same place.  If Fussball.de prefers to be displayed as Fußball.de,
that should be permitted, but they should both get you to the same server.

-Shawn
_______________________________________________
Idna-update mailing list
Idna-update <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
Shawn Steele | 1 Dec 2009 04:03
Picon
Favicon

RE: What registries might do (was: Consensus Call on Latin Sharp S and Greek Final Sigma)

> > Instead of restriction, what if registries could be relied upon to
> > bundle a PVALID ß with 'ss' for a period?  

My understanding is that's what .de and .at intend to do, although permanently.  And if the registrars in the
2 countries where this is interesting effectively make them the same, then what's the purpose in trying to
make them different?  The only interesting case at that point is lookup/display, the "preferred" form. 
It'd be better to handle preferred forms in a more flexible form so that AAA.com didn't keep getting
displayed as aaa.com.

> So I can report that there are some -- "at least one" -- people who want ß to be
> available.)

But would that person be happy with display?  It's reasonable for someone to want ß to be displayed as they'd
registered it, but it's unrealistic to expect two different web sites fußball.de and fussball.de to coexist.
 
-Shawn

_______________________________________________
Idna-update mailing list
Idna-update <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
Shawn Steele | 1 Dec 2009 04:11
Picon
Favicon

RE: Consensus Call on Latin Sharp S and Greek Final Sigma

> This is not a dialog that might only be expected on a national level.
> Illustrating this with a purely hypothetical situation -- should, say,
> the Government of Cyprus decide to apply for the Fast Track delegation
> of the full name of the country, it would not likely be happy when told
> that it this not possible because the operator of the ccTLD in another
> country where Greek orthography is prevalent persuasively advised the
> IETF that the final sigma is dispensable. This would bump the question
> up to the EU level, also calling attention to the fuller range of their
> orthographic directives.

I am NOT saying that the final sigma is dispensable, only that it should point to the same server as a sigma. 
(Case mapping is a problem here too, like camel casing).  Specifically I've mentioned several times that
there should be a display form that provides the desired spelling.  Surely there's no need for a final sigma
and sigma to point different places at the TLD level?

-Shawn
Andrew Sullivan | 1 Dec 2009 04:47

Re: Mappings - some examples


On 2009-11-30, at 21:56, Shawn Steele <Shawn.Steele <at> microsoft.com>  
wrote:

> Note I don't say that ß and ss shouldn't be presented "correctly" fo 
> r the web site owner, just that they can be reasonably expected to g 
> o to the same place.  If Fussball.de prefers to be displayed as Fußball.d 
> e, that should be permitted, but they should both get you to the sam 
> e server.
>
> -Shawn

And yet you ignore the analogy of color and colour, which is at least  
as close in this case as anything we might get across languages.  In  
that case, they _don't_ go to the same place, and nobody is mystified.  
Why?  I say it's because we have learned to live with this, and that  
people could learn the new rules in German too.

If I'm right, then you have a transition problem & not something  
fundamental to the protocol. Opponents of PVALID for these two cases  
seem not to be addressing that distinction, but if you're going to  
make your case it is, I say, critical.

A
--

-- 
Andrew Sullivan
<ajs <at> shinkuro.com>
_______________________________________________
Idna-update mailing list
Idna-update <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update
Vint Cerf | 1 Dec 2009 05:10
Picon
Favicon

Re: Consensus Call on Latin Sharp S and Greek Final Sigma

mapping isn't part of the normative protocol but could be permitted as  
a User Internet matter, under the present formulation of IDNA2008.

vint

On Nov 30, 2009, at 9:50 PM, Kenneth Whistler wrote:

>
>> (2) Both characters should be DISALLOWED
>
> And following Shawn Steele's logic: "(and mapped as in 2003)"
>
> --Ken
>

Gmane