[At-Large] News gTLDs and e-mail

[JFC Morfin]

Dear Patrick,
this point is a key point because it means that one of the main 
Internet applications will be hampered by the new TLD policy.

This new TLD policy also includes ML-TLDs. I don't really see IETF 
issuing a solution that supports xxx at ASCII-TLD and not 
xxx at UNICODE-TLD. As a consequence every mail oriented software will 
have to be updated to support TLD only mail names.

These TLD can be ASCII or punycoded UNICODE. It would seem very odd 
if this mail system update did not consistently extend to the other 
Internet host logics and did not support both ASCII and UNICODE TLDs. 
It would be surprising if the consensus was not to use the same 
logisitic effort to deploy a fully consistent Multilingual Internet.

We (with James Seng and Vint Cerf) identified at the WG-IDNABIS 
[http://wikidna.org] that:
- (a) the IDNA proposition was not the ML-DNS france at large identified 
as the world expectation (a DNS to delivers the same QoS in every 
language and scripts as it does in English ASCII)
- (b) france at large was perfectly legitimate according to the IETF 
process to give a try to such a development [we are lead users, not 
engineers]. We confirmed that this was our intent at our 2008/07/02 
meeting. We committed that our effort will strive to stay IDNA 
interoperable and will be based upon LS640 (Linguasphere System 640) 
which is the bassis for the now reduced ISO 639-6 and now an open standard.

The basic difference between IDNA and ML-DNS is that IDNA is not end 
to end (what the user types is not what the other end receives). This 
is  to support a possible lack of understanding of IDNA by the 
receiving end, specially in the mail case. This leads
- (1) to an impossible entropy problem: Unicode is degraded by 
punycode and has no way to restore the intial entrry on the other end
- (2) an increasing barely sustainable set of complex constraints in 
order to limit the cases where this may happen. The confusion also is 
that these constraints only apply at adhering registries' level.

Would the end to end be acceptable (the ML-DNS hypothesis) most of 
the multilinguisation oriented issues would be addressed at the 
internet and not at the user application layer. This is because there 
would not be a specific presentation layer need anymore:  we would be 
back to the internet as a single shared space (one single 
presentation and session default layer). This conforms with the IETF 
core values documented in RFC 3935, which makes a feature from the 4 
layers internet model.

In this case the need is only for transition management:

1. it will be a matter of a few months period once it has been 
documented, tested and validated. This is because I do not think we 
can repeat the January 1st, 1983 approach. However, we could 
"virtualize" it, for example in using legacy/Multilingual Internet 
OPES Gateways (work is to be resumed as the WG-OPES which favored 
SMTP over the DNS as their second and currently last protocol support 
documentatoin after HTTP).

2. I fear that the community starts thinking about many other needs 
such a deployment could help (security, IPv6, semantic, etc.). This 
means, not to confuse and to overload the project, that the initial 
deployment would be conceived as a pilot experimentation towards a 
permanent Internet update process (this is part of the france at large 
plan to be detailed hopefully before September).

jfc

At 08:57 04/07/2008, Patrick Vande Walle wrote:

>There is an interesting discussion currently on the IETF list about 
>the consequences of the approval of the new gTLD process by ICANN.
>One possible issue may be with vanity gTLDs like apple, ebay etc. In 
>this context, an email address may just be user at tld
>
>This may be confusing to email clients and MTAs which try to be 
>"smart". Currently , the current standard is defined in RFC 2821 as such:
>
>2.3.5 Domain
>    A domain (or domain name) consists of one or more dot-separated 
> components.
>   [...]
>   The domain name, as described in this document and in [22], is 
> the entire, fully-qualified name (often referred to as an "FQDN").  A
>   domain name that is not in FQDN form is no more than a local 
> alias. Local aliases MUST NOT appear in any SMTP transaction.
>
>Hence, if either the mail client or the MTA expect to see a dot in 
>the domain name and there is none, its behaviour may be unpredictable.
>
>The new gTLD context is addressed in the draft RFC2821bis, which states:
>
>2.3.5.  Domain Names
>    A domain name (or often just a "domain") consists of one or more 
> components, separated by dots *if more than one appears*.   (emphasis added)
>
>Unfortunately, the current implementations are based on the original 
>RFC2821, not the revised draft. There may be a lot of software out 
>there that would treat user at tld as a local e-mail address (ie not FQDN).
>
>I am not aware of any study by SSAC on that matter (pointers 
>appreciated). Where I think it matters for the user community is 
>that we actually expect our e-mails to complaints at ebay or 
>support at apple to be delivered. I see here an opportunity for the 
>ALAC to ask ICANN for a report on this.
>
>Patrick
>
>
>_______________________________________________
>ALAC mailing list
>ALAC at atlarge-lists.icann.org
>http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
>
>At-Large Official Site: http://atlarge.icann.org