[Sipping] [Editorial Errata Reported] RFC5850 (3662)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 17 June 2013 14:53 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FD021F9C8A for <sipping@ietfa.amsl.com>; Mon, 17 Jun 2013 07:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.464
X-Spam-Level:
X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLt+6scebGcQ for <sipping@ietfa.amsl.com>; Mon, 17 Jun 2013 07:53:09 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 72BCE21F9C2F for <sipping@ietf.org>; Mon, 17 Jun 2013 07:53:07 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id F2DBC62113; Mon, 17 Jun 2013 07:51:00 -0700 (PDT)
To: rohan@ekabal.com, rjsparks@nostrum.com, jdrosen@jdrosen.net, dpetrie@sipez.com, alan@sipstation.com, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, gonzalo.camarillo@ericsson.com, mary.ietf.barnes@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20130617145100.F2DBC62113@rfc-editor.org>
Date: Mon, 17 Jun 2013 07:51:00 -0700
X-Mailman-Approved-At: Mon, 17 Jun 2013 07:55:43 -0700
Cc: joelrepiquet@gmail.com, sipping@ietf.org, rfc-editor@rfc-editor.org
Subject: [Sipping] [Editorial Errata Reported] RFC5850 (3662)
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 14:53:10 -0000

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 <joelrepiquet@gmail.com>

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