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@ASCII-TLD and not xxx@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@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@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@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@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@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@ebay or support@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@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org