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

[Patrik Fältström <[e-mail]>]

On 3 dec 2014, at 04:04, Peter Saint-Andre - &yet <[e-mail]> 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