Subject: [Gen-art] Gen-art review of draft-ietf-xmpp-3920bis-19

From: Elwyn Davies <[email-masked]>
Date: Tue, 30 Nov 2010 01:21:22 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

[Apologies to the author:  This document slipped through the gen-art
last call review net and so I only got to volunteer on this one 24 hours
ago.]

Document: draft-ietf-xmpp-3920bis-19
Reviewer: Elwyn Davies
Review Date: 29 November 2010
IETF LC End Date: 
IESG Telechat date: 2 December 2010

Summary:
This is a very well written document that is mostly easy to read and
follow.  However I believe it is not (quite) ready for the IESG for the
following reasons:

It has (IMO) one major issue as an EXTENSIBLE system - the three level-1
stanzas are hard coded and it is not immediately possible to add new
types of level-1 stanza should this be thought useful in future.

There are several more minor issues with these two being important:
There are also a largish number of SHOULD requirements where the
alternative is not discussed or specified.

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.

Apart form these there are a number of other minor issues and various
nits/editorial issues.

Caveat: As usual I haven't tried to verify the XML in Appendix A, and my
scan of the examples in s9 was very cursory.

Major issues:
s4.1, Definition of XML Stanza: Given that xmpp is supposed to be
extensible, is there a really good reason why the first-level
stanza=defining elements (message, presence, iq) are hard-coded into the
specification rather than being possibly extensible? There is already a
stream features mechanism where additional first-level items could be
signlaed.

Minor issues:
s2.5, first bullet describing server respnsibilities:  The term 'local
clients' is slightly confusing.  My immediate understanding of 'local'
would be something attached to the server from the local network or
machine.  In this case it is presumably intended to imply clients that
have a session connected to this server rather than via some other
server but may of course be very remote as regards physical and network
location.  Maybe 'attached clients' or 'associated clients' (this term
is used elsewhere in the document) might be clearer, or maybe this just
needs a terminology definition for how 'local' is used - there is the
use of 'local entities' previously in s2.5 but this didn't jar so much.

s2.5, last para: Does the use of 'local services' imply anything about
the disposition of the code implementing the service? This use of
'local' may or may not conflict with the implications of 'local
mentioned in the last comment.  Terminology needs to be made a little
more rigorous.

s4.2.2: Towards the end of this section, there are two statements
stating 'the initiating entity is cleared to send XML stanzas'. Should
this be qualified with 'unless a stream restart is required as a result
of the feature negotiation' (at least at the first appearance)?  This
probably depends on whether voluntary-to-negotiate features can require
stream restarts if agreed but not otherwise.

s4.2.3 and s4.4: In s4.2.3, if a stream has to be restarted, the parties
are supposed to consider the the stream 'replaced'.  This presumably
means that the old stream is closed.  It is not absolutely clear whether
this requires that a <stream/> is exchanged or definitely not exchanged
in this case. [OK: This is cleared up for the specific TLS case at item 
3 in s5.4.3.3 and for SASL in s6.4.6 - a general note at s4.2.3 would be
appropriate since these are not necessarily the only restart cases.]

s4.2.6, paras 2 and 3: The first parts of these paragraphs are written
as if SASL autrhentication was mandatory (which it is) and is the only
possibility (which it might not be).  Para 2 (the client-to-server case)
does not appear to allow for any other options.  Para 3, OTOH, goes on
to deal with Server Dialback but the first part still reads as if SASL
was the only option.  Both paras need to be rewritten to cater for other
options (and the version 0.9 case?). 

s4.6.1, para 6: 
  'For initial stream headers in server-to-server communication, a
   server MUST include the 'from' attribute and MUST set the value to
   the domainpart of the 'from' attribute of the stanza that caused the
   stream to be established...':  Is it absolutely always the case that 
a server-to-server connection would be established because some stanza 
came in (presumably from an attached client)?  Could this be indirectly
through some local service requiring a connection for any other reason?
It is clear why the server needs to specify 'from' but the constraint
on the origin seems overly restrictive.

s5.3.5: 'Because it is relatively inexpensive to establish streams in XMPP,
   for the first two cases it is preferable to use an XMPP stream reset
   (as described under Section 4.8.3.16) instead of performing TLS
   renegotiation.':
Is this always true?  Probably so for simple instant messaging but if 
the client is using some other services provided by the server, this may 
an unwarranted generalization.  I am not sufficiently expert in either
XMPP or TLS renegotiation to know what the trade-offs would be.

