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

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

On 12/2/14, 10:24 PM, Patrik Fältström wrote:
> 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?

Yes, that is very important, and we have tried to make that clear in 
application specs that are using PRECIS. For instance, 6122bis says:

    Enforcement entails applying all of the rules specified in this
    document.  Enforcement of the XMPP address format rules is the
    responsibility of XMPP servers.  Although XMPP clients SHOULD prepare
    complete JIDs and parts of JIDs in accordance with this document
    before including them in protocol slots within XML streams, XMPP
    servers MUST enforce the rules wherever possible and reject stanzas
    and other XML elements that violate the rules (for stanzas, by
    returning a <jid-malformed/> error to the sender as described in
    Section 8.3.3.8 of [RFC6120]).

    Entities that enforce the rules specified in this document are
    encouraged to be liberal in what they accept by following this
    procedure:

    1.  Where possible, map characters (e.g, through width mapping,
        additional mapping, special mapping, case mapping, or
        normalization) and accept the mapped string.

    2.  If mapping is not possible (e.g., because a character is
        disallowed in the FreeformClass), reject the string and return a
        <jid-malformed/> error.

    Enforcement applies to complete JIDs and to parts of JIDs.  To
    facilitate implementation, this document defines the concepts of "JID
    slot", "localpart slot", and "resourcepart slot" (similar to the
    concept of a "domain name slot" for IDNA2008 defined in
    Section 2.3.2.6 of [RFC5890]):

    JID Slot:  An XML element or attribute explicitly designated in XMPP
       or in XMPP extensions for carrying a complete JID.

    Localpart Slot:  An XML element or attribute explicitly designated in
       XMPP or in XMPP extensions for carrying the localpart of a JID.

    Resourcepart Slot:  An XML element or attribute explicitly designated
       in XMPP or in XMPP extensions for carrying the resourcepart of a
       JID.

    A server is responsible for enforcing the address format rules when
    receiving protocol elements from clients where the server is expected
    to handle such elements directly or to use them for purposes of
    routing a stanza to another domain or delivering a stanza to a local
    entity; two examples from [RFC6120] are the 'to' attribute on XML
    stanzas (which is a JID slot used by XMPP servers for routing of
    outbound stanzas) and the <resource/> child of the <bind/> element
    (which is a resourcepart slot used by XMPP servers for binding of a
    resource to an account for routing of stanzas between the server and
    a particular client).  An example from [RFC6121] is the 'jid'
    attribute of the roster <item/> element.

    A server is not responsible for enforcing the rules when the protocol
    elements are intended for communication among other entities,
    typically within the payload of a stanza that the server is merely
    routing to another domain or delivering to a local entity.  Two
    examples are the 'initiator' attribute in the Jingle extension
    [XEP-0166] (which is a JID slot used for client-to-client
    coordination of multimedia sessions) and the 'nick' attribute in the
    Multi-User Chat extension [XEP-0045] (which is a resourcepart slot
    used for administrative purposes in the context of XMPP chatrooms).
    In such cases, clients SHOULD enforce the rules themselves and not
    depend on the server to do so, and client implementers need to
    understand that not enforcing the rules can lead to a degraded user
    experience or to security vulnerabilities.  However, when an add-on
    service (e.g., a multi-user chat service) handles a stanza directly,
    it ought to enforce the rules as well, as defined in the relevant
    specification for that type of service.

Is that kind of text specific enough for you?

I think we need to define this at the level of the application protocol 
because that's where the rubber meets the road and where we can 
legitimately talk about the various entities involved (at the level of 
the PRECIS framework we don't know what the entities are and what their 
responsibilities are).

As another example, see this recent discussion in the PCP WG:

http://www.ietf.org/mail-archive/web/pcp/current/msg03819.html

Peter

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