Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-3920bis-22

[Ballot comment]
4.6.  Stream Attributes

  The attributes of the root  element are defined in the
  following sections.

      Security Note: Until and unless the confidentiality and integrity
      of a stream header is ensured via Transport Layer Security as
      described under Section 5, the attributes provided in a stream
      header could be tampered with by an attacker.

Or SASL security layer (e.g. GSSAPI).


8.3.3.13.  policy-violation

  The entity has violated some local service policy (e.g., a message
  contains words that are prohibited by the service); the server MAY
  choose to specify the policy in the  element or in an
  application-specific condition element; the associated error type
  SHOULD be "modify" or "wait" depending on the policy being violated.


  (In the following example, the client sends an XMPP message that is
  too large according to the server's local service policy.)

It might be better to change the description to mention prohibited words (e.g. "!!!").
Otherwise this looks too similar to .

  C:
        %#&@^!!!
     

[Ballot comment]
-21 addresses my concerns and comments sufficiently.

I encourage future standarization of a mechanism to "fail this stanza if it would go over a hop that isn't TLS protected".

I also encourage future work tightening the specification in section 10.5.3.2 around the words "SHOULD deliver to at least one of the connected resources". I understand from email conversation that this text was crafted to account for existing implementations of advanced message delivery logic, but it leaves the door open to lazy or arbitrary implementations (such as one that may just choose a connected resource at random, or might use some ill-defined notion of "most recently active"). This has been a source of bad user experience for me.

[Ballot comment]
4.6.  Stream Attributes

  The attributes of the root  element are defined in the
  following sections.

      Security Note: Until and unless the confidentiality and integrity
      of a stream header is ensured via Transport Layer Security as
      described under Section 5, the attributes provided in a stream
      header could be tampered with by an attacker.

Or SASL security layer (e.g. GSSAPI).


8.3.3.13.  policy-violation

  The entity has violated some local service policy (e.g., a message
  contains words that are prohibited by the service); the server MAY
  choose to specify the policy in the  element or in an
  application-specific condition element; the associated error type
  SHOULD be "modify" or "wait" depending on the policy being violated.


  (In the following example, the client sends an XMPP message that is
  too large according to the server's local service policy.)

It might be better to change the description to mention prohibited words (e.g. "!!!").
Otherwise this looks too similar to .

  C:
        %#&@^!!!
     


----NEW----

      Service providers SHOULD include the
      DNS-ID identifier type in certificate requests.

XMPP Service providers?

[Ballot discuss]
[I now finished reading the whole document, but there might be a couple of more issues that I am planning to raise later. New comments in each section since the last time are after the "----NEW----" marker]

I am not really surprised, but this is a very well written document. Some quick comments/questions before I can recommend approving it:

8) SASL error condition extensibility

[Ballot comment]
Section 3.2.1 says:

  6.  If the initiating entity fails to connect using that IP address
      but the "A" or "AAAA" lookup returned more than one IP address,
      then the initiating entity uses the next resolved IP address for
      that hostname as the connection address.

I think this is slightly confusing. It sounds like the entity decides
to use A (or AAAA) and sticks with that choice. I think what you want
is ... the "A" or "AAAA" lookups returned more than one IP address...

My colleague Ari Keränen reviewed this specification and had a few
comments:

The abstract should state that this document obsoletes RFC 3920.

1.4.  Terminology

    The term "whitespace" is used to refer to any character that matches
    production [3] content of [XML]

It's not immediately clear what "production [3]" means here (same issue
in sections 4.1 and 11.5) since it looks like a numeric reference.
Perhaps something like "content of production [3] defined in [XML]"
would be clearer.


4.6.3.  id

Aren't there any restrictions on the content of the ID attribute, e.g.,
max/min length (in addition to what is defined in [RANDOM]) and allowed
characters?


4.6.5.  version

    defined value of the 'type' attribute for message, presence, or IQ
    stanzas).  The minor version number MUST be ignored by an entity with

The "IQ" stanza is mentioned multiple times before it's definition. A
brief explanation, e.g., in the section 2 and a reference to section
8.2.3 would help uninitiated readers. It might make sense to move the
whole section 8.2 much earlier to the draft (say, to the beginning of
section 4), so that all the examples would be more clear.


4.8.3.12.  not-authorized

In the example, the stream element sent by the server is missing ">".
Same problem also at least in sections 4.8.3.25, 6.4.1, 6.4.6, 9.1.1.,
and 9.1.2.


4.8.3.19.  see-other-host

It would be good to be more explicit about the format of the IP address
and port (especially) with IPv6. The example shows how IPv6 address
should be sent (with the brackets) but the text doesn't say anything
about that and implementers may easily get it wrong. Also, it could make
sense to recommend to follow RFC 5952 convention with the IPv6 addresses.


The "required" element could be more explicitly defined (now it's
mentioned in the context of TLS, but I'd assume it can be used with
other features too).


8.3.3.13.  policy-violation

    (In the following example, the client sends an XMPP message that is
    too large according to the server's local service policy.)

The example does not seem to match with the text above. Also, the type
in the example is "cancel" while it "SHOULD be modify or wait" according
to the spec.

[Ballot comment]
My colleague Ari Keränen reviewed this specification and had a few
comments:

The abstract should state that this document obsoletes RFC 3920.

1.4.  Terminology

    The term "whitespace" is used to refer to any character that matches
    production [3] content of [XML]

It's not immediately clear what "production [3]" means here (same issue
in sections 4.1 and 11.5) since it looks like a numeric reference.
Perhaps something like "content of production [3] defined in [XML]"
would be clearer.


4.6.3.  id

Aren't there any restrictions on the content of the ID attribute, e.g.,
max/min length (in addition to what is defined in [RANDOM]) and allowed
characters?


4.6.5.  version

    defined value of the 'type' attribute for message, presence, or IQ
    stanzas).  The minor version number MUST be ignored by an entity with

The "IQ" stanza is mentioned multiple times before it's definition. A
brief explanation, e.g., in the section 2 and a reference to section
8.2.3 would help uninitiated readers. It might make sense to move the
whole section 8.2 much earlier to the draft (say, to the beginning of
section 4), so that all the examples would be more clear.


4.8.3.12.  not-authorized

In the example, the stream element sent by the server is missing ">".
Same problem also at least in sections 4.8.3.25, 6.4.1, 6.4.6, 9.1.1.,
and 9.1.2.


4.8.3.19.  see-other-host

It would be good to be more explicit about the format of the IP address
and port (especially) with IPv6. The example shows how IPv6 address
should be sent (with the brackets) but the text doesn't say anything
about that and implementers may easily get it wrong. Also, it could make
sense to recommend to follow RFC 5952 convention with the IPv6 addresses.


The "required" element could be more explicitly defined (now it's
mentioned in the context of TLS, but I'd assume it can be used with
other features too).


