Subject: Re: [xmpp] Gen-art review of draft-ietf-xmpp-address-07

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

[cc'ing [email-masked] and [email-masked]]

On 11/30/10 3:43 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. This is a belated and very quick check of this
> document after reading xmpp-3920bis.  I didn't find anything much
> problematic.]
> 
> Document: draft-ietf-xmpp-address-07
> Reviewer: Elwyn Davies
> Review Date: 30 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.  (Essentially) ready.  There is one missing definition that is
> really needed for xmpp-3920bis - 'Bare JID'.

I think the solution is to remove both instances of "bare JID" since they
are inconsequential anyway. Thus:

(in 4.3.1)

   Therefore, an entity outside the security perimeter of a particular
   server cannot reliably distinguish between JIDs of the form
   <localpart@domainpart> at that server and thus can authenticate only
   the domainpart of such JIDs with any level of assurance.

and (in 4.3.2)

   o  A resourcepart can be employed as one part of an entity's address
      in XMPP.  One common usage is as the name for an instant messaging
      user's connected resource; another is as the nickname of a user in
      a multi-user chat room; and many other kinds of entities could use
      resourceparts as part of their addresses.  The security of such
      services could be compromised based on different interpretations
      of the internationalized resourcepart; for example, two or more
      confusable resources could be bound at the same time to the same
      account (resulting in inconsistent authorization decisions in an
      XMPP application), or a user could send a message to someone other
      than the intended recipient in a multi-user chat room.

> Caveat: I haven't done a
> detailed check of the Notes and Prohibited Outputs in the appendices.
> 
> Major issues:
> None.
> 
> Minor issues:
> s4.3.1, last para: There should be a formal definition of 'Bare JID' as
> it is extensively used in draft-ietf-xmpp-3920bis.  Note that almost all the
> cases where 'Bare JID' is used, both in this document and 3920bis add a
> expansion
> that this means <localpart@domainname>,  except for one instance in s8.1.2.1
> of 3920bis where it means just <domainname> (also referred to as 'Mere
> Dominname'
> elsewhere in 3920bis!).
> 
> The definition either needs to cover both cases or a different term needs to
> be
> created and used consistently for the Mere Domainname case.
> 
> Nits/editorial comments:
> None

See above, as well as my reply to your gen-art review of 3920bis.

Peter