Subject: [xmpp] WGLC Comments on 6122bis

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 Mar 2015 17:30:38 -0500

(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?

-- 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?

-- 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?

-- 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..."

-- 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.)

Thanks!

/Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 Mar 2015 17:38:23 -0500

BTW, I reviewed version 19, quite by accident :-)

On 10 Mar 2015, at 17:30, Ben Campbell wrote:

> Localpart, but it contains an identifier that is interpreted 
> incorrectly by some SASL mechanism?
>
> escaped characters, it had to be prepared to receive them from 
> somewhere else, doesn't it?
>
> The sending client, receiving client, or both?  Assuming the former, 
> it might be worth adding some words to the effect of "before 
> transmitting..."
>
> -- 8:
>
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 10 Mar 2015 17:13:28 -0600

>> 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. :-)

>> 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.

>> 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).

>> it might be worth adding some words to the effect of "before

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.

>> 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

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 Mar 2015 19:51:31 -0500

On 10 Mar 2015, at 18:13, Peter Saint-Andre - &yet wrote:

> 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.

> 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...

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

> 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.

OTOH, that goes beyond the point of _this_ draft, so I'm okay leaving it 
as informational.

[...]

> 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 ;-) )

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 Mar 2015 20:11:26 -0500

On 10 Mar 2015, at 19:51, Ben Campbell wrote:

>> 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 
> So an identifier created with UsernameCaseMapped should be fine, but 
> an identifier created somewhere else in sasl might not be legal? That 

I realized shortly after sending this that that made no sense. It seems 
more likely that you would run into a previously created identifier that 
followed older rules--but you already discuss that in the intro.

Even so, it still might not hurt to mention the appendix.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 10 Mar 2015 19:15:40 -0600

> _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.

> suppose a client might display the raw string without unescaping, but

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

> not worried about _careful_ readers ;-) )

WFM!

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Mar 2015 21:24:50 -0500

On Mar 10, 2015, at 8:15 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:

> 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.

I'm sorry, were you expecting stateful reviewers? ;-)

So maybe adding something to effect of "see 6.1 of that doc for more details" would be enough. But I read the note to be about coexisting with or using of non-updated SASL mechanisms, while 6.1 seems more about migrating.