8.3.3.13.  policy-violation

    (In the following example, the client sends an XMPP message that is
    too large according to the server's local service policy.)

The example does not seem to match with the text above. Also, the type
in the example is "cancel" while it "SHOULD be modify or wait" according
to the spec.

[Ballot discuss]
A very substantial piece of work: thanks.

I checked through the Errata raised against RFC 3920 and cannot satisfy myself that the issue raised in 1406 (http://www.rfc-editor.org/errata_search.php?eid=1406) has been addressed. The idea was, I think, simply to qualify the use of digests in examples to prevent anyone attempting to deduce meaning from them.

Does anything need to be added to this revision?

[Ballot discuss]
The summary of changes since RFC 3920 includes:

  o  Specified that the SASL SCRAM mechanism is a mandatory-to-
      implement technology for client-to-server streams.
  o  Specified that TLS plus the SASL PLAIN mechanism is a mandatory-
      to-implement technology for client-to-server streams.
  o  Specified that support for the SASL EXTERNAL mechanism is required
      for servers but only recommended for clients (since end-user X.509
      certificates are difficult to obtain and not yet widely deployed).

  Yet, the Gen-ART Review from Elwyn Davies on 29 November 2010 says:

  There seems to be a lack of clarity or definiteness about the effects
  of support of SASL being mandatory.  There are a number of places in
  the document where the text is written as if SASL were not mandatory,
  and others where the reverse is true but the surrounding text doesn't
  seem to think it is mandatory..  All these places need to be looked
  at critically to ensure that the wording is appropriate for SASL
  being mandatory and that the whole is consistent.

  I do not want to block or delay this document, but it seems that this
  issue can easily be resolved while handling the items raised in the
  DISCUSS position entered by Alexey.

[Ballot comment]
1.4.  Terminology

  The term "whitespace" is used to refer to any character that matches
  production [3] content of [XML], i.e., any instance of the SP, HTAB,
  CR, or LF rules defined in [ABNF].

Any single character or multiple characters?

3.2.1.  Preferred Process: SRV Lookup

  3.  If a response is received, it will contain one or more
      combinations of a port and hostname, each of which is weighted
      and prioritized as described in [DNS-SRV].  However, if the
      result of the SRV lookup is a single resource record with a
      Target of ".", i.e. the root domain, then the initiating entity
      MUST abort SRV processing at this point (but SHOULD attempt the
      fallback process described in the next section).

[...]

  7.  If the initiating entity fails to connect using all resolved IP
      addresses for a given hostname, then it repeats the process of
      resolution and connection for the next hostname returned by the
      SRV lookup.

While this is implied, it might be better to point out that the "next" is
selected based on priority/weight from [DNS-SRV].

3.2.2.  Fallback Processes

  For client-to-server connections, the fallback MAY be a [DNS-TXT]

Is this Normative? It looks like it is.

  lookup for alternative connection methods, for example as described
  in [XEP-0156].

3.2.3.  When Not to Use SRV

  If the initiating entity has been explicitly configured to associate
  a particular hostname (and potentially port) with the origin domain
  of the receiving entity (say, to "hardcode" an association from an
  origin domain of example.net to a configured hostname of
  webcm.example.com:80), the initiating entity SHOULD use the

Is use of port 80 a good example in this document?


4.2.2.  Stream Features Format

  A  element MAY contain more than one mandatory feature.
  This means that the initiating entity can choose among the mandatory
  features.  For example, perhaps a future technology will perform
  roughly the same function as TLS, so the receiving entity might
  advertise support for both TLS and the future technology.

So if the server requires both TLS and SASL, does this mean that it first
advertises TLS as required (and SASL is either advertised as optional or not advertised),
and then once TLS negotiation is complete, SASL needs to be advertised as required
(on the restarted stream)?

4.2.7.  Flow Chart

In the flowchart - is "receive stream features" required after each negotiation
of a voluntary feature?

4.6.  Stream Attributes

  The attributes of the root  element are defined in the
  following sections.

      Security Note: Until and unless the confidentiality and integrity
      of a stream header is ensured via Transport Layer Security as
      described under Section 5, the attributes provided in a stream
      header could be tampered with by an attacker.

Or SASL security layer (e.g. GSSAPI).

4.7.2.  Content Namespace

  When a content namespace is not declared as the default namespace and
  so-called "prefix-free canonicalization" is used instead, in rough
  outline a stream will look something like the following.

 
   
      foo
   
 

Should the closing tag be  above?

4.7.4.  Namespace Declarations and Prefixes

  An implementation MUST NOT generate namespace prefixes for elements
  qualified by the content namespace if the content namespace is
  'jabber:client' or 'jabber:server' (e.g., ).  An XMPP

Can you try to explain this again, you lost me here.

  entity MUST NOT accept data that violates this rule (in particular,
  an XMPP server MUST NOT route or deliver such data to another
  entity); instead it MUST either ignore the data or return a stream
  error (which SHOULD be ).

5.4.3.1.  Rules

  7.  Following successful TLS negotiation, all further data
      transmitted by either party MUST be encrypted.

Did you really meant "encrypted" here? What about use of NULL ciphers
with integrity protection?

5.4.3.3.  TLS Success

  R:
       
          EXTERNAL
          PLAIN
       
     

This should include SCRAM-SHA-1 :-), as it is an MTI.

6.3.3.  Mechanism Preferences

  Any entity that will act as a SASL client or a SASL server MUST
  maintain an ordered list of its preferred SASL mechanisms according
  to the client or server, where the list is ordered according to local
  policy or user configuration (which SHOULD be in order of perceived
  strength to enable the strongest authentication possible).  A server
  MUST offer and a client MUST try SASL mechanisms in preference order.

Is this clear that server's and client's preference orders are different?

  For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
  GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
  is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
  SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).

6.3.7.  Simple User Name

  Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
  that the authentication identity used in the context of such
  mechanisms is a "simple user name" (see Section 2 of [SASL] as well
  as [SASLPREP]).  The exact form of the simple user name in any
  particular mechanism or deployment thereof is a local matter, and a
  simple user name does not necessarily map to an application
  identifier such as a JID or JID component (e.g., a localpart).
  However, in the absence of local information provided by the server,
  an XMPP client SHOULD assume that the authentication identity for
  such a SASL mechanism is a simple user name equal to the localpart of
  the user's JID.

Or bare JID? I believe many implementations based on Cyrus SASL allow full email-like syntax here.

6.3.9.  Realms

  The receiving entity MAY include a realm when negotiating certain
  SASL mechanisms.  If the receiving entity does not communicate a
  realm, the initiating entity MUST NOT assume that any realm exists.
  The realm MUST be used only for the purpose of authentication; in
  particular, an initiating entity MUST NOT attempt to derive an XMPP
  hostname from the realm information provided by the receiving entity.

Should this be clearer about which mechanisms are we talking about?
IMHO, being vague is not being helpful here.

8.3.1.  Rules

  4.  An error stanza MUST contain an  child element.

  7.  An  child MUST NOT be included if the 'type' attribute
      has a value other than "error" (or if there is no 'type'
      attribute).

Are these 2 in conflict? If they are not, should they be combined into a single rule?