s5.3.5: 'However, the third case is sufficiently rare that XMPP entities
   SHOULD NOT blindly attempt TLS renegotiation.' (the third case is 
separating client authentication from server authentication):
I don't understand what is being said here.  Is this an opinion that the
risk of client credential leakage is sufficiently low that the expense of 
two stage negotiation is not really worth it?  Or is this something that 
should be controlled by a configurable client policy?  Or is this an
implementation choice?  Some clarification would help.

s5.4.3.1, rule 3: Why should the receiving entity not request a certificate?
Why would the initiating entity not send its certificate if it had one? (Is 
this related to the renegotiation issue from the last comment?)

s5.4.3.1, rule 4: How should the receiving entity make the choice given the 
'to' attribute (presumably some field in the certificate)? What happens if
it decides not to follow this should?

s5.4.3.2, para 2: The comment about not sending </stream> relates to the 
comment on s4.3.2 above. However, the reasoning for not sending </stream>
when the TCP connection is closed due to TLS failure differs from reasoning
given elsewhere (e.g., s5.3.5, para 8 - here the error is said to be at the
TLS layer and not the XMPP layer so that it is not appropriate to send </stream>).
A consistemt story is needed here.  

s5.4.3.3, item 5:  Given that SASL support is mandatory, why is offering the SASL 
feature not a MUST?  Is this to do with possible future alternatives?

s6.3.8, para 1: I suspect the two SHOULDs in this para ought to be MUSTs.  What
other options does initiating entity have if it does/does not want to act on
behalf of another entity and SASL is being used?  However maybe all this should be 
qualified by 'If SASL is being used...'

s6.4.1, para 5: 'If the receiving entity supports SASL, the stream features
   SHOULD include an advertisement for support of SASL negotiation,...':
s6.2 says that XMPP entities MUST support SASL. I think that this sentence 
probably needs to be turned round making it something like 'Unless support for SASL
negotiation is only allowed once STARTLS negotiation has been completed, the 
stream features MUST include an advertisement for the support of SASL.'  Aside from
the STARTLS case (or equivalent cases with future secure stream mechanisms), what 
happens if the SASL advertisement is not made?  

s6.4.2, last para: '... the server SHOULD discard the ongoing handshake...':
What happens if the server (receiving entity) chooses not to
comply with the new proposed SASL mechanism choice?

s6.4.5, paras 4 and 6:  'SHOULD close the stream':  What would enity do instead?

s6.4.6, para 1: The two SHOULDs in this paragraph ought to be MUSTs.  (if there is 
a 'from' address then the receiving entity MUST do the correlation - what else 
could it do?  If it does the match and they don't match, what would do other than
termionate the attempt?)

s8.1.2.1, item 2; also s10.5.1 and s10.5.2:  s8.1.2.1, item 2 appears to introduce 
the idea that the <domainname> is the 'bare JID' of a server.  This concept does 
not appear anywhere else in this document (or from a brief Google search elsewhere).  
It was not used in RFC 3920.  It also doesn't match the definition of Bare JID in
s10.5.3.2.  Previously in this document this was known as the 
'hostname'.  I think this is probably an error.  However s10.5.1 refers to a 
'Mere Domain' as a JID and s10.5.2 to a <domain/resourcepart> as a JID.  This seems
rather inconsistent. 

s8.1.2.1, items 2 and 4:  As written, both items refer to stanzas 'generated by the
server'.  I take it that the distinction is that item 2 refers to messages from the 
server that are not generated by the server as a proxy for the client account  but 
are some sort of generic control message or the like, whereas item 4 refers to server
generated messages that are generated by the server as such a proxy for the client 
account.  The wording is somewhat confusing at present.  Presumably the lack of a 
'from' attribute is intended to distinguish item 1 messages from item 4 messages -
this could be spelt out more positively if this is cotrrect.

s13.7.1.1. Both instances of item 4: 'The signatureAlgorithm SHOULD be the 
PKCS #1 version 1.5 signature algorithm with SHA-256 as defined by [PKIX-ALGO].':
What happens if it isn't? 

s13.7.1.1: First item 5: 'The certificate SHOULD include an Authority 
Information Access (AIA) extension that specifies the address of an Online
Certificate Status Protocol [OCSP] responder.'
What happens if it doesn't?

s13.9.5 and s15: The requirement for support of TLS-NEG if TLS Renegotiation is to be allowed 
should be mentioned here.  This is also a conformance requirement.

