[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
- [Sipping] [Editorial Errata Reported] RFC5850 (36… RFC Errata System