8.3.3.13.  policy-violation

  The entity has violated some local service policy (e.g., a message
  contains words that are prohibited by the service); the server MAY
  choose to specify the policy in the  element or in an
  application-specific condition element; the associated error type
  SHOULD be "modify" or "wait" depending on the policy being violated.


  (In the following example, the client sends an XMPP message that is
  too large according to the server's local service policy.)

It might be better to change the description to mention prohibited words (e.g. "!!!").
Otherwise this looks too similar to .

  C:
        %#&@^!!!
     

13.7.2.2.1.  Case #1

  If the client certificate appears to be certified by a certification
  path terminating in a trust anchor (as described in Section 6.1 of
  [PKIX]), the server MUST check the certificate for any instances of
  the XmppAddr as described under Section 13.7.1.4.  There are three
  possible sub-cases:

  Sub-Case #1:  The server finds one XmppAddr for which the domainpart
      of the represented JID matches one of the configured hostnames of
      the server; the server SHOULD use this represented JID as the
      validated identity of the client.

  Sub-Case #2:  The server finds more than one XmppAddr for which the
      domainpart of the represented JID matches one of the configured
      hostnames of the server; the server SHOULD use one of these
      represented JIDs as the validated identity of the client, choosing
      among them according to local service policies or based on the
      'to' address of the initial stream header.

What if the client has multiple accounts on the same server and they use
the same certificate? (I admit that that might be an obscure case.)
Should the server be using the 'from' value to differentiate as well?

13.9.4.  Use of SASL

  Many deployed XMPP services authenticate client connections by means
  of passwords.  It is well-known that most human users choose
  relatively weak passwords.  Although service provisioning is out of
  scope for this document, XMPP servers that allow password-based
  authentication SHOULD enforce minimal criteria for password strength
  to help prevent dictionary attacks.  Because all password-based
  authentication mechanisms are susceptible to password guessing
  attacks, XMPP servers MUST implement common rate-limiting
  mitigations.

Rate-limiting during SASL authentication?

13.9.5.  Use of TLS

  Implementations of TLS typically support multiple versions of the
  Transport Layer Security protocol as well as the older Secure Sockets
  Layer (SSL) protocol.  Because of known security vulnerabilities,
  XMPP servers and clients MUST NOT request, offer, or use SSL 2.0.
  See Appendix E.2 of [TLS] for further details.

This should probably point to draft-ietf-tls-ssl2-must-not. The reference doesn't need to be normative.

----NEW----

      Service providers SHOULD include the
      DNS-ID identifier type in certificate requests.

XMPP Service providers?

[Ballot discuss]
[I now finished reading the whole document, but there might be a couple of more issues that I am planning to raise later. New comments in each section since the last time are after the "----NEW----" marker]

I am not really surprised, but this is a very well written document. Some quick comments/questions before I can recommend approving it:

1)
4.5.3.  Idle Peer

  Even if the underlying TCP connection is alive and the stream is not
  broken, the peer might have sent no stanzas for a certain period of
  time.  In this case, the peer SHOULD close the stream using the
  handshake described under Section 4.4.

SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it decides to close it?

  If the idle peer does not
  close the stream, the other party MAY either close the stream using
  the handshake described under Section 4.4 or return a stream error
  (e.g.,  if the entity has reached a limit on
  the number of open TCP connections or  if the
  connection has exceeded a local timeout policy).  However, consistent
  with the order of layers (specified under Section 13.3), the other
  party is advised to verify that the underlying TCP connection is
  alive and the stream is unbroken (as described above) before
  concluding that the peer is idle.  Furthermore, it is preferable to
  be liberal in accepting idle peers, since experience has shown that
  doing so improves the reliability of communication over XMPP networks
  and that it is typically more efficient to maintain a stream between
  two servers than to aggressively timeout such a stream.

This is arguing for MAY above.

2)
4.6.4.  xml:lang

  o  If the receiving entity supports a language that closely matches
      the initiating entity's preferred language (e.g., "de" instead of
      "de-CH"),

I think you really need to be referencing Section 3.4 of RFC 4647 for this,
as the process you describe above is not very formal (and might introduce
wrong results if coded by a naive implementor).

      then the value of the 'xml:lang' attribute SHOULD be the
      identifier for the matching language (e.g., "de") but MAY be the
      identifier for the default language of the receiving entity (e.g.,
      "en").

3)
5.3.5.  TLS Renegotiation

  Support for TLS renegotiation is strictly OPTIONAL.  However,
  implementations that support TLS renegotiation MUST implement and use
  the TLS Renegotiation Extension [TLS-NEG].

This makes [TLS-NEG] a Normative Reference.

4)
6.4.2.  Initiation

  If the initiating entity subsequently sends another  element
  (even if the ongoing authentication handshake has not yet completed),
  the server SHOULD discard the ongoing handshake and begin a new
  handshake for the subsequently requested SASL mechanism.

What are the possible conditions for violating the SHOULD?
The server really MUST fail the existing handshake, but maybe it doesn't have
to begin a new handshake (e.g. it might choose to close the connection instead?).

5) DISCUSS DISCUSS

  [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              3.2.0", 2000.

              The Unicode Standard, Version 3.2.0 is defined by The
              Unicode Standard, Version 3.0 (Reading, MA, Addison-
              Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
              Unicode Standard Annex #27: Unicode 3.1
              (http://www.unicode.org/reports/tr27/) and by the Unicode
              Standard Annex #28: Unicode 3.2
              (http://www.unicode.org/reports/tr28/).

Should this be upgraded to at least Unicode 5.1?

6)
13.8.2.  For Confidentiality Only

  For confidentiality only, servers SHOULD support TLS with the
  TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.

Why only a SHOULD?

----NEW----

7) TLS-server-identity documents requires that protocols referencing it explicitly specify if wildcards are allowed in certificates. XMPP Core is silent on this, yet it shows some examples of certificates with wildcards.

[Ballot comment]
Please consider clarifying that you are not requiring elements to reject streams that use a prefix with
the literal value "stream", only that you are allowing them to do so to allow legacy implementations to be
compliant. It might help to be even more explicit that clients that chose not to use the literal "stream"
prefix may have interoperability problems with those legacy implementations. Also consider pointing to this
exception to the general principal of allowing the sender to set the string it uses as a prefix label in the
section on page 124 (where you note that "receiving entities MUST NOT depend on the prefix strings to have
any particular value.")

Some additional explanation of SRV's resolving to "." meaning "don't use SRV" would help.
Why is this mechanism there?

In 4.2.5 - Please consider a little more explanation on why an initiating element might send stanzas to itself?

Please consider adding forward pointers from the keep-alive sections (such as 4.5.1) to the requirement
to not send whitespace during TLS and SASL negotiation. (5.3.3, 6.3.5)

In 4.8.3.9 - "not a valid JID" may be ambiguous - is it intended to include "not well formed"?

In 5.3.5 - what does "blindly attempt" mean? why is the requirement around it SHOULD NOT?
When is it OK to blindly attempt?

In 5.4.3.3 - the "Implementation Note:" actually contains a normative requirement defining protocol behavior.
Similarly, 8.3.3.14 has a Security Note with normative requirements. I strongly suggest moving actual
protocol requirements out of those notes.

In 6.3.8 - Can you provide a reference to where is the behavior for acting on the behalf of another party is specified?

In 6.4.6  - Can you add some text justifying why the entity SHOULD terminate the connection attempt
if the from identity and the SASL authentication identity do not match, and why this is a SHOULD not a MUST?

In 8.3.3.15 : This section doesn't provide a way to protect against redirect loops (such as see-other-host did). Should it?

In 10.4.1 : should this "will" be a MUST?

In 13.1 : has the group considered a "fail this stanze if it would go over a hop that isn't TLS protected" request extension?

[Ballot discuss]
This is a solid document. I have one major point (the first below) that I would like to discuss.
I expect the remaining points to be easy to address (or be convinced to remove them after discussion).

1) This draft requires that an intial stream be established before starting TLS negotiation,
  and requires (at SHOULD strength) that the stream element that is sent in the clear
  have a from attribute identifying the user if known. It doesn't feel right to require a
  privacy leak like that. Would it make more sense to elide the from if the client knows
  it wants to try using TLS, or at least provide a way to use a from that couldn't be used
  by third parties to identify the user?

2) Section 3.2.2's MAY seems to make [DNS-TXT] and [XEP-0156] normative.

3) Section 4.4 - why is the specified behavior for the element that sends a closing stream tag defined
  as a SHOULD? When is it ok for the element to do something different, and what would it do?

