RE: Re-opening discussion about Mapping

A direction I propose for the IRI document is to try
to be more careful to distinguish an "IRI" (as is a sequence
of characters in the unicode repertoire) from the 
"presentation of an IRI" which might be some ink on paper,
sound waves, or sequence of glyph codes for a font.

http://trac.tools.ietf.org/wg/iri/trac/ticket/5

Larry
--
http://larry.masinter.net


-----Original Message-----
From: idna-update-bounces@alvestrand.no on Behalf Of Patrik Fältström
Sent: Monday, February 08, 2010 2:16 PM
To: Lisa Dusseault
Cc: idna-update@alvestrand.no; Vint Cerf
Subject: Re: Re-opening discussion about Mapping

Part from standing behind what Vint wrote in his response, let me answer more directly the questions from Lisa.

I am a developer/designer of mostly web based software for management of domain names, web sites, email services and what not. I will (and want to be able to) in my interfaces first of all be pretty sure over what data comes to me as a "server". I.e. I want to know what the end user really wanted to give me (I did explicitly not say "typed" here for reasons I hope people understand).

Now, if the web browser (if the web browser was used) did some trick and converted some characters, then I do not get the characters the end user typed (for example), but regardless of this, I will do whatever I want to do to make the end user happy. Exactly what that implies will differ depending on context. Is this domain name management or management of a web site, or the management of email addresses or sites?

Is this mapping, if applied, to be implemented in the browser or in the web server? I would like to get as raw data as possible, without having the browser doing anything, so that I know as much as possible on the server side. So I can "help" users the same way browsers today "help" users by adding ".COM" TLD if that is not added. "guessing" I think it can be called.

And if HTTP/Web browser is not in use, but instead for example an iPhone application that then interact over JSON/Netstring/TCP with some server API, then I can in a more direct way control what is sent to the server (if I also write the client). I will only be confused (possibly) over the mapping that is in the operating system / user interface libraries.


All of this might sounds like if it will make things messier for the user, but in reality I do not think so. *NO* developer have the interest in making this messier for the user. And exactly what it means to make it easier for the user depends on context. Very much. Specifically when we have so many protocols and environments and contexts where domain names are in use.

Saying just "no mapping at registration time" is not good enough for me. What about if you want to change the holder or adminc or techc of a domain? Should you do mapping then, if the domain name is typed by the user or not? Is a transfer of a domain name "registration time"?

No, I rather see that I as a developer can do whatever I want to make things easier for the users, and that might include that I try to do some mappings of codepoints that are not PVALID, or complete changes of some things that might be domain names (hard to know sometimes) to something that are domain names (different separators between labels for example).

So to answer your question Lisa: No, it is not clear what characters are suggested to be mapped, but we do not even know where or who has the responsibility to do the mapping -- if any. In the case of HTTP, is that done in the web browser or on the server side, in the cgi?

For example how do a web browser know whether the ajax / json call is to be "a registration" or not? A situation when mapping should explicitly not occur? It can not, and because of that browsers should not include any mapping at all. Ever.

That is one view, and of course you can find the arguments the other way around as well.

And this is why I think the current mapping document is as good as we can get it -- and why I think (like Pete) TR46 is too strong. Because it is very wrong to explicitly ask for mappings the way it does.

What *might* be ok and good to do is to say what codepoints can be mapped in various contexts to other characters, but I think for example the definition of bundles in the IANA registries to some degree do that. When not mapping from PVALID to other PVALID of course. So that people know that IF one work in a specific context (certain language for example), THEN it MIGHT be interesting to map from A to B.

So I would say the mapping document we have is good.

   Patrik

On 8 feb 2010, at 20.33, Lisa Dusseault wrote:

> In order to be able to handle the mappings document, should the WG choose to
> put it forward, I would like to understand as part of this discussion:
> - implementation intentions  -- who plans to implement mappings and in what
> context (e.g user typing? user click on URL?)
> - clarity -- is it clear which characters are suggested to be mapped, e.g.
> so that we understand the difference from what characters were required to
> be mapped in IDNA2003
> 
> thanks,
> Lisa
> 
> On Sun, Feb 7, 2010 at 2:35 PM, Vint Cerf <vint@google.com> wrote:
> 
>> Please see the attached, rather longish PDF. It is intended to try to move
>> the discussion forward on the matter of the mappings question.
>> 
>> The WG has previously agreed that:
>> 
>> 1. there will be no mapping in the registration process. labels in
>> registered domain names must be in U-label or A-label form, satisfying all
>> the validity criteria of the now-adopted normative IDNA2008 documents.
>> 
>> 2. The mapping discussion emerging from IDNABIS should not be normative
>> 
>> Vint
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>> 
>> 
> _______________________________________________
> Idna-update mailing list
> Idna-update@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

Received on Monday, 15 March 2010 23:53:04 UTC