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.
Abulrahman,
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
(http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt).
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.
jfc
>>
>>
>>From:
>><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).
>>
>>
>><http://unicode.org/cldr/utility/idna.jsp?a=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9#notes>http://unicode.org/cldr/utility/idna.jsp?a=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9#notes
>>
>>http://mct.verisign-grs.com/conversiontool/convertServlet?input=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9&type=UTF8
>>
>>
>>Abdulrahman,
>>
>>
>>
>>_______________________________________________
>>Idna-update mailing list
>><mailto:Idna-update at alvestrand.no>Idna-update at alvestrand.no
>>http://www.alvestrand.no/mailman/listinfo/idna-update
>
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update
-------------- 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