[Ballot comment]
IANA found -10 unclear about policy for SIP URI purpose registry so it was clarified -
the policy is IETF Consensus.  Answered IANA ticket; cleared my Discuss holding the
question for IANA after sending this email.

[Ballot comment]
Review comments from Elwyn Davies:

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: <conference info> 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: <uris>: This element may potentially contain multiple URIs - how are they separated/identified?

s5.6.1: <display-text>: This is more a wish-list thought (and might be handled by structuring the <display-text>): 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: <referred>: 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 <cascaded-focus> 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 <conference-info> context/The 'label' attribute is the media stream identifier assigned by the conferencing server: its value will be unique in the <conference-info> context/


s5.6.2: <associated-aors>: need to expand AOR here.

s5.7.2: <referred>: s/who's/whose/, in sub-element 'by': s/who/which/

s.5.7.4: <joining-method>: s/method/the method/

s.5.7.5: <joining-info>: in by sub-element: s/who/which/

s.5.7.7: <disconnection-info>: in by sub-element: s/who/which/

[Ballot discuss]
The document currently says:

  Changes in conference identifiers and service URIs SHOULD be reported
  by the focus to the Conference package subscribers.

Don't these have to go conference participants that are also foci?  That is,
for these participants, is this a MUST?  If so, how is that captured in the
document?

The document currently says:

  In the context of this specification, the comparison rules for keys
  of type xs:anyURI are byte-by-byte (including all URI parameters that
  can be included with the URI).

I am assuming that the correct reference for anyURI is:
http://www.w3.org/TR/xmlschema-2/#anyURI.

If that is the case, then I believe more details on the comparison differences between
this usage and the typical comparison for anyURI may be required.  As defined
in that spec, anyURI allows relative URIs, lexical white space and fragment identifiers;
it also references the charmod comparison in  http://www.w3.org/TR/2001/WD-charmod-20010126/#sec-URIs.  If any of those are not desired here (e.g. no relative URIs), then these need
to be made explicit.  If these are all desired, then a reference is sufficient.

The document currently says:

5.4.2  <web-page>

  This element contains a URI of a web page describing either the
  conference service or the user hosting the conference.

Is there a limit on the URI scheme of this element to HTTP and HTTPS:?
Would an atom/rss releated URI also be permitted here?

IANA Last Call Comments:
Upon approval of this document the IANA will register a SIP event package, a new MIME type (application/conference-info+xml), a new XML namespace, a new XML
schema, and will create a sub-registry "URI purposes" under the existing registry: http://www.iana.org/assignments/sip-parameters.

The suggested registration rules say "New values of the "URI purposes" are registered by the IANA when a specification becomes available and according to the definition of RFC 2434 [4]." 

Please confirm that this means "specification required" as the language above does not exactly match the RFC2434 language.