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

On 6/9/15 5:04 AM, Barry Leiba wrote:
> 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.

Agreed.

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

Good points.

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

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.

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

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