Subject: [xmpp] AD review: draft-ietf-xmpp-3920bis-16

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 02 Oct 2010 19:24:47 +0300

Hi,

I have received a publication request for the following draft:

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

Below you can find my AD review. The draft has also received some
additional comments on the list in the last few days. I will leave it up
to the author to quickly address these comments in a new revision before
I start its IETF LC or to take all these comments as IETF LC comments.

Cheers,

Gonzalo

Page 10: it is not clear if SASL is mandatory and those servers will
need to be update, or if the Sever dialback protocol is an
option. What does this RFC recommend to do? What is the point of that
paragraph? The PROTO writeup mentions that the consensus was to keep
dialback at the MAY level. The text in the draft could be more clear
about that.

Section 3.2.1 describes the preferred process. Should we add a
normative statement such as "it is RECOMMENDED to use this process" to
capture the preference?

There are a few Overview sections that contain normative
statements. Is that the intention? I am asking because overview
sections are often intended to be non-normative descriptions on what
will be normatively specified in a different section.

Section 4.3, third bullet. Is that approach described somewhere else
or it is done in a proprietory way?

Section 4.8.1.4: first TCP connection refers to the
connection that *was established* first, right?

Section 8.4, second to last bullet (at the end of the section). The
text does not give any guidance on when the receiver should choose
ignoring the stanza or returning an error.

Section 9 mentions that the examples are non normative. However,
previous sections containing examples do not mention this. Stressing
this point also in previous sections may be useful.

---

From: Dave Cridland <[email-masked]>
Date: Sat, 02 Oct 2010 20:36:50 +0100

> or it is done in a proprietory way?

XEP-0220 includes a "piggybacking" feature.

Also the bidirection S2S "future extension" has been accepted as a  
XEP, I believe.

> connection that *was established* first, right?
No... "first" should be replaced with "same" in the first bullet.

In the second bullet, "first" should be replaced with "one", and  
"second" with "other, return".

> ignoring the stanza or returning an error.
No, and it shouldn't - it's highly dependent on the application  
running over XMPP, the destination of the message, and so on. For  
instance, if the message is directed at a client, then the choice may  
depend on whether the sending client's bare jid was in the roster of  
the receiving client's account.

Trying to specify all possible cases will treble the size of the  
document, and if gets much longer people will naturally assume it's a  
SIP specification. ;-)

> this point also in previous sections may be useful.

I'm a great fan of a document conventions section for points like  
these to be made. Typically, such sections also mention about line  
breaks not being for anything but clarity, the "S1:" prefices, etc.  
I'll draft such a section if there is interest in the group.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Sat, 02 Oct 2010 20:47:10 +0100

> XEP-0220 includes a "piggybacking" feature.

Oh, no, I misread this. (Thanks to Philip Hancke for pointing out my  
error).

This point relates to using multiple streams between two domains, and  
that's possible with no extensions, proprietary or otherwise. This  
isn't always a good idea, hence the spec includes <conflict/> for the  
receiver of multiple streams for a domain to reject it, but it's not  
given a pointer here. (Perhaps it should be).

Dave.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 04 Oct 2010 10:37:14 +0300

Hi Dave,

> document, and if gets much longer people will naturally assume it's a  

that would be terrible!!! :o)

Cheers,

Gonzalo

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Oct 2010 12:16:30 -0600

On 10/2/10 1:47 PM, Dave Cridland wrote:
> that's possible with no extensions, proprietary or otherwise. This isn't
> always a good idea, hence the spec includes <conflict/> for the receiver
> of multiple streams for a domain to reject it, but it's not given a
> pointer here. (Perhaps it should be).

Done:

   o  Multiple streams over two or more TCP connections.  This approach
      is sometimes used for server-to-server communication between two
      large XMPP service providers; however, this can make it difficult
      to maintain coherence of data received over multiple streams in
      situations described under Section 10.1, which is why a server MAY
      return a <conflict> stream error to a remote domain that attempts
      to negotiate more than one stream (as described under
      Section 4.8.3.3).

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Oct 2010 15:20:32 -0600

On 10/2/10 1:36 PM, Dave Cridland wrote:
> Also the bidirection S2S "future extension" has been accepted as a XEP,
> I believe.

Yes, XEP-0288:

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

> "second" with "other, return".

Fixed.

> No, and it shouldn't - it's highly dependent on the application running
> over XMPP, the destination of the message, and so on. For instance, if
> the message is directed at a client, then the choice may depend on
> whether the sending client's bare jid was in the roster of the receiving
> client's account.

To clarify matter, in my working copy I've tweaked the text as shown below.

Note: I've added a rule about how to handle a presence stanza whose only
child element is qualified by an unknown namespace; although that rule
is implicit in the rule about handling a message or presence stanza
containing data qualified by an unknown namespace, I now think it's
better to make the handling explicit because the text was a bit too
subtle before.

###

   If a recipient receives a stanza that contains an element or
   attribute it does not understand, it MUST NOT attempt to process that
   XML data and instead MUST proceed as follows.

   o  If an entity receives a message stanza whose only child element is
      qualified by a namespace it does not understand, then depending on
      the XMPP application it MUST either ignore the entire stanza or
      return a stanza error, which SHOULD be <service-unavailable/>.

   o  If an entity receives a presence stanza whose only child element
      is qualified by a namespace it does not understand, then it MUST
      ignore the child element by treating the presence stanza as if it
      contained no child element.

   o  If an entity receives a message or presence stanza that contains
      XML data qualified by a namespace it does not understand, then it
      MUST ignore the portion of the stanza qualified by the unknown
      namespace.

   o  If an entity receives an IQ stanza of type "get" or "set"
      containing a child element qualified by a namespace it does not
      understand, then the entity MUST return an IQ stanza of type
      "error" with an error condition of <service-unavailable/>.

###

> I'm a great fan of a document conventions section for points like these
> to be made. Typically, such sections also mention about line breaks not
> being for anything but clarity, the "S1:" prefices, etc. I'll draft such
> a section if there is interest in the group.

In my working copy I've moved that sentence from Section 9 to Section
1.4, with the following changes:

   Readers need to be aware that the examples are not exhaustive and
   that, in examples for some protocol flows, the alternate steps shown
   would not necessarily be triggered by the exact data sent in the
   previous step; in all cases the protocol definitions provided in
   this document or in referenced specifications rule over any examples
   provided here.

/psa