Re: [precis] WGLC Comments on 6122bis

On 3/10/15 4:38 PM, Ben Campbell wrote:
> BTW, I reviewed version 19, quite by accident :-)
>
> On 10 Mar 2015, at 17:30, Ben Campbell wrote:
>
>> (as individual)
>>
>> Hi,
>>
>> This is a very well written draft. It's easy to understand given the
>> complexity of the material. I support it's publication.
>>
>> I have a few minor comments:
>>
>> -- section 3.2, paragraph 6:
>>
>> Is there a reason to avoid a reference for IDNA2008?

Well, IDNA2008 is collectively RFCs 5890-5894 and we do point to several 
of those specs in §3.2. :-)

>> -- 3.3, implementation note:
>>
>> Are there any practical consequences for the implementor? Are there
>> potential conflicts where the XMPP implementation correctly forms a
>> Localpart, but it contains an identifier that is interpreted
>> incorrectly by some SASL mechanism?

Re-using the UsernameCaseMapped profile from 
draft-ietf-precis-saslprepbis should help in this regard. However, as 
noted, some SASL mechanisms might not be upgraded quickly and thus would 
still use SASLprep (RFC 4013). The differences are explained a bit more 
in Appendix A of draft-ietf-precis-saslprepbis - as I see it, the only 
semi-major issue is that certain characters that were "mapped to 
nothing" in RFC 4013 are simply disallowed by the UsernameCaseMapped 
profile that we re-use in 6122bis.

>> -- 3.3.1, implementation note:
>>
>> I have mixed feelings about XEP-0106 being an informational reference
>> (using the standard of "need to read to understand/implement this
>> document"). Even if an implementation chooses not to create JIDs with
>> escaped characters, it had to be prepared to receive them from
>> somewhere else, doesn't it?

Well, the alternative is to reject the JID - but since the escaping 
mechanism in XEP-0106 is really a matter of presentation, it's something 
that affects clients more than servers anyway (and the JID escaping 
would be applied before PRECIS-related processing happens anyway).

>> -- 4, para 10 (I think): "In such cases, clients SHOULD enforce..."
>>
>> The sending client, receiving client, or both?  Assuming the former,
>> it might be worth adding some words to the effect of "before
>> transmitting..."

Good catch. We might want to say "the entities involved SHOULD enforce", 
because in the second example there the chatroom might enforce the rules 
(so it's not just about clients) and more importantly it's not always a 
good idea to trust the sender.

>> -- 8:
>>
>> While I don't object to the approach of the section, I think there's
>> some risk of confusion about which text is authoritative from a 2119
>> perspective. I think it might be worth noting that the authoritative
>> text is in the referenced sections, and only summarized here for
>> convenience.  (It only really matters if they conflict, but redundant
>> normative text makes life harder for future updates.)

I see your point: it's never a great idea to say the same thing in two 
places.

We do say:

    This section describes a protocol feature set that summarizes the
    conformance requirements of this specification....

We could add a sentence like:

    The summary is purely informational and does not override any of the
    more detailed descriptions in the body of this specification.

Peter