[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
