Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-core-24

[Ballot comment]
This is my comment from December:
Note that this draft has xmpp-im-20 appended to it within the same file.
My noob is just to xmpp-core.

A comment related to -23
Because -22 won't be archived, I think it would be a good idea for the
diffs of 22 to 23 to be posted to the mailing list rather than placed on
an ephemeral website.  There should be a longer term record of the
WG process for these changes at this point in the document.

A comment on -24

I had a Discuss due to text added during RFC processing which appeared to
allow server implementations of change normative handling of stanzas if
they were different applications.  It was stated this was for conformance
testing, even of -im, but not clear to me what in -im was non-compliant
with -core.  The WG removed the added text and I cleared my Discuss.

[Ballot discuss]
I spent quite a while reviewing this document, because it would have
been better if the revisions made in AUTH48 were just clarifications,
or small conflicts that the Working Group could arbitrate.

I found that to be the case with the changes proposed for
draft-ietf-xmpp-im.  But one of the changes in -core-23 is not
just a cleanup or clarification, but a problem that would
affect implementation, new text which I think needs to be
removed again:

Here's the diff that I block this document on, text added at
the beginning of Section 10, Server Rules for Handling XML Stanzas.


  22:

  ... The following rules apply:

  23:

      ... The following rules apply to a "mere" XMPP server, but MAY
          be further specified or overridden by a particular class of
          application servers (e.g., an instant messaging and presence
          server as defined in [XMPP-IM]):

Section 10 specifies many SHOULDs and MUSTs.  The text as written
for revision -23 gives a free rein to changing the rules and the
normative levels.  Giving the benefit of the doubt, this is by
future specification, but not only by the specifications, but also
by implementations of particular classes of servers (again, as
written).  Even for the specification case, there's a concern,
because the normative rules in Section 10 include a number that
were part of a discussion of my original Discuss on Server handling
of XML stanzas related to IM interoperability.  I don't see changes
in the XMPP-IM specification that override these rules, so perhaps
this text is about allowing -IM server implementations leeway to
ignore SHOULDs.

Anyway, this is not appropriate standards text.  If a future
spec needs to modify a rule from CORE, it can state:  "This
rule changes CORE as follows for x reason."  Core should not
contain an open door like this.

So, bottom line:  remove the new text.

[Ballot comment]
This is my comment from December:
Note that this draft has xmpp-im-20 appended to it within the same file.
My noob is just to xmpp-core.

A comment related to -23
Because -22 won't be archived, I think it would be a good idea for the
diffs of 22 to 23 to be posted to the mailing list rather than placed on
an ephemeral website.  There should be a longer term record of the
WG process for these changes at this point in the document.

[Ballot discuss]
I spent quite a while reviewing this document, because it would have
been better if the revisions made in AUTH48 were just clarifications,
or small conflicts that the Working Group could arbitrate.

I found that to be the case with the changes proposed for
draft-ietf-xmpp-im.  But one of the changes in -core-23 is not
just a cleanup or clarification, but a problem that would
affect implementation, new text which I think needs to be
removed again:

Here's the diff that I block this document on, text added at
the beginning of Section 10, Server Rules for Handling XML Stanzas.


  22:

  ... The following rules apply:

  23:

      ... The following rules apply to a "mere" XMPP server, but MAY
          be further specified or overridden by a particular class of
          application servers (e.g., an instant messaging and presence
          server as defined in [XMPP-IM]):

Section 10 specifies many SHOULDs and MUSTs.  The text as written
for revision -23 gives a free rein to changing the rules and the
normative levels.  Giving the benefit of the doubt, this is by
future specification, but not only by the specifications, but also
by implementations of particular classes of servers (again, as
written).  Even for the specification case, there's a concern,
because the normative rules in Section 10 include a number that
were part of a discussion of my original Discuss on Server handling
of XML stanzas related to IM interoperability.  I don't see changes
in the XMPP-IM specification that override these rules, so perhaps
this text is about allowing -IM server implementations leeway to
ignore SHOULDs.

Anyway, this is not appropriate standards text.  If a future
spec needs to modify a rule from CORE, it can state:  "This
rule changes CORE as follows for x reason."  Core should not
contain an open door like this.

[Ballot discuss]
This is a Discuss for the revisions of the document following IESG approval (from
version 22 to version 23) - the diffs were placed on a website rather than
archived on the xmpp mailing list.  I think they should probably be archived.

