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

[Elwyn Davies <[e-mail]>]

Hi.

Ah!  My reply to Russ' email and this just crossed in the aether.

Yes these seem to be an excellent solution, especially combined with the
move from hostname to FQDN etc noted previously.

There are a couple of points later where I complained about some SHOULDS
and realized afterwards that they are not actually protocol
specifications but hopes about communications:


> s8.2.1: A reference to s10.3.1, where the meaning of a message with
> 'to'
> attribute is explained, would clarify the first SHOULD.  Adding 'if
> possible' to route or deliver it to the intended recipient' would
> explain the second SHOULD which should probably be lowercase 'should'
> as this
> isn't a conformance issue but a matter of whether the connections are
> available.
> 
> s8.2.2: The second and third SHOULDs probably need 'if possible' to
> explain them and they should probably be lowercase 'should' as this
> isn't a conformance issue but a matter of whether the connections are
> available.
> 
> 

Full reeponses tomorrow.. last night was late enough :-)

Regards,
Elwyn

On Tue, 2010-11-30 at 15:45 -0700, Peter Saint-Andre wrote:
> 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" <[e-mail]> 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
>