Draft: draft-ietf-sipping-conference-package-11.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Date: Thursday 6/9/2005 11:55 AM CST Summary: The draft is almost ready for Proposed Standard, subject to Ted Hardie's DISCUSS and a couple of minor but substantive points below. There are a few editorial nits that ought to be addressed but could be done by RFC Editor notes, or incorporated if a new version results from Ted's points. Review: In general this draft looks in good shape to be approved as Proposed Standard. I note that Ted Hardie has raised a discuss over a couple of technical points. I haven't checked the Examples (s7) or XML Schema (s6) in detail... I assume some machine has done these! Substantive points: s5.2: version: I would have thought the version number MUST be incremented for any full notification sent as well as for partials, if I understand the algorithm correctly. Presumably it could be incremented for any notification since the deleted ones terminate the state. (The XML scheam in s6 allows the version to be optional - it strikes me that this is accident prone - it would probably be better to require a version number, although one for a deleted state is redundant.) s5.4.3: : This element may potentially contain multiple URIs - how are they separated/identified? s5.6.1: : This is more a wish-list thought (and might be handled by structuring the ): many chat and conferencing systems provide for a full name and a handy nickname for conference users - would this be a sensible addition here? s5.7.2: : I guess: s/It can contain/It MAY contain/ Some editorial nits below: General: The term 'conference package' appears capitalized occasionally (not just in headers) - make it consistent. Abstract/Intro: The term 'tightly coupled conference' is used in the framework to describe the sorts of conference which are generally being addressed by this series of drafts (c.f draft-ietf-sipping-cc-conferencing-07). Is it intended that this package is restricted to the tightly coupled case (I think that is the intention)? If so, it would be good to mention the term, otherwise it would be useful to note the scope of the package in terms of types of conference to which it is applicable. s2, Terminology: Might be worth mentioning that terminology is imported from the framework document. Also the terms 'roster', 'conference roster' and 'sidebar roster' are used with specific meaning which I think it would be worth explaining (they aren't in the framework). s3, 1st sentence: Pedantically: s/subscribe to a conference/subscribe to the information relating to a conference/ s3, 2nd sentence; s/route to/identify/ s3.2, 1st sentence: s/Filters to conference subscriptions are a desirable feature/Filters which can be applied to conference subscriptions are a desirable feature/ Do the statements about future standardization need to be updated given that draft-ietf-simple-event-filter-funct-05 and related drafts are now in the RFC editor queue? s3.8: I am slightly confused by the phrase 'Users of this package': Does this mean an implementation or instantiation of this package? Also does this restriction conflict with the mechanism? s4.4, third para: s/permissible/for which it is permissible/ s5.1, last para: s/for automata processing, others - for human/for processing by automata, others are for human/ s5.3.4, 1st para: s/The 'label' attribute is the media stream identifier being assigned by the conferencing server such as its value is unique in the context/The 'label' attribute is the media stream identifier assigned by the conferencing server: its value will be unique in the context/ s5.6.2: : need to expand AOR here. s5.7.2: : s/who's/whose/, in sub-element 'by': s/who/which/ s.5.7.4: : s/method/the method/ s.5.7.5: : in by sub-element: s/who/which/ s.5.7.7: : in by sub-element: s/who/which/