mixing different direction labels within same domain

J-F C. Morfin jfc at morfin.org
Wed Sep 7 14:06:41 CEST 2011

At 23:22 06/09/2011, Harald Alvestrand wrote:
>On 08/10/2011 10:29 AM, Abdulrahman I. ALGhadir wrote:
>>Well in this case the protocol didn't give any standard solution 
>>way to handle this problem rather letting it to be treated as 
>>vendor wish (shouldn't the rfc enacts in making standards) or at 
>>least to acknowledge this issue and to push it to another level 
>>e.g.  Unicode URI rendering?
>The group discussed the problem of detecting the presence of domain 
>names in free text, and the consequences of having domain names 
>display differently when apps treated them as domain names and when 
>apps treated them as free text.
>The conclusion was that detecting domain names in free text is just 
>about impossible, and that consistent behaviour is important to 
>users; thus, the WG did not recommend any special treatment for 
>domain names, choosing rather to live with the results of the 
>existing BIDI algorithm.


Pleae remember my first question to Vint when we started this WG: was 
the WG work intended to address the network technology issues with 
IDNs or the users' needs. The response by James Seng that Vint did 
endorse, our final consensus, and Harald's position today are 
consistant: to only address the network technology issues.

If you remember I had many reasons to oppose the WG's orientation for 
its lack of intent to support orthotypography (the scripting syntax 
of languages). However the RFC 5895 proposition clearly addressed 
this issue. It shown that de facto the principle of subsidiarity was 
the Internet response to diversity from its very inception. It was 
"unusual" but the diversity was to be addressed outside of the 
Internet ends. Actually, most probably at the fringes that the IAB 
declared out of its scope in response to my appeals. This is why we 
introduced the IDNA2010 term to label the coordination of the 
needed  "outside" definitions, i.e. the equivalent to the Internet 
side IDNA2008, this time on the User side. And why we foresaw 
IDNA2012 as the place to address the architectural overall implications.

These two IDNA2010 and IDNA2012 work concern other protocols (cf. the 
external implications of the WG/PRECIS), the variants (cf. 
ICANN/WG/VIP), the implication of the IANA and the support of the 
registries demanded by the subsidiary solution, including an overall 
review of the SDNS (subsidiary DN system) of which IDNA2008 has 
firmly established the core (the current DNS), etc. and necessarily 
the support of orthotypography which is mandatory in our French case 

Now, the homographic and variant issues have shown that Unicode is 
not sufficent enough to address the needs of the networked use needs. 
They call for a WDE (whole digital ecosystem) orthotypography and 
canonalization algorithms. The response of the IESG '(we were several 
to ask for various reasons) has been to adopt IDNA2008 without 
investigating further about the IDNA architecture and the Internet 
Use needs as did the AD. Now, we can build.

You probably may chose to implement subsidiarity to address diversity 
in diverse manners. All of them will necessarily belong to 
metacommunications, understanding that there are three communications strata:

- the telecommunications stratum, where the necessary metadata are in 
the copper, on a plug to plug basis. Layer 0.Basic services.
- the datacommunications stratum, where the necessary metadata are in 
the header of the datagram container. Onionly added and pealed by 
(ISO 1 to 7) layers on an end to end value added services basis.
- the metacommunications stratum, where the additional metadata are 
pouring from everywhere through fringe to fringe intelligent/extended 
services protocols.

As you know the IETF is not a metacommunications body.

In addition, what you ask for is pure orthotypography of the texts 
used in an Internet (or any other technology also using domain names) 
context. This is pure digital Internetwork orthotypography. It first 
must be defined (and this why the IUCG collects descriptions of the 
different needs), and then documented in not IETF, non Internet, but 
in InterUse protocol terms that may be ported by many different 
media, including Unicode if you want - but probably in using some 
special or user reserved code-point that you may embed/act upon in 
applications or though OPESes.


>><mailto:idna-update-bounces at alvestrand.no>idna-update-bounces at alvestrand.no 
>>[mailto:idna-update-bounces at alvestrand.no] On Behalf Of Harald Alvestrand
>>Sent: 7/Aug/2011 11:55 PM
>>To: Abdulrahman I. ALGhadir
>>Cc: <mailto:idna-update at alvestrand.no>idna-update at alvestrand.no
>>Subject: Re: mixing different direction labels within same domain
>>On 06/21/11 07:55, Abdulrahman I. ALGhadir wrote:
>>Dear all,
>>I am just wondering whenever it is permitted or not to have this case:
>><r2l chars><num1>.<num2>.<etc ..>
>>This particular case has all labels legal, but the overall display 
>>name will display very oddly (as noted). The oddity is caused by 
>>our inability to mandate whole-domain tests, as described in the RFC.
>>It is logical for the administrator of <etc ..> to forbid 
>>registration of leading-numeric labels if it anticipates R2L labels 
>>at the next level down, and it is logical for application writers 
>>to simply reject such names because they are going to confuse the 
>>users (much in the spirit of Firefox' refusal to do mixed-script 
>>names), but the RFC does not require them to do so.
>>As you know in case r2l labels the display will be like this
>><etc..>.<num1>.<num2><r2l chars>
>>I think the display will depend on the direction of <etc> and 
>>whether it is in an RTL context or an LTR context, but I'm still 
>>not confident of my ability to execute the BIDI algorithm in my head.
>>As you see both of them have different display order which 
>>isn't  the same as network order.
>>And I know it is mentioned in the RFC
>>    Several stronger statements were considered and rejected, because
>>    they seem to be impossible to fulfill within the constraints of the
>>    Unicode bidirectional algorithm.
>>And one of the statement is
>>   o  The sequence of labels should be consistent with network order.
>>       This proved impossible -- a domain name consisting of the labels
>>       in network order) L1.R2.R3.L4 will be displayed as L1.R3.R2.L4 in
>>       an LTR context.  (In an RTL context, it will be displayed as
>>       L4.R3.R2.L1)
>>And I have tried two implemented tools (well I don't know if they 
>>follow the RFC fully or not).
>>Idna-update mailing list
>><mailto:Idna-update at alvestrand.no>Idna-update at alvestrand.no
>Idna-update mailing list
>Idna-update at alvestrand.no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110907/888561a6/attachment.html>

More information about the Idna-update mailing list