I have just requested the IESG to publish this document as
proposed
standard.
The PROTO writeup follows:
Regards
Keith
PROTO writeup for
http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-
list-conferencing-01.txt: "Conference Establishment
Using
Request-Contained
Lists in the Session Initiation Protocol (SIP)"
(1.a) Who is the Document Shepherd for this document?
Has the
Document Shepherd personally reviewed this version
of the
document and, in particular, does he or she
believe this
version is ready for forwarding to the IESG for
publication?
Keith Drage
The document has been reviewed and is ready for forwarding
to IESG for
publication.
(1.b) Has the document had adequate review both from key
WG members
and from key non-WG members? Does the Document
Shepherd have
any concerns about the depth or breadth of the
reviews that
have been performed?
Document history:
* draft-camarillo-sipping-exploders-solution-00 was
submitted
November
22nd 2003 and expired May 22nd 2004.
* draft-camarillo-sipping-exploders-00 was submitted
September 9th
2003
and expired March 9th 2004.
* draft-camarillo-sipping-exploders-02 was submitted
February 6th
2004
and expired August 6th 2004.
* draft-camarillo-sipping-exploders-03 was submitted
February 2004
and
expired August 1st 2004.
* draft-camarillo-sipping-uri-list-01 was submitted 6th
February
2004
and expired 6th August 2004.
* draft-camarillo-uri-list-02 was submitted 27th March 2004
and
expired
25th September 2004.
* draft-ietf-sipping-uri-list-00 was submitted 30th May 2004
and
expired
30th November 2004.
* draft-ietf-sipping-uri-list-conferencing-00 was submitted
27th
July
2004 and expired January 5th 2005.
* draft-ietf-sipping-uri-list-conferencing-01 was submitted
September
23rd 2004 and expired March 24th 2005.
* draft-ietf-sipping-uri-list-conferencing-02 was submitted
2nd
December
2004 and expired 28th May 2005.
* draft-ietf-sipping-uri-list-conferencing-03 was submitted
8th
April
2005 and expired 10th October 2005.
* draft-ietf-sipping-uri-list-conferencing-04 was submitted
24th
October
2005 and expired 24th April 2006.
* draft-ietf-sipping-uri-list-conferencing-05 was submitted
27th
February 2006 and expired 26th August 2006.
* draft-ietf-sip-uri-list-conferencing-00 was submitted
24th
September
2006 and expires 24th March 2007.
* draft-ietf-sip-uri-list-conferencing-01 was submitted
26th
January
2007 and expires 30th July 2007.
WGLC was initiated in the SIPPING WG on
draft-ietf-sipping-uri-list-
conferencing-02 on 12th January 2005 with comments requested
by 12th
February 2005.
No comments were received.
During the course of the work comments have also been made
by: Atsushi
Sato,
Dean Willis, Darshan Bildikar.
draft-ietf-sipping-uri-list-conferencing-05 was extended to
refer to
draft-
ietf-sipping-capacity.
The document was moved from the SIPPING WG to the SIP WG in
conformance
with
RFC 3427 because it defines an option tag (this was added at
a late
stage in
the review process). The document was regarded by the
SIPPING WG chairs
as
being adequately reviewed and no further review took place
in the SIP
WG.
The SIP mailing list was polled on this status and no
complaint was
made.
(1.c) Does the Document Shepherd have concerns that the
document
needs more review from a particular or broader
perspective,
e.g., security, operational complexity, someone
familiar with
AAA, internationalization or XML?
The document defines mechanisms that are entirely internal
to the
Session
Initiation Protocol (SIP). The document shepherd considers
that no
external
review from an external specialist is necessary.
(1.d) Does the Document Shepherd have any specific
concerns or
issues with this document that the Responsible
Area Director
and/or the IESG should be aware of? For example,
perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for
it. In any
event, if the WG has discussed those issues and
has indicated
that it still wishes to advance the document,
detail those
concerns here.
The document defines a new SIP protocol extension for a
particular
purpose
in a form that has been used for many other extensions. The
document
shepherd has no concerns with the.
(1.e) How solid is the WG consensus behind this
document? Does it
represent the strong concurrence of a few
individuals, with
others being silent, or does the WG as a whole
understand and
agree with it?
There is a strong requirement from OMA for a SIP solution in
this area.
The
document also forms part of 3GPP Release 7 content.
(1.f) Has anyone threatened an appeal or otherwise
indicated extreme
discontent? If so, please summarise the areas of
conflict in
separate email messages to the Responsible Area
Director. (It
should be in a separate email because this
questionnaire is
entered into the ID Tracker.)
None indicated.
(1.g) Has the Document Shepherd personally verified that
the
document satisfies all ID nits? (See
http://www.ietf
.org/ID-Checklist.html and
http://tools.ietf
.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has
the document
met all formal review criteria it needs to, such
as the MIB
Doctor, media type and URI type reviews?
The document has been reviewed against the guidelines in RFC
4485 and it
is
believed that the document is conformant with those
guidelines.
While the document defines a new SIP option tag, these have
been
performed
as a SIP working group item, and therefore this draft is in
conformance
with
RFC 3427.
For ID-NITS against idnits 1.124 reports "No nits
found".
(1.h) Has the document split its references into
normative and
informative? Are there normative references to
documents that
are not ready for advancement or are otherwise in
an unclear
state? If such normative references exist, what
is the
strategy for their completion? Are there
normative references
that are downward references, as described in
[RFC3967]? If
so, list these downward references to support the
Area
Director in the Last Call procedure for them
[RFC3967].
The document has split its references into normative and
informative
references. All the normative references are now published
RFCs except
as
follows:
* reference [6] draft-ietf-sipping-uri-services-06 has been
submitted to
the IESG by the SIPPING group as proposed standard.
* reference [7] draft-ietf-simple-xcap-list-usage-05 is in
in the
RFC
editor queue as proposed standard.
* reference [8] draft-ietf-sipping-capacity-attribute-03 has
been
submitted to the IESG by the SIPPING group as proposed
standard.
(1.i) Has the Document Shepherd verified that the
document IANA
consideration section exists and is consistent
with the body
of the document? If the document specifies
protocol
extensions, are reservations requested in
appropriate IANA
registries? Are the IANA registries clearly
identified? If
the document creates a new registry, does it
define the
proposed initial contents of the registry and an
allocation
procedure for future registrations? Does it
suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If
the document
describes an Expert Review process has Shepherd
conferred with
the Responsible Area Director so that the IESG can
appoint the
needed Expert during the IESG Evaluation?
Section 8 of the document registers a new option-tag; the
new option-tag
is
defined elsewhere in the document. This registration is
consistent with
RFC
3968 which defines the registry and is also consistent with
the current
format of the registry.
(1.j) Has the Document Shepherd verified that sections
of the
document that are written in a formal language,
such as XML
code, BNF rules, MIB definitions, etc., validate
correctly in
an automated checker?
The document contains no entries written in formal language.
While the
document makes use of XML within a SIP message body, that
XML is defined
by
other documents (RFC 4488,
draft-ietf-simple-xcap-list-usage-05), and
used
in this specification by reference. Figure 1, figure 3, and
figure 4
contain
an example of this XML usage which is apparently
well-formed.
(1.k) The IESG approval announcement includes a
Document
Announcement Write-Up. Please provide such a
Document
Announcement Writeup? Recent examples can be
found in the
"Action" announcements for approved
documents. The approval
announcement contains the following sections:
Technical Summary
This document describes how to create a conference using SIP
URI-list
services. In particular, it describes a mechanism that
allows a client
to
provide a conference server with the initial list of
participants using
an
INVITE-contained URI-list.
Working Group Summary
The document was originally produced by the SIPPING working
group, but
was
transferred to the SIP working group due to the need to
define a new
option
tag, in conformance with RFC 3427.
Document Quality
There is a strong requirement from OMA and 3GPP for a SIP
solution in
this
area.
Personnel
Keith Drage is the document shepherd for this document.
Cullen Jennings
is
the responsible Area Director.
-----Original Message-----
From: Internet-Drafts ietf.org [mailto:Internet-Draftsietf.org]
Sent: 26 January 2007 20:50
To: i-d-announceietf.org
Cc: sipietf.org
Subject: [Sip] I-D
ACTION:draft-ietf-sip-uri-list-conferencing-01.txt
A New Internet-Draft is available from the on-line
Internet-Drafts
directories.
This draft is a work item of the Session Initiation Protocol
Working
Group of the IETF.
Title : Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol
(SIP)
Author(s) : G. Camarillo, A. Johnston
Filename : draft-ietf-sip-uri-list-conferencing-01.txt
Pages : 14
Date : 2007-1-26
This document describes how to create a conference using SIP
URI-list
services. In particular, it describes a mechanism that
allows a user
agent client to provide a conference server with the
initial list of
participants using an INVITE-contained URI-list.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draf
t-ietf-sip-uri-list-conferencing
-01.txt
To remove yourself from the I-D Announcement list, send a
message to
i-d-announce-requestietf.org with the word unsubscribe in the
body of
the message.
You can also visit h
ttps://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login
with the
username "anonymous" and a password of your e-mail
address. After
logging in, type "cd internet-drafts" and then
"get
draft-ietf-sip-uri-list-conferencing-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/s
hadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailservietf.org.
In the body type:
"FILE
/internet-drafts/draft-ietf-sip-uri-list-conferencing-01.txt
".
NOTE: The mail server at ietf.org can return the document
in
MIME-encoded form by using the "mpack" utility.
To use this
feature, insert the command "ENCODING mime"
before the "FILE"
command. To decode the response(s), you will need
"munpack" or
a MIME-compliant mail reader. Different MIME-compliant
mail
readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which
have been split
up into multiple messages), so check your local
documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail
reader
implementation to automatically retrieve the ASCII version
of the
Internet-Draft.
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