[More coming...my systems are down]

[Ballot discuss]
4.2.1: The new text says to do a numerical comparison on version numbers.  Is that correct, to treat the numbers as decimals, so that 4.11 is older than 4.2?  I have no problem with that choice, but it's different enough from common usage that some clarification is needed, for either choice.

6.2: The relationship between SASL and TLS "names" and JIDs is not clear, and needs to be spelled out explicitly.  For example, how is a JID represented in a client-side certificate?  You note that the user-typed domain name is what needs to be verified in the TLS certificate; in precisely what field?  What about SASL user names?  Are resources part of the authentication name?

[Ballot comment]
These are both generally excellent specifications; clear, easy to follow, and
the unusually large number of  examples it contains makes it easy to see how
things are supposed to work. That said,  I have a number of comments:

The diagrams in sections 2.1, 4.1, 8.2, etc. aren't correctly aligned in the
HTML version; they are fine in the text version. (I guess this doesn't matter
since the RFC Editor only deals in the text version but I thought I'd mention
it.)

The term "TCP sockect" used in sections 2.3, 2.5, 4.1 and probably elsewhere
seems unnecessarily UNIX-y; how about "TCP connection" instead? (I looked at a
bunch of other RFCs and the general trend seems to be to use the term "TCP
socket" when talking about network socket APIs.)

Section 4.2 requires that ids be nonrepeating and unpredictable. Perhaps an
informative reference to RFC 1750 would be appropriate?

Section 4.6.2: It might be worthwhile to mention that the xml:lang element could
be used to select an appropriate language for  clauses in s.

Section 5.3 and 5.4: "Step 5: Server informs client to proceed:" ->
                    "Step 5: Server informs client that it is OK to proceed:"

This document makes frequent use of the capitalized term "NOT REQUIRED". This is
not one of the terms RFC 2119 defines. I believe these are equivalent to MAY or
OPTIONAL and the text should be modified accordingly. Alternately, a sentence
saying how "NOT REQUIRED" is to be interpreted could be added to section 1.2.

[Ballot discuss]
Even though I'm voting DISCUSS for now, I want to note that this spec was a pleasure to read -- it's much cleaner and clearer that most, even to someone with little knowledge of the area.

Most of these are nits, except for the ones marked with an asterisk.

1.4:  This is not quite compliant with our usual practice.  See 3.6 of draft-ietf-ipr-submission-rights-08.txt (which has been approved by the IESG) for details on trademarks.

In "Definition of XML Stanza" section: unbalanced close parenthesis

*4.2.1: The semantics of version processing, except for exact match, are poorly (and probably inappropriately) defined.  Ssee Section 2.5 of draft-ietf-ipsec-ikev2-11.txt for a detailed description of version number processing; in particular, note the difference between major and minor version number.  This is an important thing to get right, for future-proofing.

4.7 (and elsewhere):  use example.com for domain names

5.3: In the TLS negotiations, is any white space allowed after the  token?

*6.2: The relationship between SASL and TLS "names" and JIDs is not clear, and needs to be spelled out explicitly.  For example, how is a JID represented in a client-side certificate?  You note that the user-typed domain name is what needs to be verified in the TLS certificate; in precisely what field?  What about SASL user names?  Are resources part of the authentication name?

*8.3: The Stream ID used here is security-sensitive, and the required properties -- that it be unpredictable and non-repeating -- should be stated explicitly.

9.3: "not unrecoverable" is hard to parse...

9.3.2: -- says /&gr;

[Ballot discuss]
In section 14.1, 2nd paragraph, the text says: "Entities that
  communicate with the service SHOULD be configured with the Root CA
  certificate rather than the service certificate; this avoids problems
  associated with simple comparison of service certificates."  The
  practice that is being discouraged is simple, straightforward, and
  potentially more secure.  Further justification for the additional
  level of indirection is needed.
 
  In section 14.1, 2nd paragraph, the text says: "If a self-signed
  service certificate is used, an entity SHOULD NOT trust it if it is
  changed to another self-signed certificate or a certificate signed by
  an unrecognized authority."  I do not understand this sentence.
  The digital signature on a certificate prevents it from being
  undetectably changed.

[Ballot comment]
Section 1.3 should be deleted prior to publication.

  In section 5.1, the 7th numbered item is an introductory statement for
  the two cases listed in the 8th numbered item.  They should all be one
  numbered item.

  In section 5.3, Step 7 (alt), the text talks about 'Sever2'.  Yet, the
  scenario involves on client and one server.

  In section 9.2.3, the 2nd numbered item is an introductory statement for
  the cases listed in the 3rd numbered item.  They should all be one
  numbered item.

  An informative reference to RFC 3280 is desirable.  It will help
  someone trying to deal with certification path validation for TLS.

[Ballot discuss]
Even though I'm voting DISCUSS for now, I want to note that this spec was a pleasure to read -- it's much cleaner and clearer that most, even to someone with little knowledge of the area.

Most of these are nits, except for the ones marked with an asterisk.

1.4:  This is not quite compliant with our usual practice.  See 3.6 of draft-ietf-ipr-submission-rights-08.txt (which has been approved by the IESG) for details on trademarks.

In "Definition of XML Stanza" section: unbalanced close parenthesis

*4.2.1: The semantics of version processing, except for exact match, are poorly (and probably inappropriately) defined.  Ssee Section 2.5 of draft-ietf-ipsec-ikev2-11.txt for a detailed description of version number processing; in particular, note the difference between major and minor version number.  This is an important thing to get right, for future-proofing.

4.7 (and elsewhere):  use example.com for domain names

5.3: In the TLS negotiations, is any white space allowed after the  token?

*6.2: The relationship between SASL and TLS "names" and JIDs is not clear, and needs to be spelled out explicitly.  For example, how is a JID represented in a client-side certificate?  You note that the user-typed domain name is what needs to be verified in the TLS certificate; in precisely what field?  What about SASL user names?  Are resources part of the authentication name?

*8.3: I'm a bit puzzled by the challenge key semantics.  As I understand it, the  Receiving server is the suspicious party, or it wouldn't be dialing back.  But what we see is the Originating serve supplying a key that the authoritative server will verify.  Shouldn't that be the other way around?  That is, shouldn't the receiving server send a challenge to the originating server, and expect to see it coming back from the authoritative server?  Or is this not a security mechanism?  (If it is, and TLS isn't used, there's an attack.  A malicious originating server sees a key coming from a real originating server for some domain; it steals that key, and sends it to the receiving server.  The authoritative server is happy, because it's expecting to see that key.)  Note also that for security purposes, some function of the challenge is generally used, rather than simply repeating the challenge.

9.3: "not unrecoverable" is hard to parse...

9.3.2: 9.3.2 -- says /&gr;

[Ballot discuss]
Even though I'm voting DISCUSS for now, I want to note that this spec was a pleasure to read -- it's much cleaner and clearer that most, even to someone with little knowledge of the area.

Most of these are nits, except for the ones marked with an asterisk.

1.4:  This is not quite compliant with our usual practice.  See 3.6 of draft-ietf-ipr-submission-rights-08.txt (which has been approved by the IESG) for details on trademarks.

In "Definition of XML Stanza" section: unbalanced close parenthesis

*4.2.1: The semantics of version processing, except for exact match, are poorly (and probably inappropriately) defined.  Ssee Section 2.5 of draft-ietf-ipsec-ikev2-11.txt for a detailed description of version number processing; in particular, note the difference between major and minor version number.  This is an important thing to get right, for future-proofing.

4.7 (and elsewhere):  use example.com for domain names

5.3: In the TLS negotiations, is any white space allowed after the  token?

*6.2: The relationship between SASL and TLS "names" and JIDs is not clear, and needs to be spelled out explicitly.  For example, how is a JID represented in a client-side certificate?  You note that the user-typed domain name is what needs to be verified in the TLS certificate; in precisely what field?  What about SASL user names?  Are resources part of the authentication name?

*8.3: I'm a bit puzzled by the challenge key semantics.  As I understand it, the  Receiving server is the suspicious party, or it wouldn't be dialing back.  But what we see is the Originating serve supplying a key that the authoritative server will verify.  Shouldn't that be the other way around?  That is, shouldn't the receiving server send a challenge to the originating server, and expect to see it coming back from the authoritative server?  Or is this not a security mechanism?  (If it is, and TLS isn't used, there's an attack.  A malicious originating server sees a key coming from a real originating server for some domain; it steals that key, and sends it to the receiving server.  The authoritative server is happy, because it's expecting to see that key.)  Note also that for security purposes, some function of the challenge is generally used, rather than simply repeating the challenge.

9.3: "not unrecoverable" is hard to parse...

9.3.2: 9.3.2 -- says /^gr;