4) Section 8.3.1 - Does "generated stanza" mean "the stanza that caused an error to be generated"?
  Can you provide more detail about why swapping the to and from are SHOULD (I can't figure out what
  in section 13.10 would have you not simply swap.)

5) page 137 (delivery related attack point 2) : this paragraph "How a server ... bare JID." does not parse.

6) Section 10.5.3.1 The second bullet seems to make [XMPP-IM] a normative reference. There were other
  places in the document where [XMPP-IM] seemed to be required reading in order to build a conformant
  implementation.

7) Section 10.5.3.2 : Why, for a message stanza, do you say SHOULD deliver to at least one matching resource?
  Why is this not a MUST, and why do you allow something between one and all?

8) Section 13.10.1 : It's not clear what you really mean by "make the IP address or method of access public".
  How do you test this MUST NOT? Can you give examples of what you're worried a server implemenation  might
  do in error?

9) Section 13.12, item 4 : this 10000 is a magic number - please consider calling out that it was arbitrarily
  chosen. More importantly, please add text disuading implementers from chosing to set a limit of 10000 bytes
  by default.

[Ballot discuss]
The summary of changes since RFC 3920 includes:

  o  Specified that the SASL SCRAM mechanism is a mandatory-to-
      implement technology for client-to-server streams.
  o  Specified that TLS plus the SASL PLAIN mechanism is a mandatory-
      to-implement technology for client-to-server streams.
  o  Specified that support for the SASL EXTERNAL mechanism is required
      for servers but only recommended for clients (since end-user X.509
      certificates are difficult to obtain and not yet widely deployed).

  Yet, the Gen-ART Review from Elwyn Davies on 29 November 2010 says:

  There seems to be a lack of clarity or definiteness about the effects
  of support of SASL being mandatory.  There are a number of places in
  the document where the text is written as if SASL were not mandatory,
  and others where the reverse is true but the surrounding text doesn't
  seem to think it is mandatory..  All these places need to be looked
  at critically to ensure that the wording is appropriate for SASL
  being mandatory and that the whole is consistent.

  I do not want to block or delay this document, but it seems that this
  issue can easily be resolved while handling the items raised in the
  DISCUSS position entered by Alexey.

[Ballot comment]
1.4.  Terminology

  The term "whitespace" is used to refer to any character that matches
  production [3] content of [XML], i.e., any instance of the SP, HTAB,
  CR, or LF rules defined in [ABNF].

Any single character or multiple characters?

3.2.1.  Preferred Process: SRV Lookup

  3.  If a response is received, it will contain one or more
      combinations of a port and hostname, each of which is weighted
      and prioritized as described in [DNS-SRV].  However, if the
      result of the SRV lookup is a single resource record with a
      Target of ".", i.e. the root domain, then the initiating entity
      MUST abort SRV processing at this point (but SHOULD attempt the
      fallback process described in the next section).

[...]

  7.  If the initiating entity fails to connect using all resolved IP
      addresses for a given hostname, then it repeats the process of
      resolution and connection for the next hostname returned by the
      SRV lookup.

While this is implied, it might be better to point out that the "next" is
selected based on priority/weight from [DNS-SRV].

3.2.2.  Fallback Processes

  For client-to-server connections, the fallback MAY be a [DNS-TXT]

Is this Normative? It looks like it is.

  lookup for alternative connection methods, for example as described
  in [XEP-0156].

3.2.3.  When Not to Use SRV

  If the initiating entity has been explicitly configured to associate
  a particular hostname (and potentially port) with the origin domain
  of the receiving entity (say, to "hardcode" an association from an
  origin domain of example.net to a configured hostname of
  webcm.example.com:80), the initiating entity SHOULD use the

Is use of port 80 a good example in this document?


4.2.2.  Stream Features Format

  A  element MAY contain more than one mandatory feature.
  This means that the initiating entity can choose among the mandatory
  features.  For example, perhaps a future technology will perform
  roughly the same function as TLS, so the receiving entity might
  advertise support for both TLS and the future technology.

So if the server requires both TLS and SASL, does this mean that it first
advertises TLS as required (and SASL is either advertised as optional or not advertised),
and then once TLS negotiation is complete, SASL needs to be advertised as required
(on the restarted stream)?

4.2.7.  Flow Chart

In the flowchart - is "receive stream features" required after each negotiation
of a voluntary feature?

4.6.  Stream Attributes

  The attributes of the root  element are defined in the
  following sections.

      Security Note: Until and unless the confidentiality and integrity
      of a stream header is ensured via Transport Layer Security as
      described under Section 5, the attributes provided in a stream
      header could be tampered with by an attacker.

Or SASL security layer (e.g. GSSAPI).

4.7.2.  Content Namespace

  When a content namespace is not declared as the default namespace and
  so-called "prefix-free canonicalization" is used instead, in rough
  outline a stream will look something like the following.

 
   
      foo
   
 

Should the closing tag be  above?

4.7.4.  Namespace Declarations and Prefixes

  An implementation MUST NOT generate namespace prefixes for elements
  qualified by the content namespace if the content namespace is
  'jabber:client' or 'jabber:server' (e.g., ).  An XMPP

Can you try to explain this again, you lost me here.

  entity MUST NOT accept data that violates this rule (in particular,
  an XMPP server MUST NOT route or deliver such data to another
  entity); instead it MUST either ignore the data or return a stream
  error (which SHOULD be ).

5.4.3.1.  Rules

  7.  Following successful TLS negotiation, all further data
      transmitted by either party MUST be encrypted.

Did you really meant "encrypted" here? What about use of NULL ciphers
with integrity protection?

5.4.3.3.  TLS Success

  R:
       
          EXTERNAL
          PLAIN
       
     

This should include SCRAM-SHA-1 :-), as it is an MTI.

6.3.3.  Mechanism Preferences

  Any entity that will act as a SASL client or a SASL server MUST
  maintain an ordered list of its preferred SASL mechanisms according
  to the client or server, where the list is ordered according to local
  policy or user configuration (which SHOULD be in order of perceived
  strength to enable the strongest authentication possible).  A server
  MUST offer and a client MUST try SASL mechanisms in preference order.

Is this clear that server's and client's preference orders are different?

  For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
  GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
  is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
  SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).

6.3.7.  Simple User Name

  Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
  that the authentication identity used in the context of such
  mechanisms is a "simple user name" (see Section 2 of [SASL] as well
  as [SASLPREP]).  The exact form of the simple user name in any
  particular mechanism or deployment thereof is a local matter, and a
  simple user name does not necessarily map to an application
  identifier such as a JID or JID component (e.g., a localpart).
  However, in the absence of local information provided by the server,
  an XMPP client SHOULD assume that the authentication identity for
  such a SASL mechanism is a simple user name equal to the localpart of
  the user's JID.

Or bare JID? I believe many implementations based on Cyrus SASL allow full email-like syntax here.

6.3.9.  Realms

  The receiving entity MAY include a realm when negotiating certain
  SASL mechanisms.  If the receiving entity does not communicate a
  realm, the initiating entity MUST NOT assume that any realm exists.
  The realm MUST be used only for the purpose of authentication; in
  particular, an initiating entity MUST NOT attempt to derive an XMPP
  hostname from the realm information provided by the receiving entity.

Should this be clearer about which mechanisms are we talking about?
IMHO, being vague is not being helpful here.

8.3.1.  Rules

  4.  An error stanza MUST contain an  child element.

  7.  An  child MUST NOT be included if the 'type' attribute
      has a value other than "error" (or if there is no 'type'
      attribute).

