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/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
