Subject: Re: [xmpp] Gen-art review of draft-ietf-xmpp-3920bis-19 (updated)

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Nov 2010 15:45:26 -0700

Hi Elwyn, unfortunately I replied to your original message, not the updated
one. I've run a diff between the two and here reply only to the points
raised in your updated text.

On 11/30/10 3:12 AM, "Elwyn Davies" <[email-masked]> wrote:

> 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.  Later... Having slept on the comments I see there are a couple that were
> items that I missed and should be modified or removed.  In particular
> about whitespace (where I missed the definition in terminology).
> Further I have now read (very quickly) the address draft which clarifies
> some matters on what are possible JIDs but doesn't totally solve some of the
> issues.]
> 
> 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.  This is,
> I guess a philosophical issue, and as a -bis document it probably isn't
> going to get changed at this stage, so this need not concern us deeply.
> However I think that it might be useful to provide an explanation of
> the general semantics of the three types of stanza early on in the document -
> not having participated in XMPP, it wasn't until I stepped back from
> the details of the document (as well as finding out what IQ stood for
> when I reached section 8) that I realized that the three existing
> categories of stanza are  effectively semantic types that are appropriate
> for the three classes of message for which they are named, but could
> be used for other sorts of function - this might avoid people thinking that
> they need extra stanza types and complaining that it isn't extensible :-( .

How about if we add the following paragraph right after the definition of
"XML Stanza" in Section 4.1?

   There are three kinds of stanzas: message, presence, and IQ (short
   for "Info/Query").  These stanza types provide three different
   communication primitives: a "push" mechanism for generalized
   messaging, a specialized "publish-subscribe" mechanism for
   broadcasting information about network availability, and a "request-
   response" mechanism for more structured exchanges of data (similar to
   [HTTP]).  Further explanation is provided under Section 8.2.1,
   Section 8.2.2, and Section 8.2.3, respectively.

<snip/>

> The separation of the address format into a separate document means
> that there should be some information about the terms that are
> imported in the terminology section.  The early sections on stream setup
> talking about 'from' and 'to' addresses have some difficulties with the
> use of hostname versus the term used in the JID/addressing draft of
> domainname.  Almost the whole of this document implies that a JID
> *necessarily*
> has a localpart, whereas the definition in the addressing draft allows
> it to be just a bare (or mere!) domainname.  The couple of places where
> JIDs may or in some cases, must not have a localpart confuse matters because
> they don't describe the hostname only forms as JIDs in the main text, but they
> are suddenly transformed into JIDs in summaries (in particular the summary
> table in s4.6.6
> where it turns out that, yes, all the 'to' and 'from' addresses are actually
> JIDs but (1) only restricted forms are allowed for some interactions
> and (2) these restricted forms were carefully *not* described as JIDs earlier
> in s4.6).
> Again, the term 'bare JID' is almost everywhere shown as
> <localpart@domainname>
> except for in s8.1.2.1.  This term is not actually defined in the addressing
> draft
> and appears only in one place as a term for <localpart@domainname>.

I suggest adding the following definitions to the Terminology section:

   The terms "localpart", "domainpart", and "resourcepart" are defined
   in [XMPP-ADDR].

   The term "bare JID" refers to an XMPP address of the form
   <localpart@domainpart> (for an account at a server) or of the form
   <domainpart> (for a server).

   The term "full JID" refers to an XMPP address of the form
   <localpart@domainpart/resourcepart> (for a particular authorized
   client or device associated with an account) or of the form
   <domainpart/resourcepart> (for a particular resource or script
   associated with a server).

Let me know if I've missed anything from your updated review.

Thanks again.

Peter