Re: [precis] Review of current document draft-ietf-precis-framework-20

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Patrik,

On 11/26/14, 11:28 PM, Patrik Fältström wrote:
> I intend reading the mapping document today, sorry for the delay but
> $dayjob has been kind of ultra-busy...
>
> Note that most issues I have have to do with clarifications, and that
> it is not clear what the intent is.

Yes, I will reply to your big message next.

> Maybe a few where I urge caution. And they are definitely mapping
> related.

Clarifying question: are you talking about mapping in general (which 
might include width mapping, mapping non-ASCII space characters to ASCII 
space, case mapping, or in some nomenclatures even Unicode 
normalization), or only the kind of locale and context dependent mapping 
that is discussed in draft-ietf-precis-mappings?

> Let me phrase it this way:
>
> One of the problems with IDNA2003 was that it included mapping. It
> was unclear to people whether the client or server did the mapping.
> In reality the only place where mapping could exist for a stable
> protocol/implementation was between application/User Interface and
> where the protocol was really "doing things". So mapping was ripped
> out of IDNA when IDNA2008 was created.

In the PRECIS WG we've had quite a bit of discussion about the dividing 
line between application and protocol, or more precisely between between 
the user interface (which can more easily handle issues of culture, 
context, intent, locale, device limitations, etc.) and the actual use of 
conformant strings in protocol slots.

(Unfortunately, much of our most productive discussion has happened in 
sessions at IETF meetings, not on the list, so it's hard to find pointers.)

> Precis has decided mapping is still part of the protocol definition,

Well, draft-ietf-precis-mappings is only an informative reference from 
draft-ietf-precis-framework and with good reason: we reached the 
conclusion a few IETF meetings ago that we simply couldn't provide 
normative recommendations here.

> and I must understand where more exactly you expect mapping to
> happen, what happens if that mapping is not done, how to expect to do
> matching (comparison) between strings in the over all environment
> where it is possibly unknown whether mapping has been done or not,
> and specifically how it might impact the architecture in the cases
> where the mapping is destructive to the string itself (non-reversible
> mapping).
>
> I do not think it is clear in the framework WHERE mapping is to
> happen.

When you say "WHERE", do you mean (1) when in the process of handling an 
internationalized string or (2) by which entity in a protocol interaction?

I think we have been clear about (1), or at least we've tried to be 
clear - see for example Section 6 of draft-ietf-precis-framework.

I also think that the various profile documents and using protocols have 
been clear about (2) - see for instance Section 4 of 
draft-ietf-xmpp-6122bis.

> Maybe just some ascii art would make things easier to understand?

ASCII art always helps. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/