An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
draft-ietf-sipping-dialog-package-06

[Ballot comment]
This was very well done.  The one thing I'd suggest when doing similar
documents in the future is that you include an explicit analysis of
the advice on authorization policy and confirm that the proposed
applications in the introduction are actually compatible with this
advice.

[Ballot comment]
In the introduction:

up, user A's phone rings.  When A picks it up, they here ringing,

--> up, user A's phone rings.  When A picks it up, they hear ringing,

I would find an example in "3.11 State agents" very useful.  In that
same vein, including a session description element in the sample
in 4.2 would be useful. 

In 4.1.6.3, it should probably be clarified whether the MIME type
parameter's changing should trigger an updated session description,
since the "bucket" mime type parameters actually carry things like
codec which are likely to be of interest.

In 4.3, the document says:

  If the value in the new document is
  one higher than the local version number, the local version number is
  increased by one, and the document is processed.  If the value in the
  document is more than one higher than the local version number, the
  local version number is set to the value in the new document, and the
  document is processed.

Am I missing something, or is this equivalent to saying "If the value in
the document is higher than the local version number, the local version
number is set to the value in the new document, and the document is
processed"?  That is, is the incremented by one case actually different?

[Ballot comment]
The description of sip.byeless in section 5.1 is much more clear than
  the description in section 1.  Repeating the first few sentences of
  section 5.1 in section 1 would have been helpful to me.

IANA Comments:
Upon approval of this document the IANA will register a new MIME type, a new XML namespace and schema, and two new media feature parameters in the SIP
tree.

In the description in section 89, it should probably also say "and schema" as this is also included in the IANA Considerations section.

[Ballot comment]
Since the draft is going to be touched anyway, I didn't make this a DISCUSS, but I'd appreciate the authors' attention to these comments from the Gen-Art review by Michael Patton:

----------------------------------------------------------------
Summary: This draft is basically ready for publication, but has a few
things that I'd like to see cleared up before publication.
The first one can be done as a normal part of RFC prep, the
second probably needs some new text, which would need review.


In Section 1, first paragraph, references to RFCs are sometimes done
with the reference number (and not the RFC number) and
sometimes with the RFC number (and not the reference number).
Besides being inconsistent, this makes it hard to notice the
correlation between the various references.  I'd suggest
making ALL the references in the form "RFC3265 [1]" which is
clear and makes it consistent.
There are other places in the doc where RFCs are mentioned without
references.  They should be added.


The last paragraph of the Introduction seemed just a bit sparse to
me.  But, as I'm unfamiliar with the subject area this may
just be my lack of background.  This does suggest that the
paragraph might be improved with a little more explanation.
On the other hand it _is_ the introduction, so it's not
supposed to be complete.
Then, when I get to Section 5 which does have the definitions, I find
myself asking what these have to do with the rest of the
document.  It seems to me that these are general parameters
and not specific to this document.  I think the document needs
to explain what these are for somewhere...


Typos:

Abstract: "an receive notifications" => "and receive notifications"

Section 3.7.1 nearly at the end:
  "the replaced invitation transition transitions to"
=> "the replaced invitation transitions to"

Section 3.7.2: paragraph 4 has an unmatched open paren.

Section 4.1.6.2: second paragraph has an unmatched open paren.

The doubly nested parens at the end of paragraph 2 in Section 5.2 are
confusing, and suggest that that sentence should be rewritten
as several to avoid the nesting.


Random comment:  I would have used Dave instead of Bob and then the VM
mailbox could have been daves-not-here-man... but that joke's probably
US centric...

[Ballot discuss]
It doesn't look like my review comments from January have been addressed:

http://eikenes.alvestrand.no/pipermail/ietf-types/2005-January/000574.html

I just ran the schema found in section 4.4 through the checker again and the errors are still there.

Please change the registrant/change controller info for the requests found in section 8 to either be the IESG or "as designated by the IESG" for a working group.