Status of the mapping proposals?

Elisabeth Blanconil eblanconil at gmail.com
Mon Apr 27 00:17:07 CEST 2009


2009/4/26 Vint Cerf <vint at google.com>

> 1. At best I can barely make out what Elisabeth is talking about but in any
> case the thread does not strike me as relevant to our work
>
2. We are not going to change punycode at this point so complaints about its
> function are inappropriate to this WG
>

Dear Mr. Cerf,
at best I can barely make out what you are refering to.

- There is no issue about DNS.
- There no issue about punycode.
- There is no issue about finalizing mapping function.
- Along the charter there should be no issue about the location of the
mapping function.

So there should be no issue at all.

This is why I consider that the work of this WG is completed, except the
application developper information document by Patrick Falström. But I have
not understood if you wanted or not it to be a WG-IDNABIS deliverable.

What we need now is to finalize the mapping function and its application to
> IDN lookups in IDNA2008.
>

What needs to be defined is what "IDN lookups" can be. I plain words that I
can understand as a user there are two possibilities:

1. one is as per the charter: IDNs are mapped into regular LDH DNs at
application level, resulting in regular DN lookups. I am fully satisfied
with this option.

2. another one is not as per the charter: IDNs mapping is bundled with
lookup at protocol level, making the IDNA2008 scriptural space non
transparent, i.e. non neutral.  I understand you prefer that option.

If I am uncorrect, please explain me where.
Thank you !

Elisabeth Blanconil

 On Apr 26, 2009, at 12:27 AM, Elisabeth Blanconil wrote:

> 2009/4/25 Gervase Markham <gerv at mozilla.org>
>
>> On 24/04/09 18:27, Elisabeth Blanconil wrote:
>>
>>> There is nothing to object.
>>>
>>> The ".fra" project is destined to support the full French language
>>> scriptural bandwidth and therefore regular pragmatic environment. Our
>>> job is to support semantic addresses (i.e. also domain names) the
>>> semantic of which demands majuscules.
>>>
>>
>> [Apologies if this is old ground for people.]
>>
>> But in the current infrastructure, you can type capital letters into your
>> web browser and nothing breaks. It even continues to display those capital
>> letters to you. This doesn't require the DNS be case-sensitive. In effect,
>> DNS has built into it a mechanism were every possible case-variant of a name
>> is bundled together. Why does supporting the French language fully require
>> the ability for (the equivalents of) http://ABC.com and http://abc.com to
>> take you to different web sites?
>
>
> This is very simple. The real issue we (as an R&D group) is semiotic
> digital facilitation integration. This means that when some human wants to
> convey a meaning, a thought, he can use a very large number of mediatic
> artifacts. One of these artifacts is the character set attached to his
> natural language. If that character set is stable, it means that it
> represents the necessary scriptural bandwidth to carry every meaning people
> want to express or need to understand in the context of that natural
> language (syntax, metalanguage, usage, cultural back-ground, etc.)
>
> The French language calls at least for a scriptural bandwidth of 90
> characters. English language actually calls for at least 50. I say at least
> because we work on this with different centers of expertise and of
> authority. One of the reason is that French differentiate "majusculese" and
> "minuscules" and even in some cases "mediuscules". The latter case is the
> rule in France for postal addresses. Discrepancies with network addresses is
> something that would probably call for some serious legal review.
>
> There is a great difference in using a limited English script set as in the
> DNS as a technical patch, and reducing the French script set to that English
> script set, with all the undefined costs and confusion it would create at no
> identified advantage.
>
> Can you explain why case-*sensitivity* (as opposed to case-preserving) *in
>> the protocol* is necessary for your purposes?
>
>
> No one ever talked about "in the protocol" but the TATWEEL proposition that
> france at large and ASIWG did not support and would call for the work of this
> WG to come to a stop (as per the Charter).
>
> The Charter and every of us, I hope, agree that the protocol level MUST not
> affect, and MUST respect, the DNS. We are here speaking of Semantic
> Addresses which are not specific to the Internet and therefore belong to the
> "user application layer". It seems that we need to be very careful in
> avoiding to confuse network application, interapplication and user
> application layers. This also determines how to support the (virtual)
> presentation layer.
>
> In practical terms, it only means that "ABC" will be not be punycoded as
> "abc", as the current Internet default (by lack of) presentation layer does.
> The ".fra" presentation will therefore be different from the "default"
> internet presentation transparently to the DNS. Off-protocol mapping gives a
> full command to users over their Domain Name Applications (DNA).
>
> Best.
>
> Elisabeth Blanconil
>
> PS. I was busy with family business today. I hope I can have some Draft
> completed by Monday after-noon.
> _______________________________________________
> 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/20090427/c712cb75/attachment.htm 


More information about the Idna-update mailing list