(This updates the original proto writeup to use the new template. The only
substantive changes are those related to nickname internationalization and the
mention of GMSA RCS references to this document.)
> Document Writeup
>
> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February
> 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the
> title page header?
>
The RFC is intended to be a proposed standard. The title header page indicates
standards track.
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
Technical Summary
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending instant messages within a peer-to-peer session, negotiated using
the Session Initiation Protocol (SIP) and the Session Description
Protocol (SDP). This document defines the necessary tools for
establishing multi-party chat sessions, or chat rooms, using MSRP.
Working Group Summary
There has been controversy about doing this work in SIMPLE. The XCON
working group was chartered to do create similar mechanisms in a media
independent fashion. There was a compromise consensus to do this draft
in SIMPLE with the idea that, with its smaller scope, it could complete
more quickly than the XCON work, and that it would be a short-term
solution until XCON completed the more general work.
This in fact did not occur, as this draft took longer than expected due
to several editor changes. Discussion at the SIMPLE meeting at IETF75
concluded that we should capture the parts of this draft were specific
about mixing MSRP at a conference bridge, but abandon the rest in favor
of XCON. However, this conclusion did not achieve consensus when brought
it to the working group list at large.
We readdressed this on the SIMPLE list in September 2010. A few
participants strongly argued that the work should be abandoned, as it
conflicted with (now substantially complete) work in XCON. But others
(including at least one implementor) argued for completion. In
particular, several people argued that this draft enabled them to build
a light weight text-chat service without requiring all the features
enabled by XCON. Note that the XCON working group has since completed
its work and closed.
In summary, the working group originally had a consensus to complete
this work, and has not achieved a consensus to change that plan.
We had agreement to pubreq version 07 in late 2010. The shepherd found
some issues during the PROTO review. The work group discussed the
substantive changes since version 07 on list, and we had a
similar consensus to pubreq version 11 without a new WGLC
The apps area review turned up some issues with the internationalization
of nicknames. The related updates, as well as a new normative dependency
on the PRECIS work, have been vetted on the SIMPLE list.
Document Quality.
The document has quite a bit of review over its lifespan in the SIMPLE
work group. It lists Eva Leppanen, Adamu Haruna, Adam Roach, Matt
Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrianv Georgescu,
and Nancy Greene as reviewers in the acknowledgments.
The document has undergone an MMUSIC expert review (Flemming Adreasen), since
it contains an SDP extension. It has been through WGLC, multiple consensus
calls, as well as an IETF last call. It has had 2 Gen-ART reviews (Christer
Holmberg as Suresh Krishnan) , as well as IANA, apps-dir (Alexey Melnikov),
tsv-dir (Cullen Jennings), and sec-dir (Vincent Roca) reviews. The shepherd
believes that all issues raised in these reviews have been resolved.
There are at least two existing implementations, "Blink" as a client and
"SylkServer" as a server. A few others have indicated the intent to
implement it. Additionally, the GSMA RCS 5.1 specification references this
document in order to use the a=chatroom attribute.
Personnel
The document shepherd for this document is Ben Campbell.
The responsible Area Director is Robert Sparks (formerly Gonzalo Camarillo).
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
The document shepherd reviewed this document for content, structure, and nits.
The shepherd believes the document is ready for publication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
The Document Shepherd does not have concerns about the depth or breadth
of the reviews.
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
The shepherd believes all aspects of this document has been sufficiently
reviewed.
(See "Document Quality" section)
> (6) Describe any specific concerns or issues that the Document Shepherd
> has 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 shepherd previously argued that the nickname management
extension to MSRP is in fact a signaling or control function that should
be handled in the control layer, not as part of the media stream. This
was extensively discussed in the working group, and the consensus was to
keep the nickname management extension as described in this document.
The shepherd accepts the consensus.
There have been previous concerns about the relationship of this work to
that of XCON. The shepherd believes that SIMPLE had a consensus to move this
work forward anyway. Please see the "work group summary" section for details.
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.
Each author has confirmed that they are aware of no disclosures needed
to conform with the referenced BCPs.
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
There have been no IPR disclosures referencing this document.
> (9) 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?
Among the people currently active in the WG there is a wide consensus
behind the document. No significant objections have been raised to this
version of the document.
However, there has been some controversy over how this work relates to
XCON. Please see the Working Group Summary for details.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
No one has threatened an appeal or otherwise indicated extreme
discontent.
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
The Document Shepherd believes that the document contains all needed
information, and that all nits are covered.
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
The document has undergone an MMUSIC expert review, since
it contains an SDP extension.
> (13) Have all references within this document been identified as
> either normative or informative?
All references are identified normative or informative.
> (14) 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 plan for their completion?
There is a normative dependency on draft-ietf-precis-nickname. This is a work
item of the PRECIS working group. The shepherd, author of the dependency, and
the relevant area directors discussed how to move forward, and determined that
work on the dependency was not likely to force changes into this draft.
Therefore we plan to complete this work, but let it pend on the dependency in
the RFC editor's queue.
> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.
There is a normative downref to RFC 4353 (The conferencing framework). This was
discussed in the working group, with a consensus that RFC 4353 was
necessary to fully understanding this document.
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.
This document does not effect the status of any existing RFC.
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
The shepherd has reviewed the IANA considerations, and believes tha
t the IANA Consideration contains the
appropriate information, and is consistent with the rest of the
document. IANA has completed their review of the document.
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
The document does not establish any new registries.
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
The shepherd requested that the authors verify the ABNF in the document. The
authors reported that the ABNF was validated with an automated checker.