Are these 2 in conflict? If they are not, should they be combined into a single rule?


8.3.3.13.  policy-violation

  The entity has violated some local service policy (e.g., a message
  contains words that are prohibited by the service); the server MAY
  choose to specify the policy in the  element or in an
  application-specific condition element; the associated error type
  SHOULD be "modify" or "wait" depending on the policy being violated.


  (In the following example, the client sends an XMPP message that is
  too large according to the server's local service policy.)

It might be better to change the description to mention prohibited words (e.g. "!!!").
Otherwise this looks too similar to .

  C:
        %#&@^!!!
     

----NEW----

13.7.2.2.1.  Case #1

  If the client certificate appears to be certified by a certification
  path terminating in a trust anchor (as described in Section 6.1 of
  [PKIX]), the server MUST check the certificate for any instances of
  the XmppAddr as described under Section 13.7.1.4.  There are three
  possible sub-cases:

  Sub-Case #1:  The server finds one XmppAddr for which the domainpart
      of the represented JID matches one of the configured hostnames of
      the server; the server SHOULD use this represented JID as the
      validated identity of the client.

  Sub-Case #2:  The server finds more than one XmppAddr for which the
      domainpart of the represented JID matches one of the configured
      hostnames of the server; the server SHOULD use one of these
      represented JIDs as the validated identity of the client, choosing
      among them according to local service policies or based on the
      'to' address of the initial stream header.

What if the client has multiple accounts on the same server and they use
the same certificate? (I admit that that might be an obscure case.)
Should the server be using the 'from' value to differentiate as well?

13.9.4.  Use of SASL

  Many deployed XMPP services authenticate client connections by means
  of passwords.  It is well-known that most human users choose
  relatively weak passwords.  Although service provisioning is out of
  scope for this document, XMPP servers that allow password-based
  authentication SHOULD enforce minimal criteria for password strength
  to help prevent dictionary attacks.  Because all password-based
  authentication mechanisms are susceptible to password guessing
  attacks, XMPP servers MUST implement common rate-limiting
  mitigations.

Rate-limiting during SASL authentication?

13.9.5.  Use of TLS

  Implementations of TLS typically support multiple versions of the
  Transport Layer Security protocol as well as the older Secure Sockets
  Layer (SSL) protocol.  Because of known security vulnerabilities,
  XMPP servers and clients MUST NOT request, offer, or use SSL 2.0.
  See Appendix E.2 of [TLS] for further details.

This should probably point to draft-ietf-tls-ssl2-must-not.

[Ballot discuss]
[I now finished reading the whole document, but there might be a couple of more issues that I am planning to raise later. New comments in each section since the last time are after the "----NEW----" marker]

I am not really surprised, but this is a very well written document. Some quick comments/questions before I can recommend approving it:

1)
4.5.3.  Idle Peer

  Even if the underlying TCP connection is alive and the stream is not
  broken, the peer might have sent no stanzas for a certain period of
  time.  In this case, the peer SHOULD close the stream using the
  handshake described under Section 4.4.

SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it decides to close it?

  If the idle peer does not
  close the stream, the other party MAY either close the stream using
  the handshake described under Section 4.4 or return a stream error
  (e.g.,  if the entity has reached a limit on
  the number of open TCP connections or  if the
  connection has exceeded a local timeout policy).  However, consistent
  with the order of layers (specified under Section 13.3), the other
  party is advised to verify that the underlying TCP connection is
  alive and the stream is unbroken (as described above) before
  concluding that the peer is idle.  Furthermore, it is preferable to
  be liberal in accepting idle peers, since experience has shown that
  doing so improves the reliability of communication over XMPP networks
  and that it is typically more efficient to maintain a stream between
  two servers than to aggressively timeout such a stream.

This is arguing for MAY above.

2)
4.6.4.  xml:lang

  o  If the receiving entity supports a language that closely matches
      the initiating entity's preferred language (e.g., "de" instead of
      "de-CH"),

I think you really need to be referencing Section 3.4 of RFC 4647 for this,
as the process you describe above is not very formal (and might introduce
wrong results if coded by a naive implementor).

      then the value of the 'xml:lang' attribute SHOULD be the
      identifier for the matching language (e.g., "de") but MAY be the
      identifier for the default language of the receiving entity (e.g.,
      "en").

3)
5.3.5.  TLS Renegotiation

  Support for TLS renegotiation is strictly OPTIONAL.  However,
  implementations that support TLS renegotiation MUST implement and use
  the TLS Renegotiation Extension [TLS-NEG].

This makes [TLS-NEG] a Normative Reference.

4)
6.4.2.  Initiation

  If the initiating entity subsequently sends another  element
  (even if the ongoing authentication handshake has not yet completed),
  the server SHOULD discard the ongoing handshake and begin a new
  handshake for the subsequently requested SASL mechanism.

What are the possible conditions for violating the SHOULD?
The server really MUST fail the existing handshake, but maybe it doesn't have
to begin a new handshake (e.g. it might choose to close the connection instead?).

