[Editorial Errata Reported] RFC5850 (3662)

RFC Errata System <[email protected]> Mon, 17 Jun 2013 07:51:00 -0700 (PDT)
Newsgroups gmane.ietf.sipping
Message-ID <[email protected]>
--===============7724656249470892842==
Content-Type: text/plain

The following errata report has been submitted for RFC5850,
"A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5850&eid=3662

--------------------------------------
Type: Editorial
Reported by: Joël Repiquet <[email protected]>

Section: 2.5

Original Text
-------------
   The multi-party architecture may also need to provide a mechanism to
   get information about the status/handling of a dialog (for example,
   information about the history of other contacts attempted prior to
   the current contact).  Finally, the architecture should provide ample
   opportunities to present informational URIs that relate to calls,
   conversations, or dialogs in some way.  For example, consider the SIP
   Call-Info header or Contact header fields returned in a 300-class
   response.  Frequently, additional information about a call or dialog
   can be fetched via non-SIP URIs.  For example, consider a web page
   for package tracking when calling a delivery company or a web page
   with related documentation when joining a dial-in conference.  The
   use of URIs in the multi-party framework is discussed in more detail
   in Section 3.7.

Corrected Text
--------------
   The multi-party architecture may also need to provide a mechanism to
   get information about the status/handling of a dialog (for example,
   information about the history of other contacts attempted prior to
   the current contact).  Finally, the architecture should provide ample
   opportunities to present informational URIs that relate to calls,
   conversations, or dialogs in some way.  For example, consider the SIP
   Call-Info header or Contact header fields returned in a 300-class
   response.  Frequently, additional information about a call or dialog
   can be fetched via non-SIP URIs.  For example, consider a web page
   for package tracking when calling a delivery company or a web page
   with related documentation when joining a dial-in conference.  The
   use of URIs in the multi-party framework is discussed in more detail
   in Section 2.7.

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5850 (draft-ietf-sipping-cc-framework-12)
--------------------------------------
Title               : A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
Publication Date    : May 2010
Author(s)           : R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.
Category            : INFORMATIONAL
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

--===============7724656249470892842==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
--===============7724656249470892842==--