Subject: [xmpp] Barry Leiba's Yes on draft-ietf-xmpp-6122bis-23: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 09 Jun 2015 04:04:59 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-xmpp-6122bis-23: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would make the RFC 6365 reference normative.

The ABNF definition for localpart would benefit from citing
[draft-ietf-precis-saslprepbis] by "UsernameCaseMapped profile". 
Similarly for "OpaqueString profile" in the definition of "resourcepart".
 (And, by the way, I wouldn't put quotation marks around the profile
names.)

The first paragraph of Section 3.2 defines a particular parsing order,
which will affect a JID such as in example 15, way down below.  I think
it's worth explicitly saying that here, to reduce the likelihood that
such JIDs might be mis-parsed.  You do mention it in the note explaining
example 15, but it'd be useful to highlight it here.

In Section 3.3.1, I find the "i.e."s to be distracting clutter, and
mildly recommend rendering those lines like this:
 
      U+0022 (QUOTATION MARK): "
      U+0026 (AMPERSAND): &

In example 21, it might be more fun to use PILE OF POO (U+1F4A9) instead.
 Or maybe not...

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 09 Jun 2015 09:27:04 -0600

> https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

Agreed.

>   (And, by the way, I wouldn't put quotation marks around the profile

Good points.

> example 15, but it'd be useful to highlight it here.

Yes, that would be helpful because the order does matter. I suggest:

OLD

    The domainpart of a JID is that portion which remains once any
    portion from the first '/' character to the end of the string has
    been removed (if there is a '/' character present), and then any
    portion from the beginning of the string to the first '@' character
    (if there is a '@' character present).

NEW

    The domainpart of a JID is that portion which remains once the
    following parsing steps are taken:

    1.  Remove any portion from the first '/' character to the end of the
        string (if there is a '/' character present).

    2.  Remove any portion from the beginning of the string to the first
        '@' character (if there is a '@' character present).

    This parsing order is important, as illustrated by example 15 in
    Section 3.5.

>        U+0022 (QUOTATION MARK): "

This might be confusing...

U+003A (COLON): :

So I'll change the order to:

       " U+0022 (QUOTATION MARK)

       & U+0026 (AMPERSAND)

       ' U+0027 (APOSTROPHE)

       / U+002F (SOLIDUS)

       : U+003A (COLON)

       < U+003C (LESS-THAN SIGN)

       > U+003E (GREATER-THAN SIGN)

       @ U+0040 (COMMERCIAL AT)

Peter

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Jun 2015 17:41:46 +0100

Hi, Peter; thanks for the response.

>    This parsing order is important, as illustrated by example 15 in

Nice; thanks.

> This might be confusing...

Ah, true.

>       > U+003E (GREATER-THAN SIGN)

Yes, that's a good way to handle it.

b