*** Alex Zinnin:

> There were a couple of things that bothered me, but as I write them
> down I conclude that they are not show stoppers.

> Moderate Issues:

> 1) There is no textual description of the format of the message.  The
> document assumes that the reader will understand from the XML Schema
> that there is an outer wrapper of "isConposing" , that there is a
> mandatory element call "state", the specific name space to be used for
> this, and similar properties.  As this schema is very small, this is
> almost defensible.  But it seems to me that this is a bad practice. 
> (This is currently being debated on the SIMPLE list.  I am providing
> my opinion here.) It would be better to simply include a bit of text
> about the structure of the XML message.  There is text about the
> optional elements, but none about the mandatory elements as XML

There is only one mandatory element, <status>. Your point is well taken;
I've added a brief section to the document that outlines the overall
message format.

> 2) The document says that usage of this feature can be negotiated with
> SDP.  It is probably obvious to those very conversant with SDP, but it
> would be helpful to those who are less conversant to indicate which
> SDP element this is used with.  I would that this somehow goes on the
> m= line.  I am guessing that if I were more conversant with SDP I
> would know that it is okay to have multiple media lines with the same
> port number, etc.

More detail added; see also other comments.

> Minor:  Given the discussion of SDP negotiation in the document,
> shouldn't there be a reference?  I think that would be a normative
> reference.

A reference was added.

*** Hollenbeck, Scott

> The definition of the <isComposing> element includes this element:

> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded"/>

> that effectively allows extensions.  Section 3.4 mentions this in
> passing, but I'd really like to see a better description of what can or
> can't be considered a legitimate extension.

> I would also like to see a description of how extensions, future
> revisions, and the XML namespace registered in this document are related
> (or not).

*** Allison Mankin

> SDP negotiation is underdescribed.  If it isn't appropriate for it to
> be specified in this draft, please state that another draft would do
> so.

I've added additional details in the "Using the Status Message" section
(Section 4).  I hope this answers the question, but details would
probably depend a bit on MSRP, for example.  For example, in MSRP, the
media type (application/im-iscomposing+xml) would appear in the
a=accept-types parameter, not as a media ("m") line. 

Thus, I'm not sure that describing the 'm' line model is helpful, since
it wouldn't necessarily be used.

Should MSRP be referenced, given that it is only one of possibly several
different session-mode implementations and obviously somewhat SIP-specific?

I've also changed the wording so that SDP is an example, not the only
one. After all, negotiation may use SDPng, or some other protocol,
without this draft depending on it.

One punt is to simply say that the details depend on the session mode
protocol.

> Also, the draft makes the choice that page mode can't negotiate
> iscomposing without explaining why this is so - there's no mechanism
> explanation.  But MESSAGE-based SIP IM (page mode) is common, and will
> probably stay so.  Being able to control whether iscomposing is
> present seems important, because users may have page mode with the
> iscomposing feature and have strong preferences against it (there was
> some discussion of how page mode users experience iscomposing on the
> list) or even privacy/overhead reasons for needing it to be turned
> off.  With more discussion of the initiation/negotiation of
> iscomposing, the draft should re-consider page mode ability to
> negotiate iscomposing - simple on-off for the feature is enough.