s14: I seem to remember that giving a working group as a registrant contact
for an URI is deprecated as it is likely to go out of existence fairly shortly.

Nits/editorial comments:

s3.2.1, bullet labeled '5': 'The initiating entity uses the IP
address(es) from the first successfully resolved hostname...': 'first'
implies that it depends on how fast the answers come back.  Presumably
what is wanted is the IP address of the highest priority SRV record that
is successfully resolved, maybe subject to some local policies?

s3.2.1,bullets labelled '3' and '8':  Bullet 3 suggests that the s3.2.2
fallaback process 'SHOULD' be used whereas bullet 8 has an implicit MAY
(that might be better if was explicit).  Why the distinction?
[Presumably, having read on, there is little point in trying the first
possibility in the defaults if the initiating entity has already tried
the default port, but the alternatives might still work.] Section 3.2.2
could mention that there is no point in trying the default ports if they
were already tried under s3.2.1.

s3.2.2: A pointer to s15.7 where the default port numbers are registered
would be useful.

s3.2.4: Where is the appropriate XML stanza for defining add-on services
defined?

s4.1, Definition of XML Stanza: The term/title 'iq'/'IQ' is not expanded
until s8.2.3 in this document where it is expanded as info/query.  It
would be useful to mention this here (first occurrence) and indeed maybe
to put all three of message, presence and iq into the terminology
section.  The usage of IQ stanzas would then be clearer and their use
in examples would be more transparent - currently they just appear with
no introduction (e.g, in s4.1 and then in s4.8.3.11).

s4.1, final set of bullets: Adding section references to the five topics
would be helpful.

s4.2.2, first para: A pointer to s4.6.5 which is very prescriptive about
how to do the version comparison would be useful.

Figure 3: It would help if the figure could be made one or two lines
shorter so that the title appears on the same page.  (e.g., move the
bottom line 'yes' and 'no' above the transition lines that they apply
to, remove one line below the 'process complete' box.)

s4.6.1, para 8 (also s4.6.2):  Although it may seem a bit pedantic, it
is probably desirable to clarify that by 'hostname' the document means a
fully qualified DNS name.  The term is used ambiguously by many
operating systems.

s4.6.6: The entries for to/initiating to receiving and from/receiving to
initiating are hostnames and not JIDs always.  The other two to and from
entries are hostnames rather than JIDs for the server-to-server case.
[But the comments on s8.1.2.1 item 2 and ss10.5.1/2 under minor issues
may have some bearing here.]

s5.3.3 and s6.3.5: Does 'whitespace' mean all the 'white space' items
referred to in Section 2.10 of the current version of the XML spec
(i.e., including line separators).  The term whitespace is used earlier
whan referring just to spaces used in the context of keep alives.  [It
turns out much later that s11.7 clarifies this but maybe doesn't totally
resolve s2.10.] Note that the XML specification uses 'white space'
rather than 'whitespace'.

s6.4., last para:  For consistency and avoiding confusion between XMPP
server and SASL server: s/server/receiving entity/

s8.2.1: A reference to s10.3.1, where the meaning of a message with 'to'
attribute is explained, would be clarify the first SHOULD.  Adding 'if
possible' to route or deliver it to the intended recipient' would
explain the second SHOULD.

s8.2.2: The second and third SHOULDs probably need 'if possible' to
explain them.

