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