5) DISCUSS DISCUSS

  [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              3.2.0", 2000.

              The Unicode Standard, Version 3.2.0 is defined by The
              Unicode Standard, Version 3.0 (Reading, MA, Addison-
              Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
              Unicode Standard Annex #27: Unicode 3.1
              (http://www.unicode.org/reports/tr27/) and by the Unicode
              Standard Annex #28: Unicode 3.2
              (http://www.unicode.org/reports/tr28/).

Should this be upgraded to at least Unicode 5.1?

----NEW----

6)
13.8.2.  For Confidentiality Only

  For confidentiality only, servers SHOULD support TLS with the
  TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.

Why only a SHOULD?

[Ballot comment]
1.4.  Terminology

  The term "whitespace" is used to refer to any character that matches
  production [3] content of [XML], i.e., any instance of the SP, HTAB,
  CR, or LF rules defined in [ABNF].

Any single character or multiple characters?

3.2.1.  Preferred Process: SRV Lookup

  3.  If a response is received, it will contain one or more
      combinations of a port and hostname, each of which is weighted
      and prioritized as described in [DNS-SRV].  However, if the
      result of the SRV lookup is a single resource record with a
      Target of ".", i.e. the root domain, then the initiating entity
      MUST abort SRV processing at this point (but SHOULD attempt the
      fallback process described in the next section).

[...]

  7.  If the initiating entity fails to connect using all resolved IP
      addresses for a given hostname, then it repeats the process of
      resolution and connection for the next hostname returned by the
      SRV lookup.

While this is implied, it might be better to point out that the "next" is
selected based on priority/weight from [DNS-SRV].

3.2.2.  Fallback Processes

  For client-to-server connections, the fallback MAY be a [DNS-TXT]

Is this Normative? It looks like it is.

  lookup for alternative connection methods, for example as described
  in [XEP-0156].

3.2.3.  When Not to Use SRV

  If the initiating entity has been explicitly configured to associate
  a particular hostname (and potentially port) with the origin domain
  of the receiving entity (say, to "hardcode" an association from an
  origin domain of example.net to a configured hostname of
  webcm.example.com:80), the initiating entity SHOULD use the

Is use of port 80 a good example in this document?


4.2.2.  Stream Features Format

  A  element MAY contain more than one mandatory feature.
  This means that the initiating entity can choose among the mandatory
  features.  For example, perhaps a future technology will perform
  roughly the same function as TLS, so the receiving entity might
  advertise support for both TLS and the future technology.

So if the server requires both TLS and SASL, does this mean that it first
advertises TLS as required (and SASL is either advertised as optional or not advertised),
and then once TLS negotiation is complete, SASL needs to be advertised as required
(on the restarted stream)?

4.2.7.  Flow Chart

In the flowchart - is "receive stream features" required after each negotiation
of a voluntary feature?

4.6.  Stream Attributes

  The attributes of the root  element are defined in the
  following sections.

      Security Note: Until and unless the confidentiality and integrity
      of a stream header is ensured via Transport Layer Security as
      described under Section 5, the attributes provided in a stream
      header could be tampered with by an attacker.

Or SASL security layer (e.g. GSSAPI).

4.7.2.  Content Namespace

  When a content namespace is not declared as the default namespace and
  so-called "prefix-free canonicalization" is used instead, in rough
  outline a stream will look something like the following.

 
   
      foo
   
 

Should the closing tag be  above?

4.7.4.  Namespace Declarations and Prefixes

  An implementation MUST NOT generate namespace prefixes for elements
  qualified by the content namespace if the content namespace is
  'jabber:client' or 'jabber:server' (e.g., ).  An XMPP

Can you try to explain this again, you lost me here.

  entity MUST NOT accept data that violates this rule (in particular,
  an XMPP server MUST NOT route or deliver such data to another
  entity); instead it MUST either ignore the data or return a stream
  error (which SHOULD be ).

5.4.3.1.  Rules

  7.  Following successful TLS negotiation, all further data
      transmitted by either party MUST be encrypted.

Did you really meant "encrypted" here? What about use of NULL ciphers
with integrity protection?

5.4.3.3.  TLS Success

  R:
       
          EXTERNAL
          PLAIN
       
     

This should include SCRAM-SHA-1 :-), as it is an MTI.

6.3.3.  Mechanism Preferences

  Any entity that will act as a SASL client or a SASL server MUST
  maintain an ordered list of its preferred SASL mechanisms according
  to the client or server, where the list is ordered according to local
  policy or user configuration (which SHOULD be in order of perceived
  strength to enable the strongest authentication possible).  A server
  MUST offer and a client MUST try SASL mechanisms in preference order.

Is this clear that server's and client's preference orders are different?

  For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
  GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
  is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
  SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).

6.3.7.  Simple User Name

  Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
  that the authentication identity used in the context of such
  mechanisms is a "simple user name" (see Section 2 of [SASL] as well
  as [SASLPREP]).  The exact form of the simple user name in any
  particular mechanism or deployment thereof is a local matter, and a
  simple user name does not necessarily map to an application
  identifier such as a JID or JID component (e.g., a localpart).
  However, in the absence of local information provided by the server,
  an XMPP client SHOULD assume that the authentication identity for
  such a SASL mechanism is a simple user name equal to the localpart of
  the user's JID.

Or bare JID? I believe many implementations based on Cyrus SASL allow full email-like syntax here.

6.3.9.  Realms

  The receiving entity MAY include a realm when negotiating certain
  SASL mechanisms.  If the receiving entity does not communicate a
  realm, the initiating entity MUST NOT assume that any realm exists.
  The realm MUST be used only for the purpose of authentication; in
  particular, an initiating entity MUST NOT attempt to derive an XMPP
  hostname from the realm information provided by the receiving entity.

Should this be clearer about which mechanisms are we talking about?
IMHO, being vague is not being helpful here.

----NEW----

8.3.1.  Rules

  4.  An error stanza MUST contain an  child element.

  7.  An  child MUST NOT be included if the 'type' attribute
      has a value other than "error" (or if there is no 'type'
      attribute).

Are these 2 in conflict? If they are not, should they be combined into a single rule?


8.3.3.13.  policy-violation

  The entity has violated some local service policy (e.g., a message
  contains words that are prohibited by the service); the server MAY
  choose to specify the policy in the  element or in an
  application-specific condition element; the associated error type
  SHOULD be "modify" or "wait" depending on the policy being violated.


  (In the following example, the client sends an XMPP message that is
  too large according to the server's local service policy.)

It might be better to change the description to mention prohibited words (e.g. "!!!").
Otherwise this looks too similar to .

  C:
        %#&@^!!!
     

[Ballot discuss]
[This is the initial version of my comments. I only finished reading section 12 at this point. New comments in each section since the last time are after the "----NEW----" marker]

I am not really surprised, but this is a very well written document. Some quick comments/questions before I can recommend approving it:

1)
4.5.3.  Idle Peer

  Even if the underlying TCP connection is alive and the stream is not
  broken, the peer might have sent no stanzas for a certain period of
  time.  In this case, the peer SHOULD close the stream using the
  handshake described under Section 4.4.

SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it decides to close it?

  If the idle peer does not
  close the stream, the other party MAY either close the stream using
  the handshake described under Section 4.4 or return a stream error
  (e.g.,  if the entity has reached a limit on
  the number of open TCP connections or  if the
  connection has exceeded a local timeout policy).  However, consistent
  with the order of layers (specified under Section 13.3), the other
  party is advised to verify that the underlying TCP connection is
  alive and the stream is unbroken (as described above) before
  concluding that the peer is idle.  Furthermore, it is preferable to
  be liberal in accepting idle peers, since experience has shown that
  doing so improves the reliability of communication over XMPP networks
  and that it is typically more efficient to maintain a stream between
  two servers than to aggressively timeout such a stream.

This is arguing for MAY above.

----NEW----

2)
4.6.4.  xml:lang

  o  If the receiving entity supports a language that closely matches
      the initiating entity's preferred language (e.g., "de" instead of
      "de-CH"),

I think you really need to be referencing Section 3.4 of RFC 4647 for this,
as the process you describe above is not very formal (and might introduce
wrong results if coded by a naive implementor).

      then the value of the 'xml:lang' attribute SHOULD be the
      identifier for the matching language (e.g., "de") but MAY be the
      identifier for the default language of the receiving entity (e.g.,
      "en").

3)
5.3.5.  TLS Renegotiation

  Support for TLS renegotiation is strictly OPTIONAL.  However,
  implementations that support TLS renegotiation MUST implement and use
  the TLS Renegotiation Extension [TLS-NEG].

This makes [TLS-NEG] a Normative Reference.

4)
6.4.2.  Initiation

  If the initiating entity subsequently sends another  element
  (even if the ongoing authentication handshake has not yet completed),
  the server SHOULD discard the ongoing handshake and begin a new
  handshake for the subsequently requested SASL mechanism.

What are the possible conditions for violating the SHOULD?
The server really MUST fail the existing handshake, but maybe it doesn't have
to begin a new handshake (e.g. it might choose to close the connection instead?).

