[Idna-arabicscript] mapping of Full Stops

[Vint Cerf]

Folks,

I think we might be able to come to a conclusion this way:

1. it is important that we agree that the canonical, exchange format  
for domain names contain ONLY U+002E as the label separator
2. UI contexts and practices will likely vary and reasonable choices  
for local use of "full-stop" characters will vary
3. The mappings document is essentially informational and notional,  
not prescriptive, so editing it as if it were normative is likely  
counterproductive
4. The idea of documenting UI practices seems useful, but, as I think  
Paul argues, this need not be the work of the IDNABIS working group.

If ICANN sees some value in (4) perhaps it can formulate a kind of  
"known mapping practices" registry (I hesitate to say "best  
practices") for various scripts (languages??)
I don't see this as an IETF function, however.

comments?

vint


On Oct 12, 2009, at 12:06 PM, Paul Hoffman wrote:

> At 11:13 AM -0400 10/12/09, John C Klensin wrote:
>> I don't either (see above about "harmless"), except that I think
>> it would be very unfortunate to have to reopen and re-review
>> this document in six months or a year when someone argues that
>> one or two of U+0589, U+1632, U+166E (a special case because I'm
>> sure Eric can advise us as to whether that request would be
>> likely to arise and be plausible), U+1803, and so on should be
>> added to the list for the same types of reasons as the ones
>> Sarmad describes.
>
> Fully agree. I can't speak for Pete, but I am not willing to re-open  
> the document to add characters to a list of optional characters. In  
> fact, I'm not even sure there will be a "we" around in six months:  
> the WG should close down after we have fulfilled our charter.
>
>> So I guess I'm making a recommendation about something I should
>> have spotted and made the recommendation about long ago: create
>> a registry for these things.
>
> And here we fully disagree. I think defining the rules for  
> registries for any of the optional parts of the document will take  
> at least another year, and we have already hit the exhaustion point.  
> I see absolutely no upside for a registry of optional suggestions  
> for an Informational RFC, with a significant downside of taking a  
> lot of review time that could be better spent elsewhere.
>
>> The reason for that is precisely
>> to prevent our needing to reopen the mapping document to add one
>> or more of these characters, not to treat them with more or less
>> authority.
>
> I see no "need" to reopen the document, ever. If someone wants to  
> prepare a document with a different view, or with the same view but  
> additional characters, that's fine, and quite easy in the RFC process.
>
>> I think such additions are extremely probable,
>> either as new scripts are added to Unicode or as communities
>> that are now unrepresented in this WG and probably
>> underrepresented on the Internet show up and explain their
>> needs.  Of course, YMMD on that likelihood assessment.
>
> We certainly agree on the likelihood of desired additions, but I  
> think not on the "need" for a revision to the WG's document.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update