s8.3.2/s8.3.3:  All the error specifications in s8.3.3 contain a SHOULD
specification of the error type recommended.  A note in s8.3.2 or s8.3.3
that the values of the error type given in s8.3.3 are the usual expected
error type, but that there are conceivably circumstances when some other
value would be more appropriate. (the only one I copuld think of so far,
apart from the remote-server-timeout case already in the draft, was
associated with payment-required where a modify or cancel error type
might be appropriate if the reason was not that the requestor wasn't 
actually authorized but that it didn't have enough credit.)

s11.4: 'A client SHOULD NOT rely on the ability to send data that does
not conform to the schemas':  This is not controllable by the protocol.
s/SHOULD NOT/should not/

s11.4: What should the client do if it doesn't ignore non-conformant
elements?

s8.3.3.15, Security Note: s/communicated/communicate/ 
 
s14. The IANA Considerations mostly duplicate those in RFC 3920.  Is the
intention that IANA should update the references to RFC3920 to point at
this document?  If so some statement should be made about this. 

s14: Presumably 'XXXX' is to be replaced by the RFC nnnn identifier for
the eventual RFC.  This isn't stated.  Should the various Namespace
names refer to document sections?

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Nov 2010 21:26:29 -0600

(answering as an XMPP co-chair and doc shepherd, not as a gen-ART reviewer)

Thanks for the thorough review on short notice!

 While I will let Peter answer in detail, I do need to point out that this is a bis draft that set out to make specific fixes and improvements to the original spec based on actual deployment experience, while maintaining backwards compatibility as much as possible. Fixing everything that might be wrong with RFC3920 was not in scope. I suspect the working group would consider extensibility improvements in scope only to the degree that people ran into extensibility issues in the field, or that the existing text is unclear.

Does that make a difference on your major issue?

(Peter, please offer your opinion on this--as I assumed the co-chair roll well after the charter was approved, it's risky for me to try to say much about original intent.)

Again, thanks for the short notice work on this, and please don't take my comments in any way as a complaint.

Thanks!

Ben.

On Nov 29, 2010, at 7:21 PM, Elwyn Davies <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Nov 2010 14:59:48 -0700

Hi Elwyn, thank you for reviewing this long document on such short notice.
I'm cc'ing [email-masked] to keep the XMPP WG in the loop, as well as
[email-masked].

> types of level-1 stanza should this be thought useful in future.

That has been the design of XMPP since 1999 and it has not visibly slowed
the development of a wide range of XMPP extensions. From this I conclude
that the existing stanza types appear to cover all of the communication
primitives that have been needed in the XMPP community. Furthermore, the
extensibility model was documented in RFC 3920 and this I-D merely provides
updated documentation for the core XMPP protocols by obsoleting RFC 3920.
It's a bit late to be changing it now. Besides, I imagine that if we want an
even more flexible extensibility model, we'll develop XMPP 2.0. :)

> alternative is not discussed or specified.

This is true. When the alternatives are not security-critical, we have in
general left them up to the best judgment of software developers and service
operators. 

I'll also admit that it's a lot of work to document the alternatives to each
SHOULD-level requirement, and that the XMPP WG and the spec writer might
lack energy to do that in all cases. A quick grep yields 137 instances of
SHOULD or RECOMMENDED, and I'd expect that well over 100 of those do not
document the alternatives.

That said, if you have concerns about specific instances of those
conformance terms, please let me know. In the meantime, I will endeavor to
look at them all, although I won't have time to do so until after the IESG
telechat this Thursday at the earliest.

>From the perspective of software development, SASL authentication is
mandatory-to-implement for all clients and servers.

>From the perspective of service deployment, SASL authentication is
mandatory-to-negotiate without qualification for all client-to-server
streams. By contrast, for server-to-server streams, in practice SASL
authentication is used only in the case of TLS + SASL EXTERNAL with PKIX
certificates (in theory it could be used in the case of pre-shared secrets
between servers, but I am not aware of any deployment of such a solution).
However, many deployed XMPP services still do not have PKIX certificates and
therefore fall back to weak identity verification using the Server Dialback
protocol that was documented in RFC 3920 but has since been pulled out into
a separate spec. While we would love to say that TLS + SASL EXTERNAL is
mandatory-to-negotiate without qualification for all server-to-server
streams, such a mandate would be so far out of alignment with deployed
reality that people would just ignore it anyway.

However, here again I'll take another look at the text to make sure that
these matters are clear. In part, some of the confusion might derive from
the fact that in some places we use the term "mandatory" alone, rather than
"mandatory-to-implement" or "mandatory-to-negotiate". I have fixed all such
instances in my working copy.

> stream features mechanism where additional first-level items could be

And there's been absolutely no demand for new first-level elements. I'm not
saying there never will be such demand, but to date the XMPP community has
been able to do everything it's wanted to do using the existing stanza
types.

> use of 'local entities' previously in s2.5 but this didn't jar so much.

Elsewhere in this document we use the term "connected client", so I propose
using that term here as well.

> mentioned in the last comment.  Terminology needs to be made a little

Elsewhere in this document we use the term "add-on service", so I propose
using that term here as well.

> stream restarts if agreed but not otherwise.

The fact that the initiating entity is cleared to send stanzas is orthogonal
to whether a stream restart might be required after negotiation of a
voluntary-to-negotiate feature -- even if a voluntary-to-negotiate feature
required a stream restart (and so far none of them do), the initiating
entity would still be cleared to send stanzas.

Also note that stream restarts are something of a legacy "feature" (bug?),
because back in ~2003 we thought a stream restart would be necessary to
flush the security context of a stream after negotiation of TLS or
negotiation of a SASL mechanism that enforced a security layer. However, in
fact that really wasn't necessary and if we did it over again we might
remove stream restarts entirely. But there was no appetite in the WG for
making such a large change in 3920bis, so stream restarts remain as a kind
of legacy feature (bug?).

> appropriate since these are not necessarily the only restart cases.]

Section 4.2.3 states in part:

   The initiating entity then MUST send a new initial stream header,
   which SHOULD be preceded by an XML declaration as described under
   Section 11.5.

That seems clear to me.

However, this would be even clearer:

   On successful negotiation of a feature that necessitates a stream
   restart, both parties MUST consider the previous stream to be
   replaced but MUST NOT send a closing </stream> tag and MUST NOT
   terminate the underlying TCP connection; instead, the parties MUST
   reuse the existing connection, which might be in a new state (e.g.,
   encrypted as a result of TLS negotiation).  The initiating entity
   then MUST send a new initial stream header, which SHOULD be preceded
   by an XML declaration as described under Section 11.5.

> options (and the version 0.9 case?).

See above about wiggle room for weak identity verification using Server
Dialback.

Before SASL, we did also have another method for client authentication, but
that is completely deprecated, unlike Server Dialback (which unfortunately
clings to life despite our best efforts to drive a stake through its heart).

> on the origin seems overly restrictive.

There's no reason to establish a server-to-server connection unless a server
needs to send a stanza to a peer server. The triggering stanza might have
been generated by a connected client, an add-on service, or even the server
itself. Unlike end users, servers don't connect to each other just because
they're lonely. :)

> XMPP or TLS renegotiation to know what the trade-offs would be.

The XMPP WG had a fair amount of discussion about the tradeoffs and came to
the conclusions summarized in that section. The cost here is not really
related to the application that is operated after streams are negotiated
(and don't assume that IM is a simple or inexpensive application!), but to
the process of establishing streams in the first place no matter what
application is operated over the stream.

> implementation choice?  Some clarification would help.

The WG came very close to saying that XMPP entities MUST NOT use TLS
renegotiation because in general the costs (e.g., code complexity) outweigh
the benefits. However, as described there is one case when it might be
useful. Yet that case is quite rare, because in this case essentially the
client doesn't trust the server and won't send its TLS credentials to the
server until after the server has authenticated to the client. So far we
don't know of any client implementations or deployments that are
sufficiently paranoid to behave that way and in any case end-user
certificates are extremely rare at this point in the evolution of XMPP
technologies. In the case of server-to-server connections, the server that
acts as a TLS client uses a PKIX certificate as its credential and such
certificates are public anyway, so there's no possibility of leaking private
information. End-user certificates also tend to be public in that way
(although the user might worry about leaking their bare JID before the
stream is protected).

To clarify these matters, I suggest the following modified text:

   The third case has improved security characteristics when the TLS
   client (which might be an XMPP server) presents credentials to the
   TLS server.  If communicating such credentials to an unauthenticated
   TLS server might leak private information, it can be appropriate to
   complete TLS negotiation for the purpose of authenticating the TLS
   server to the TLS client and then attempt TLS renegotiation for the
   purpose of authenticating the TLS client to the TLS server.  However,
   this case is extremely rare because the credentials presented by an
   XMPP server or XMPP client acting as a TLS client are almost always
   public (i.e., a PKIX certificate) and therefore providing those
   credentials before authenticating the XMPP server acting as a TLS
   server would not in general leak private information.

   As a result, implementers are encouraged to carefully weigh the costs
   and benefits of TLS renegotiation before supporting it in their
   software, and XMPP entities that act as TLS clients are discouraged
   from blindly attempting TLS renegotiation unless the certificate (or
   other credential information) sent during TLS negotiation is known to
   be private.

> s5.4.3.1, rule 3: Why should the receiving entity not request a certificate?

Perhaps it has no expectation that initiating entity will be able to provide
a certificate. I don't think the WG had consensus to say MUST here, but I'll
bring this up on the WG list.

> this related to the renegotiation issue from the last comment?)

Yes, it is related -- the initiating entity might not want to send its
(private) credential information until after the receiving entity has itself
authenticated to the initiating entity.

> 'to' attribute (presumably some field in the certificate)?

Here the 'to' attribute essentially functions like a Server Name Indication
in TLS. If the server has multiple certificates based on domain name (e.g.,
in a virtual hosting environment), it can figure out which certificate to
present based on the domain name contained in 'to' address. I suggest the
following text clarification:

   4.  The receiving entity SHOULD choose which certificate to present
       based on the domainpart contained in the 'to' attribute of the
       initial stream header (in essence, this domainpart is
       functionally equivalent to the Server Name Indication defined for
       TLS in [TLS-EXT]).

> What happens if

The TLS negotiation might fail because the initiating entity would think
it's connecting to example.com but the receiving entity would present a
certificate for example.org (or whatever).

However, note that this doesn't apply if the XMPP server is servicing only
one domain, which is by far the most common deployment scenario.

> A consistemt story is needed here.

The text in Section 5.3.5 is more correct, thus I propose this in 5.4.3.2:

   The receiving entity MUST NOT send a closing </stream> tag before
   terminating the TCP connection (since the failure has occurred at the
   TLS layer, not the XMPP layer; see Section 13.3).

(The text about the stream being replaced applies to TLS success but not TLS
failure.)

> feature not a MUST?  Is this to do with possible future alternatives?

In the server-to-server case, if the peer server did not present a
certificate then SASL won't be possible. See above.

> behalf of another entity and SASL is being used?

None. So I think MUST and MUST NOT are appropriate (with the understanding
that they are hypothetical imperatives anyway, not categorical imperatives).

> However maybe all this
> should be

I think not.

> s6.2 says that XMPP entities MUST support SASL.

Right. The clause "If the receiving entity supports SASL" is a legacy of RFC
3920, when SASL was new. The clause can be safely removed now (all other
instances have been removed, but we missed this one).

> I think that this sentence

I think that changing the sentence as you propose is not correct, because it
closes off all other reasons for not advertising support for SASL (and,
because SASL is mandatory-to-negotiate if advertised, thus forcing an
attempt at SASL negotiation).

For completeness, I think it would be best to adjust the text in this
section as follows:

###

6.4.1.  Exchange of Stream Headers and Stream Features

   If SASL negotiation follows successful STARTTLS negotiation
   (Section 5), then the SASL negotiation occurs over the encrypted
   stream that has already been negotiated.  If not, the initiating
   entity resolves the hostname of the receiving entity as specified
   under Section 3, opens a TCP connection to the advertised port at the
   resolved IP address, and sends an initial stream header to the
   receiving entity.  In either case, the receiving entity will receive
   an initial stream from the initiating entity.

   I: <stream:stream
        from=[email-masked]'
        to='im.example.com'
        version='1.0'
        xml:lang='en'
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'>

   When the receiving entity processes an initial stream header from the
   initiating entity, it MUST send a response stream header to the
   initiating entity (for which it MUST generate a unique stream ID; if
   TLS negotiation has already succeeded then this stream ID MUST be
   different from the stream ID sent before TLS negotiation completed).

   R: <stream:stream
        from='im.example.com'
        id='vgKi/bkYME8OAj4rlXMkpucAqe4='
        to=[email-masked]'
        version='1.0'
        xml:lang='en'
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'>

   The receiving entity also MUST send stream features to the initiating
   entity.  The stream features SHOULD include an advertisement for
   support of SASL negotiation, i.e., a <mechanisms/> element qualified
   by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.  Typically there
   are only three cases in which support for SASL negotiation would not
   be advertised here:

   o  TLS negotiation needs to happen before SASL can be offered (i.e.,
      TLS is required and the receiving entity is responding to the very
      first initial stream header it has received for this connection
      attempt).

   o  SASL negotiation is impossible for a server-to-server connection
      (i.e., the initiating server has not provided a certificate that
      would enable strong authentication and therefore the receiving
      server is falling back to weak identity verification using the
      Server Dialback protocol [XEP-0220]).

   o  SASL has already been negotiated (i.e., the receiving entity is
      responding to an initial stream header sent as a stream restart
      after successful SASL negotiation).

[...]

###

> comply with the new proposed SASL mechanism choice?

That paragraph has changed in response to IESG feedback and subsequent WG
discussion. In my working copy it now reads:

   If the initiating entity subsequently sends another <auth/> element
   and the ongoing authentication handshake has not yet completed, the
   server MUST discard the ongoing handshake and MUST process a new
   handshake for the subsequently requested SASL mechanism.

> s6.4.5, paras 4 and 6:  'SHOULD close the stream':  What would enity do

Return a stream error, but that's not very friendly because the initiating
entity hasn't really violated any rules, it's just that authentication has
failed.

> could it do?  If it does the match and they don't match, what would do other

We don't place a great deal of trust in the 'from' address that is sent
before confidentiality and integrity are in place. What if the initial
'from' was tampered with, but the SASL exchange succeeds anyway? In fact we
might consider changing the second SHOULD to MAY for that very reason,
although I think SHOULD is probably fine.

> 'Mere Domain' as a JID and s10.5.2 to a <domain/resourcepart> as a JID.  This

The word "bare" is missing from section 4.2.6:

   For server-to-server communication, the initiating server's bare JID
   (<domainpart>)...

Historically, we referred to bare JID as <localpart@domainpart> and full JID
as <localpart@domainpart/resourcepart>, but we didn't have good terms for
<domainpart> vs. <domainpart/resourcepart> (not that anyone really uses the
latter form). Thus we borrowed the terms bare JID and full JID for servers,
as well.

You make a good point about the section names. I suggest changing them to:

     10.5.  Local Domain
       10.5.1.  domainpart
       10.5.2.  domainpart/resourcepart
       10.5.3.  localpart@domainpart
         10.5.3.1. No Such User
         10.5.3.2. User Exists
       10.5.4.  localpart@domainpart/resourcepart

> this could be spelt out more positively if this is cotrrect.

I suggest the following tweaked text:

   2.  When the server generates a stanza on its own behalf for delivery
       to the client from the server itself, the stanza MUST include a
       'from' attribute whose value is the bare JID (i.e., <domainpart>)
       of the server as agreed upon during stream negotiation (e.g.,
       based on the 'to' attribute of the initial stream header).

and:

   4.  A server MUST NOT send to the client a stanza without a 'from'
       attribute if the stanza was not generated by the server on its
       own behalf (e.g., if it was generated by another client or
       another server and the server is merely delivering it to the
       client on behalf of some other entity); therefore, when a client
       receives a stanza that does not include a 'from' attribute, it
       MUST assume that the stanza is from the user's account on the
       server.

> PKCS #1 version 1.5 signature algorithm with SHA-256 as defined by

The issuing entity (typically a CA) can use a stronger signature algorithm
if it pleases.

> What happens if it isn't?

I don't see an interoperability issue here -- we're trying to provide a
baseline for certificate issuers, but naturally CAs might choose stronger
signature algorithms in the future.

> What happens if it doesn't?

Then entities checking the certificate might need to fall back on CRLs.

> should be mentioned here.

We could copy the last sentence of Section 5.3.5:

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

> This is also a conformance requirement.

Section 15 does not include features that are optional.

> for an URI is deprecated as it is likely to go out of existence fairly

Good point, I'll change those to IESG.

> is successfully resolved, maybe subject to some local policies?

Good catch. I think we can change this to:

   "...from the successfully resolved hostname..."

Where "success" is measured in the terms of the prior steps.

> were already tried under s3.2.1.

There's a difference here between failure in the case when there are SRV
records, and no SRV records at all. If the DNS admin has configured SRV
records but they're just wrong or result in failed lookups, I think the
fallback is not a good idea (I've received feedback about this offlist since
-19 was published as well) -- this can result in some strange cases of
one-way connections in server-to-server scenarios. Thus I think this is
correct:

   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.

and:

   8.  If the initiating entity receives a response to its SRV query but
       it is not able to establish an XMPP connection using the data
       received in the response, it SHOULD NOT attempt the fallback
       process described in the next section (this helps to prevent a
       state mismatch between inbound and outbound connections).

   9.  If the initiating entity does not receive a response to its SRV
       query, it SHOULD attempt the fallback process described in the
       next section.

> s3.2.2: A pointer to s15.7 where the default port numbers are registered

Agreed. Changed to:

   The fallback process SHOULD be a normal "A" or "AAAA" address record
   resolution to determine the IPv4 or IPv6 address of the origin
   domain, where the port used is the "xmpp-client" port of 5222 for
   client-to-server connections or the "xmpp-server" port of 5269 for
   server-to-server connections (these are the default ports as
   registered with the IANA; see Section 14.7).

> s3.2.4: Where is the appropriate XML stanza for defining add-on services

If by "defining" you mean "communicating with", the answer is that it
depends on the application. For XMPP groupchat services of the kind used at
IETF meetings, the protocol is defined here:

http://xmpp.org/extensions/xep-0045.html

There is no appropriate XML stanza for *defining* add-on services. If only
developing protocol extensions were that easy... :)

