Re: [xmpp] WGLC Comments on 6122bis

On 3/10/15 6:51 PM, Ben Campbell wrote:
> On 10 Mar 2015, at 18:13, Peter Saint-Andre - &yet wrote:
>
>> 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. :-)
>
> I guess I should have said "... here", but needing 5 references probably
> argues against doing it again. :-) It just sort of looked strange that
> it was missing while the next phrase had a reference.
>
>>
>>>> -- 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.
>
> So an identifier created with UsernameCaseMapped should be fine, but an
> identifier created somewhere else in sasl might not be legal? That
> _seems_ unlikely to be a problem...

Right.

> It might not hurt to mention the saslprepbis appendix in the note.

Actually, Section 6.1 of draft-ietf-precis-saslprepbis is an even better 
pointer because it describes the differences in more detail, with an eye 
toward migration from Stringprep to PRECIS. You might want to re-read 
that section to determine the level of your concern.

>>>> -- 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).
>
> So a server would just operate on the escaped string without worrying
> about the fact. Got it. OTOH, this draft applies to clients, too. I
> suppose a client might display the raw string without unescaping, but
> that would be ugly.

Yes, but it's interoperably ugly! ;-)

> OTOH, that goes beyond the point of _this_ draft, so I'm okay leaving it
> as informational.
>
> [...]
>
>>>> -- 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.
>
>
> How about adding something more specific. For example, something to the
> effect of the following (to either the current text or with your
> proposed addition):
>
> "[RFC2119] keywords in this section are intended to describe the
> referenced normative text."
>
> (A careful reader will figure out the right thing without it. But I'm
> not worried about _careful_ readers ;-) )

WFM!

Peter

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

_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis