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 protected]> 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 > <localp...@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 <localp...@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 <localp...@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 <localp...@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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