> no introduction (e.g, in s4.1 and then in s4.8.3.11).

Good point. I have added those to the terminology section:

   The term "XML stream" (also "stream") is defined under Section 4.1.

   The term "XML stanza" (also "stanza") is defined under Section 4.1.
   There are three kinds of stanzas: message, presence, and IQ (short
   for "Info/Query").  These are defined under Section 8.2.1,
   Section 8.2.2, and Section 8.2.3, respectively.

> s4.1, final set of bullets: Adding section references to the five topics

Done.

> how to do the version comparison would be useful.

Agreed. Changed to:

   If the initiating entity includes in the initial stream header the
   'version' attribute set to a value of at least "1.0" (see
   Section 4.6.5)...

> to, remove one line below the 'process complete' box.)

Done.

> fully qualified DNS name.  The term is used ambiguously by many

Agreed. I suggest that we use the term "FQDN" instead of "hostname" anyway, 
because of the many ambiguities over the years regarding the latter term. 
Thus:

   Because XML streams are sent over TCP, the initiating entity needs to
   determine the IPv4 or IPv6 address (and port) of the receiving entity
   before it can attempt to connect to the XMPP network.  Typically this
   is done by resolving the receiving entity's fully-qualified domain
   name or "FDQN" (see [DNS-CONCEPTS]).

