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

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...

  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.

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.

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?