On 3 dec 2014, at 04:04, Peter Saint-Andre - &yet <[email protected]> wrote: > > 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?
I talk about any kind of transformation of a string. >> 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. Not surprising (and yes, I have seen some of this without claiming I did follow it). > (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. Ok. Which I think is fair and good. >> 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? Mainly (1) but that implies (2), right. > 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. That only specifies in what order the operations take place. It does not say when it happens. Example: A send a string X to B. B store the string, which can be a username or password. Later C send a string Y to B. B is to look up that string among stored strings, to see whether in this case X == Y or not. Where in the flow A -> B(store) - B(lookup) <- C are the steps in section 6 taking place? You have some string flowing between A and B(store), some string stored, some string flowing between C and B(lookup) and then some string is looked up. Which ones of these strings passed around have to live up to what requirements? > 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. :-) :-D Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
