Eszett (was Implementation questions)

[JFC Morfin]

Dear John,
my point is not on any particular. It is on the way IDNA2008 is now 
being worked on, not anymore for a quick finalization but to possibly 
become IDNA2010, with myriads of irrelevant details for an Internet 
protocol, etc. I read and understand the reasons why, and dislike 
this disrepect of the charter.

At 21:32 24/12/2008, John C Klensin wrote:
>--On Wednesday, 24 December, 2008 18:50 +0100 JFC Morfin
><jefsey at jefsey.com> wrote:
>
> > At 14:16 24/12/2008, John C Klensin wrote:
> >> Certainly, if I were a user registering a label that might be
> >> construed as being in German, I would try to do that
> >> regardless of what the relevant registry required.   But, if
> >> the registry did not exclude mixed-script registrations, I
> >> might also register a label containing β (U+03B2) any time
> >> I intended ß (U+00DF) to appear and vice versa, simply
> >> because, in some fonts, they look a little too much alike.
> >
> > John,
> > you put yourself in a very confortable situation.
>
>Comfortable?  Or uncomfortable?

Confortable. You assume that as a registrant you are free to decide 
what you will do to protect your rights.
As I ask you to imagine, this is in most of the cases uncertain 
because others registrants may interfere or conflict.

> > More pragmatically let us imagine that I am another German who
> > has interests in the same name appearance and I register the
> > other name. The question now is who is legally (UDRP, ccTLD
> > rules) legitimate? If a rule favors me, you will legitimately
> > sue the ccTLD Manager since the actual underlaying ASCII
> > strings are actually different.
>
>First of all, my comment about what I would do as a potential
>registrant is independent of the advice I would give registries.
>I have always advised registries to avoid mixed-script labels
>unless special circumstances arise and to use variant techniques
>to restrict registrations or separate ownership of
>easily-confused labels.   Sometimes registries take that type of
>advice and sometimes they do not and I recognize that there are
>legitimate reasons for not doing so.

Users are not engineers. They trust the IETF to make the Internet 
work better. If an IETF protocol permits something, why would they as 
simple zone managers forbide it?  If IETF protocols are not fool 
proof what can they do about it?

>And, as usual, this is not just about TLD registries and other
>zones that are subject to global policies.   Any zone
>administrator is going to need to balance things that people
>want to do (whether you consider it legitimate or not) against
>maximizing user protection.

Sorry, no!

Maximizing user protection is the precautionary role of the protocol. 
Internet is to survive the users. It did it until now. Do we want to 
change that?

For everyone the IETF is supposed to know better. What is legitimate 
is what they make possible. The "(world) constitution is in the 
code", the code is written in conformity to the standard. If users 
can change the standard it is not a standard any more (what is 
discussed here is far more than parametering a default installation).

>If the latter were our only objective, we would stick with ASCII 
>domain names (which I would certainly not advocate).

Why would you stay with ASCII domain names?

We only have to stay with a strictly sortable universal non 
confusable character set.

We decided that it will have to be Unicode. It is not a strictly 
sortable universal non confusable character set. So, the IETF's job 
is to make it robustly look as one. What is discussed here is to make 
it under many conditions a strictly sortable universa non confusable 
character set. But it is not discussed how to make it a robust one.

There are two places where to make it robust.

1) at the edge. The application must then control the edge and 
replace the DNS. This can only be the case in a multitiered Internet 
that would be co-managed by application operators such as major 
Search Engines, User desks, mail operators, etc.

2) at the DNS. An alternative I proposed and several consider in 
their own ways. We wait for of IDNA2008 to be completed to give it a 
try and preserve interoperability and interintelligibility.

> >From that perspective, whatever leverage the UDRP, local rules
>and regulations, etc., provide is very much part of the system.
>Many decisions about what to register are ultimately up to the
>registry. If the registry perceives risk if they get it wrong,
>that is not necessarily a bad thing.

The registry eveluations will be diverse. If the protocol does not 
unify them this will be a technical balkanization unless the internet 
becomes a new Compuserve-like network, lead by a Search Engine 
Operators's consortium.

> > You may remember that during the joint ITU/UNESCO meeting in
> > Geneva I questionned the WIPO on such situations (as well as
> > on babel-names [protected ASCII labels]). The response (after
> > a few cofees) was that they respected IPR in ASCII and in
> > Unicode, but were unable to decide when there was conflict
> > between the two.
>
>There is no more reason to believe that there is a conflict
>between ASCII and Unicode.  There are conflicts between
>(non-ASCII) scripts within Unicode as well.   To take a handy
>European example, there is more overlap between Greek and
>Cyrillic than between either and ASCII.

