Subject: [Sip] LC Review: draft-ietf-sip-manyfolk-resource-02.txt

From: "James Undery" <[email-masked]>
Date: Thu, 6 Sep 2001 10:32:49 +0100

This is a first cut of a last call review of
draft-ietf-sip-manyfolk-resource-02.txt

NITS (Doing LC so I didn't really check)
====

The table numbering is messed up there are two tables 3 and 4.
Table 4 Summary of header fields, P-Z, not in alphabetical order ;-)
Section 16 is vague to the point of uselessness as no IPR statements on the
IETF page refer directly to this draft.

LC Review
=========

Generally, I believe this draft uses functionality only working in the bis
drafts, large portions repeat the base spec (sometimes inaccurately),
however, nothing is a major problem and with these corrections I'd be happy
with the draft.

Section 3
=========

"QoS Assured" vs "QoS Enabled"
------------------------------

QoS Assured, how can this be backwardly compatible, if the UAC goes straight
to ringing this will fail. I am not sure if this draft can guarantee QoS
Assured sessions and backwards compatibility. (Unless Requires header is
used, but this isn't explicitly stated, and then the call will fail)

Section 5.1
===========

Really a NIT, but I'd remove the i,u and e values for clarity of the example
SDP

Section 6
=========

Record-Route issues
-------------------

Firstly Record-Route is broken in rfc2543, so I'll base comments on the bis
version.

"If the initial request contained Record-Route headers, the provisional
response MUST contain a copy of these headers...", The MUST conflicts with
the SHOULD in section 16.2 of bis04 and some of the text later on in the
section.

Retransmission Strategy
-----------------------

This differs (unintentionally ?) from the retransmission strategy of
non-INVITEs. Why not just reference standard retransmission? (Requests are
retransmitted every T2 seconds after a provisional response has been
received, until 11 messages have been sent or a final response is received.)

Section 6.1
===========

Content-Length should be "m*"
Hide is depreciated

The following are missing

Authentication-Info
Alert-Info
Call-Info
Content-Disposition
Content-Language
In-Reply-To
MIME-version
Supported

Sections 7 & 8
==============

The section numbers are wrong for the bis. The whole section would be
better, not trying to be errata to the SIP spec.

Section 9
=========

Content-Disposition is in the bis.

HTH

James Undery

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: William Marshall <[email-masked]>
Date: Thu, 13 Sep 2001 18:30:53 -0400 (EDT)

Jim,

Thanks for your comments on the manyfolks draft.  I'll try
to address each of them individually.

> The table numbering is messed up there are two tables 3 and 4.

whoops.  fixed.

> Table 4 Summary of header fields, P-Z, not in alphabetical order ;-)

That's what I get for picking it up from another draft, without looking
closely.  fixed.

> IETF page refer directly to this draft.

3Com's statement is there; AT&T's statement is on its way.  The text for
section 16 came straight from RFC2026.  Though I agree with the comment,
it is required to be there, exactly as is.

> however, nothing is a major problem and with these corrections I'd be happy

The intention is that this draft be an extension of RFC2543, and not bis.
Therefore, several sections of bis are repeated (but just those portions 
that are needed for this mechanism).  The hope is that nothing will
directly conflict with bis, when it becomes an RFC.  I believe that
is true except for the prohibited use of Record-Route from the provisional
response (noted below, and which will be fixed).

> "QoS Assured" vs "QoS Enabled"

The draft defines an option value for the Requires header (section 10).
Agreed it is not possible to be QoS Assured and backwards compatible.
The tag is optional to quickly recover from a UAS that does not support
preconditions (by letting the session proceed without them).  If that is
not the desired recovery, then the option tag would be used in the request.

I've added text to section 10 to make this point clearer.

> Section 5.1

agreed

> Record-Route issues

It is intended that this draft make this a MUST, while the base spec is
only a SHOULD.  The Route header is needed for the COMET (just as for
the PRACK).  I believe this is valid for the manyfolks extension to
strengthen the requirement language of the base spec.  

Inclusion of the Route header in the COMET is more of a problem.  The
current text says it MUST be placed in the COMET, and MUST NOT be placed 
in any other request.  I'm removing the MUST NOT line to not conflict with 
bis.  However, it is true that this "MUST be placed in the COMET" directly 
conflicts with the "MUST NOT be placed in any other request" in 100rel,
and therefore should be taken to override 100rel as well.

> Retransmission Strategy

Agreed.  It is better to just reference the base spec there.

> Section 6.1

2543 didn't define "m*" for this table, and has Content-Length marked
as optional.  I'd agree that based on bis it should be "m*", but based
on 2543 it should be kept as "o".

> The following are missing

since manyfolks is an extension to 2543, these headers are not yet
defined.  Again I'd agree that based on bis they should be in the table,
but based on 2543 they should not be.

> Sections 7 & 8

The section numbers match 2543.

> Content-Disposition is in the bis.

but not in 2543 and needed for this feature.  Therefore duplicated
here.  Hopefully this will not conflict with the final text in bis.

> James Undery

Other changes to appear in next version of manyfolks draft, based on
other list comments:

Added text in section 11 (usage rules) making explicit that a
mid-session re-INVITE follows the same sequence of messages as
an initial INVITE.

Tried to add text to section 13 about doing resource reservations
sequentially, instead of in parallel, but discovered many problems
interacting with the forking proxy that limit the information available
to the UAC in those cases.  So this was left unchanged.

I will make the MSWord source of the draft, with changebars, available
if anyone is interested in mid-versions.

Bill Marshall
[email-masked]