5) DISCUSS DISCUSS

  [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              3.2.0", 2000.

              The Unicode Standard, Version 3.2.0 is defined by The
              Unicode Standard, Version 3.0 (Reading, MA, Addison-
              Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
              Unicode Standard Annex #27: Unicode 3.1
              (http://www.unicode.org/reports/tr27/) and by the Unicode
              Standard Annex #28: Unicode 3.2
              (http://www.unicode.org/reports/tr28/).

Should this be upgraded to at least Unicode 5.1?

[Ballot comment]
1.4.  Terminology

  The term "whitespace" is used to refer to any character that matches
  production [3] content of [XML], i.e., any instance of the SP, HTAB,
  CR, or LF rules defined in [ABNF].

Any single character or multiple characters?

3.2.1.  Preferred Process: SRV Lookup

  3.  If a response is received, it will contain one or more
      combinations of a port and hostname, each of which is weighted
      and prioritized as described in [DNS-SRV].  However, if the
      result of the SRV lookup is a single resource record with a
      Target of ".", i.e. the root domain, then the initiating entity
      MUST abort SRV processing at this point (but SHOULD attempt the
      fallback process described in the next section).

[...]

  7.  If the initiating entity fails to connect using all resolved IP
      addresses for a given hostname, then it repeats the process of
      resolution and connection for the next hostname returned by the
      SRV lookup.

While this is implied, it might be better to point out that the "next" is
selected based on priority/weight from [DNS-SRV].

3.2.2.  Fallback Processes

  For client-to-server connections, the fallback MAY be a [DNS-TXT]

Is this Normative? It looks like it is.

  lookup for alternative connection methods, for example as described
  in [XEP-0156].

3.2.3.  When Not to Use SRV

  If the initiating entity has been explicitly configured to associate
  a particular hostname (and potentially port) with the origin domain
  of the receiving entity (say, to "hardcode" an association from an
  origin domain of example.net to a configured hostname of
  webcm.example.com:80), the initiating entity SHOULD use the

Is use of port 80 a good example in this document?


4.2.2.  Stream Features Format

  A  element MAY contain more than one mandatory feature.
  This means that the initiating entity can choose among the mandatory
  features.  For example, perhaps a future technology will perform
  roughly the same function as TLS, so the receiving entity might
  advertise support for both TLS and the future technology.

So if the server requires both TLS and SASL, does this mean that it first
advertises TLS as required (and SASL is either advertised as optional or not advertised),
and then once TLS negotiation is complete, SASL needs to be advertised as required
(on the restarted stream)?

4.2.7.  Flow Chart

In the flowchart - is "receive stream features" required after each negotiation
of a voluntary feature?

4.6.  Stream Attributes

  The attributes of the root  element are defined in the
  following sections.

      Security Note: Until and unless the confidentiality and integrity
      of a stream header is ensured via Transport Layer Security as
      described under Section 5, the attributes provided in a stream
      header could be tampered with by an attacker.

Or SASL security layer (e.g. GSSAPI).

4.7.2.  Content Namespace

  When a content namespace is not declared as the default namespace and
  so-called "prefix-free canonicalization" is used instead, in rough
  outline a stream will look something like the following.

 
   
      foo
   
 

Should the closing tag be  above?

4.7.4.  Namespace Declarations and Prefixes

  An implementation MUST NOT generate namespace prefixes for elements
  qualified by the content namespace if the content namespace is
  'jabber:client' or 'jabber:server' (e.g., ).  An XMPP

Can you try to explain this again, you lost me here.

  entity MUST NOT accept data that violates this rule (in particular,
  an XMPP server MUST NOT route or deliver such data to another
  entity); instead it MUST either ignore the data or return a stream
  error (which SHOULD be ).

5.4.3.1.  Rules

  7.  Following successful TLS negotiation, all further data
      transmitted by either party MUST be encrypted.

Did you really meant "encrypted" here? What about use of NULL ciphers
with integrity protection?

5.4.3.3.  TLS Success

  R:
       
          EXTERNAL
          PLAIN
       
     

This should include SCRAM-SHA-1 :-), as it is an MTI.

6.3.3.  Mechanism Preferences

  Any entity that will act as a SASL client or a SASL server MUST
  maintain an ordered list of its preferred SASL mechanisms according
  to the client or server, where the list is ordered according to local
  policy or user configuration (which SHOULD be in order of perceived
  strength to enable the strongest authentication possible).  A server
  MUST offer and a client MUST try SASL mechanisms in preference order.

Is this clear that server's and client's preference orders are different?

  For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
  GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
  is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
  SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).

6.3.7.  Simple User Name

  Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
  that the authentication identity used in the context of such
  mechanisms is a "simple user name" (see Section 2 of [SASL] as well
  as [SASLPREP]).  The exact form of the simple user name in any
  particular mechanism or deployment thereof is a local matter, and a
  simple user name does not necessarily map to an application
  identifier such as a JID or JID component (e.g., a localpart).
  However, in the absence of local information provided by the server,
  an XMPP client SHOULD assume that the authentication identity for
  such a SASL mechanism is a simple user name equal to the localpart of
  the user's JID.

Or bare JID? I believe many implementations based on Cyrus SASL allow full email-like syntax here.

6.3.9.  Realms

  The receiving entity MAY include a realm when negotiating certain
  SASL mechanisms.  If the receiving entity does not communicate a
  realm, the initiating entity MUST NOT assume that any realm exists.
  The realm MUST be used only for the purpose of authentication; in
  particular, an initiating entity MUST NOT attempt to derive an XMPP
  hostname from the realm information provided by the receiving entity.

Should this be clearer about which mechanisms are we talking about?
IMHO, being vague is not being helpful here.

[Ballot discuss]
[This is the initial version of my comments. I only finished reading section 6.6 at this point.]

I am not really surprised, but this is a very well written document. Some quick comments/questions before I can recommend approving it:

1)
4.5.3.  Idle Peer

  Even if the underlying TCP connection is alive and the stream is not
  broken, the peer might have sent no stanzas for a certain period of
  time.  In this case, the peer SHOULD close the stream using the
  handshake described under Section 4.4.

SHOULD close the stream, or SHOULD use the procedure in Section 4.4 if it decides to close it?

  If the idle peer does not
  close the stream, the other party MAY either close the stream using
  the handshake described under Section 4.4 or return a stream error
  (e.g.,  if the entity has reached a limit on
  the number of open TCP connections or  if the
  connection has exceeded a local timeout policy).  However, consistent
  with the order of layers (specified under Section 13.3), the other
  party is advised to verify that the underlying TCP connection is
  alive and the stream is unbroken (as described above) before
  concluding that the peer is idle.  Furthermore, it is preferable to
  be liberal in accepting idle peers, since experience has shown that
  doing so improves the reliability of communication over XMPP networks
  and that it is typically more efficient to maintain a stream between
  two servers than to aggressively timeout such a stream.

This is arguing for MAY above.

2)
4.6.4.  xml:lang

  o  If the receiving entity supports a language that closely matches
      the initiating entity's preferred language (e.g., "de" instead of
      "de-CH"),

I think you really need to be referencing Section 3.4 of RFC 4647 for this,
as the process you describe above is not very formal (and might introduce
wrong results if coded by a naive implementor).

      then the value of the 'xml:lang' attribute SHOULD be the
      identifier for the matching language (e.g., "de") but MAY be the
      identifier for the default language of the receiving entity (e.g.,
      "en").

3)
5.3.5.  TLS Renegotiation

  Support for TLS renegotiation is strictly OPTIONAL.  However,
  implementations that support TLS renegotiation MUST implement and use
  the TLS Renegotiation Extension [TLS-NEG].

This makes [TLS-NEG] a Normative Reference.

4)
6.4.2.  Initiation

  If the initiating entity subsequently sends another  element
  (even if the ongoing authentication handshake has not yet completed),
  the server SHOULD discard the ongoing handshake and begin a new
  handshake for the subsequently requested SASL mechanism.

What are the possible conditions for violating the SHOULD?
The server really MUST fail the existing handshake, but maybe it doesn't have
to begin a new handshake (e.g. it might choose to close the connection instead?).

Upon approval of this document, IANA understands that there are seven
IANA Actions that need to be completed.

First, in the namespace registry of IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the existing registry for the namespace for xmpp-tls should be updated to:

URI: urn:ietf:params:xml:ns:xmpp-tls
Specification: [ RFC-to-be ]
Description: This is the XML namespace name for STARTTLS negotiation
data in the Extensible Messaging and Presence Protocol (XMPP) as defined
by [ RFC-to-be ].
Registrant Contact: IETF, XMPP Working Group,

Second, in the namespace registry of IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the existing registry for the namespace for xmpp-sasl should be updated to:

URI: urn:ietf:params:xml:ns:xmpp-sasl
Specification: [ RFC-to-be ]
Description: This is the XML namespace name for SASL negotiation data in
the Extensible Messaging and Presence Protocol (XMPP) as defined by [
RFC-to-be ].
Registrant Contact: IETF, XMPP Working Group,

Third, in the namespace registry of IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the existing registry for the namespace for xmpp-streams should be
updated to:

URI: urn:ietf:params:xml:ns:xmpp-streams
Specification: [ RRFC-to-be ]
Description: This is the XML namespace name for stream error data in the
Extensible Messaging and Presence Protocol (XMPP) as defined by [
RFC-to-be ].
Registrant Contact: IETF, XMPP Working Group,

Fourth, in the namespace registry of IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the existing registry for the namespace for xmpp-bind should be updated to:

URI: urn:ietf:params:xml:ns:xmpp-bind
Specification: [ RFC-to-be ]
Description: This is the XML namespace name for resource binding in the
Extensible Messaging and Presence Protocol (XMPP) as defined by [
RFC-to-be ].
Registrant Contact: IETF, XMPP Working Group,

Fifth, in the namespace registry of IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

the existing registry for the namespace for xmpp-stanzas should be
updated to:

URI: urn:ietf:params:xml:ns:xmpp-stanzas
Specification: [ RFC-to-be ]
Description: This is the XML namespace name for stanza error data in the
Extensible Messaging and Presence Protocol (XMPP) as defined by [
RFC-to-be ].
Registrant Contact: IETF, XMPP Working Group,

Sixth, in the Generic Security Service Application Program Interface
(GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL)
Service Names registry located at:

http://www.iana.org/assignments/gssapi-service-names/gssapi-service-names.xhtml

the reference for the service name "xmpp" will be changed from RFC3920
to this document.

Seventh, in the User Registered Port Number registry, the references for
port 5222, "xmpp-client" and port 5269, "xmpp-server," will be changed
from RFC3920 to this document.

IANA understands that these seven tasks are all that need to be
completed upon approval of the document.

PROTO writeup for http://tools.ietf.org/id/draft-ietf-xmpp-3920bis-16.txt: "Extensible Messaging and Presence Protocol (XMPP): Core"


  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd for this document is Ben Campbell.

The document has been reviewed and is ready for forwarding to IESG for publication.


  (1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document had multiple rounds of WGLC and considerable review from working group participants, many of which are implementors of the protocol. Commenters include (in no particular order) Justin Karneges, Matthew Wild, Curtis King, Kevin Smith, Philipp Hancke, Florian Zeitz, Waqas Hussain, Dave Cridland, Jehan Pages, Ralph Meijer, and others. 

The Document Shepherd does not have concerns about the depth or breadth of the reviews.


  (1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization, or XML?

The document should undergo the usual Gen-ART and secdir reviews. But otherwise the Document Shepherd does not have concerns over the level and breadth of review for this document. This is a long document, and schedules for external reviews should keep that in mind.


  (1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.  Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.


The document shepherd has no concerns with this document.

There have been no IPR disclosures on this document. Disclosure number 324 was filed on RFC3920, which this draft intends to obsolete.



  (1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Among the people currently active in the WG there is a wide consensus behind the document. No significant objections have been raised to this version of the document.



  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Nobody has threatened an appeal or otherwise indicated extreme discontent.


  (1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type, and URI type reviews?  If the document
        does not already indicate its intended status at the top of
        the first page, please indicate the intended status here.

idnits 2.12.05 returns a few warnings that do not appear to be substantive. The Document Shepherd believes that the document contains all needed information.


  (1.h)  Has the document split its references into normative and
        informative?  Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion?  Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The draft contains both normative and informative references.


The draft contains a normative reference to RFC 3447, which is an informational RFC. This RFC is a republication of the RSA algorithm specifications. This seems to fit both the letter and spirit of RFC 3967. All other normatively referenced RFCs are either at least proposed standard or BCPs.

The draft contains several normative references to ISO, Unicode Consortium, and WC3 documents.

The draft contains a normative dependency on draft-ietf-xmpp-address. We expect that draft to progress together with this draft.

The draft contains a normative dependency on draft-saintandre-tls-server-id-check, which is still in progress. We expect that draft to progress soon, and do not expect changes in that draft to force changes in this one. Draft-ietf-xmpp-3920bis should be held in the editors queue until approval of draft-saintandre-tls-server-id-check.


The draft contains informative references to draft-ietf-newtrk-interop-reports, draft-ietf-tls-rfc4366-bis, and draft-ietf-xmpp-3921bis. It references the current version as of this writing, but if those drafts are revised prior to publication of this one, the references should be updated.


  (1.i)  Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process, has the Document
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during IESG Evaluation?

The Document Editor believes that the IANA Consideration contains the appropriate information, and is consistent with the rest of the document.


  (1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document contains a number of XML schemas, which have been mechanically verified using the W3C validator at http://www.w3.org/2001/03/webdata/xsv .


  (1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up.  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.

Since 2004 the Internet community has gained extensive implementation and deployment experience with XMPP, including formal interoperability testing carried out under the auspices of the XMPP Standards Foundation (XSF).  This document incorporates comprehensive feedback from software developers and service providers, including a number of backward-compatible modifications.  As a result, this document reflects the rough consensus of the Internet community regarding the core features of XMPP 1.0, thus obsoleting RFC 3920.


        Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

There is strong consensus in the working group to publish this document.

There has been controversy over the use of dialback authentication in XMPP. RFC 3920 recommended against the use of dialback, but included it for backwards compatibility reasons. Since dialback continues to be in common use among XMPP implementations, some working group participants wished to keep it in this draft. Others believed that we should further discourage its use by removing it. The working group reached a rough consensus to remove it from this draft, but mention it (referencing XEP-0220) as something many implementations do, and allowed at a MAY level for interworking with implementations that are unable to use stronger authentication.

There were concerns that the XMPP addressing format (aka JID) depend on internationalization technologies (stringprep) that are currently in flux, and may be in flux for some time. Rather than block progress on this draft, the working group chose to remove the JID definition to a separate draft (draft-ietf-xmpp-address-03). The referenced draft continues to use stringprep, but was separated out to make it easier to update in a "modular" fashion once work on a new internationalization approach is complete.

        Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

There are at least 25 server implementations, 50 library implementations, and 100 client implementations of the XMPP RFCs; a partial list is located at  (that list does not include "software as a service" implementations hosted by service providers such as Google Talk). Several downloadable software
implementations in each category have been closely tracking the changes between RFC 3920 and draft-ietf-xmpp-3920bis, and many others are currently being upgraded or are waiting until the replacement RFC is
published before including the modifications in released software. Interoperability is continually being verified among implementation teams, over the XMPP network, and at more formal interoperability
testing events sponsored by the XMPP Standards Foundation. It is expected that official implementation reports will be submitted within a year after publication of the revised XMPP RFCs.


        Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

The document shepherd for this document is Ben Campbell.

The responsible Area Director is Gonzalo Camarillo.

The IANA Expert(s) for the registries in this document are .