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

From: Elwyn Davies <[email-masked]>
Date: Tue, 30 Nov 2010 22:43:08 +0000

Hi, Peter.

This is fine by me - given the proposed fixes to 3920bis.

Good to go now.

Regards,
Elwyn

On Tue, 2010-11-30 at 15:17 -0700, Peter Saint-Andre wrote:
> [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
> 
>