You play on words. The conflicts are over the non semiotic 
equivalence of punycode in/outputs. ASCII based, Unicode and real 
sortable universal non confusable character set namespaces are not 
equipotent. Outside of multiered externets, IDNA is not strict enough 
to artificially enforce that equipotence. Even if the work the WG 
carries may reduce the cardinal differences, there is no 
architectural enforcement of the IDNA constraints.  This is very 
simple mathematics. And Internet architecture: IDNA is not end to end 
- except when between a Search engine and its own made browser.

> > What do you think the ccTLD Manager can do, when all such an
> > additional hassle and costs are to be supported by zero added
> > revenue? He only can forget about any IETF rule, respecting
> > the rule of the code. This is exactly what ".su" documented.
> > As long as the IDNS is only to be supported at user
> > application layer and not at core presentation layer (i.e.
> > equal to the DNS which actually use the "default" presentation
> > layer)  the problem will stay with us.
>
>I don't understand what you are suggesting here.  Nothing requires a 
>ccTLD Manager to support IDNs if they don't consider them either 
>profitable or part of their mission.

I am suggesting nothing. I just state that as a registry manager, and 
as all the other registry managers I talked with, except a few ones 
who do not know yet how they will cope with ICANN recommendations, I 
do not, and I will not, make any difference between domain names - 
because users' applications could use them differently. Because this 
is not in my charter, in my economy, in my interest nor in my 
registrants' interest. The DNS is not at user application layer.

This is why I suggest this basic premise to be used by everyone.

>Nothing
>external to a country imposes a "zero added revenue" constraint.

So you want IDNs to cost more than ASCII DNs? What would be the rationale?

>Even with variants, there are some approaches that involve
>little additional hassle or cost (e.g., prohibit the
>registration of a confusing name by anyone if the name which
>might be confused with it is already registered) even though the
>bundling approaches do introduce some complexity.

Whatever you want. As long as it is in the code, i.e. documented in 
the RFC being used. Either published by this WG or by another WG 
building-up on this WG IDNA2008, if possible before 20090901-00:00. 
This would help ICANN and the Internet stability.

>As you know, I believe that, for many purposes, search engines,
>intentionally-populated directories, and alternate naming
>systems will, in the long term, be more important than IDNs.

Why? This would only build commercial dependance on search engine 
operators. I see no reason why IDNs would not be part of a 
generalised and fully interoperable multilingual naming system.

>That doesn't imply that IDNs are not important or do not have a
>role.  But, again, the decision is ultimately up to the
>registries.

Sorry. The decision to use IDN has been consensually decided by the 
ITU and the WSIS for years. The problem is not with IDN but with IDNA 
compatibility. Where/how is that compatibility to be implemented and 
enforced, and what the are the consequence if this is no part of the 
core Internet itself.

>Perhaps some registries will decide that the search
>engines, etc., will be important enough that they should just
>avoid registration of IDNs.

????
We are talking of zones here. The reasoning is the same for DN and 
IDN zones. There should always be equal coopetition/complementarity 
between DNS and Search Engines. My point is that from too long (hence 
the delay) this WG's discusses point of interest only to Search 
Engines. And delays the DNS calendar.

>If they do, I hope no one tries to
>make global rules that _require_ that they support IDNs (in a
>strange way, that is another reason for not mapping Eszett --
>since the mapping can produce an all-ASCII string, a zone that
>decided to not provide IDN support could find apparent IDNs in
>its zone anyway, with consequent increased support costs
>(however small)).

How that? You mean on this particular case or you think of something else?

>   But, if a zone does decide to support IDNs
>and still believes that other navigation methods will be
>important, then I hope that whatever we do with IDNA2008 will
>move things toward labels that are as unambiguous as possible,
>including especially having fully reversible

The problem is that two non equipotent sets cannot be bijective. You 
need first to adequately equal their cardinals. But just suggesting 
how to make it, does not force it....

>mappings between
>A-labels and U-labels (and hence no labels in URIs or IRIs that
>in native character form but are not either LDH-labels or
>U-labels).
>
>      john

Paul Hoffman answering Vint
>>It is clearly an issue how to convey to implementors the 
>>implications of this - which is one reason that the Rationale 
>>document is so important.
>
>Indeed. If the document is not available or not clearly 
>understandable to everyone who needs to be making the new decisions, 
>then interoperability with existing will suffer.

You seem to assume that only goodwilling people will implement IDNA.
Does that not set the precautionary principle and duty aside?
jfc