[At-Large] News gTLDs and e-mail

Thu Jul 3 14:24:21 EDT 2008

JFC and all,

  One very important thing you left out here is that SMTP and
ESMTP protocols will need to be updated as well.  I don't see
that happening in the near term.  So Patricks concern he raised
still remains to the vast majority of Internet users.  Than the additional
problem is of "Upgrade" by service providers.  Some, if not most
Email server applications will need significant modification.  Of course
this is not a ICANN problem or concern, nor an IETF problem or
concern.

  Frankly as a result of the above and below ( JFC's remarks )
I don't see IDN gTLD's as being widely supported but I also see
no good reason to not making them avaliable either.

JFC Morfin wrote:

> 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
>
> _______________________________________________
> 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

Regards,

Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1 at ix.netcom.com
My Phone: 214-244-4827