and then:

   The preferred process for FQDN resolution is to use [DNS-SRV] records
   as follows:

etc.

And in a few places by "hostname" we really mean "domainpart", so I've 
modified those accordingly.

> may have some bearing here.]

A mere <domainpart> is a JID.

> rather than 'whitespace'.

Section 1.4 of 3920bis states this (including the changes resulting from 
Alexey Melnikov's IESG comments):

   The term "whitespace" is used to refer to any character or characters
   matching production [3] content of [XML], i.e., one or more instances
   of the SP, HTAB, CR, or LF rules defined in [ABNF].

> server and SASL server: s/server/receiving entity/

Fixed.

> explain the second SHOULD.

Tweaked to:

   The <message/> stanza can be seen as a "push" mechanism whereby one
   entity pushes information to another entity, similar to the
   communications that occur in a system such as email.  All message
   stanzas SHOULD possess a 'to' attribute that specifies the intended
   recipient of the message (see Section 8.1.1 and Section 10.3); upon
   receiving such a stanza, a server SHOULD if possible route or deliver
   it to the intended recipient (see Section 10 for general routing and
   delivery rules related to XML stanzas).

> s8.2.2: The second and third SHOULDs probably need 'if possible' to

Tweaked to:

   The <presence/> stanza can be seen as a specialized broadcast or
   "publish-subscribe" mechanism, whereby multiple entities receive
   information (in this case, network availability information) about an
   entity to which they have subscribed.  In general, a publishing
   entity (client) SHOULD send a presence stanza with no 'to' attribute,
   in which case the server to which the entity is connected SHOULD if
   possible broadcast that stanza to all subscribed entities.  However,
   a publishing entity MAY also send a presence stanza with a 'to'
   attribute, in which case the server SHOULD if possible route or
   deliver that stanza to the intended recipient.  See Section 10 for
   general routing and delivery rules related to XML stanzas, and
   [XMPP-IM] for rules specific to presence applications.

> actually authorized but that it didn't have enough credit.)

Done in 8.3.3:

   The error-type value that is RECOMMENDED for each defined condition
   is the usual expected type; however, in some circumstances a
   different type might be more appropriate.

> not conform to the schemas':  This is not controllable by the protocol.

Sure:

   Clients are advised not to rely on the ability to send data that 
   does not conform to the schemas...

> s11.4: What should the client do if it doesn't ignore non-conformant

Process them. :)

Some implementation violate the schemas. Tthey can do that, but we recommend 
that they don't because violating the schemas can have bad consequences. One 
old example is <presence type='invisible'/> (ick).

> s8.3.3.15, Security Note: s/communicated/communicate/

Fixed.

> this document?  If so some statement should be made about this.

The IANA knows about that because the first paragraph of Section 14 states:

   The following subsections update the registrations provided in
   [RFC3920].

> the eventual RFC.  This isn't stated.  

The "XXXX" is autogenerated via the &rfc.number; predefined entity in 
xml2rfc and the RFC Editor team knows to search-and-replace on that.

> Should the various Namespace

I see no special reason to call out the section numbers in the IANA 
registry. That would be more work for the IANA, with very little benefit (we 
assume that readers can search the spec for strings of interest).

Thanks again for the detailed review.

Peter