Re: [MMUSIC] [Technical Errata Reported] RFC5547 (3190)

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Mon, 16 April 2012 09:10 UTC

Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8321F8722 for <mmusic@ietfa.amsl.com>; Mon, 16 Apr 2012 02:10:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.182
X-Spam-Level:
X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 wg+11cCD7g7R for <mmusic@ietfa.amsl.com>; Mon, 16 Apr 2012 02:10:50 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61D21F8713 for <mmusic@ietf.org>; Mon, 16 Apr 2012 02:10:50 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-a0-4f8be2194781
Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 75.72.03534.912EB8F4; Mon, 16 Apr 2012 11:10:49 +0200 (CEST)
Received: from [159.107.24.207] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 11:10:47 +0200
Message-ID: <4F8BE215.7030108@ericsson.com>
Date: Mon, 16 Apr 2012 11:10:45 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20120412160631.2C189B1E002@rfc-editor.org>
In-Reply-To: <20120412160631.2C189B1E002@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "markus.isomaki@nokia.com" <markus.isomaki@nokia.com>, "fandreas@cisco.com" <fandreas@cisco.com>, "bruno.chatras@orange.com" <bruno.chatras@orange.com>
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5547 (3190)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 09:10:51 -0000

Hi:

According to the discussion in SIPCORE, I agree with the reported errata. 
It should be moved to status "verified".

Thanks to Bruno and Paul for reporting it.

/Miguel

On 12/04/2012 18:06, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC5547,
> "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5547&eid=3190
>
> --------------------------------------
> Type: Technical
> Reported by: Bruno CHATRAS<bruno.chatras@orange.com>
>
> Section: GLOBAL
>
> Original Text
> -------------
> Section 9.1., paragraph 7:
>
> OLD:
>
>
>
>      --boundary71
>
>      Content-Type: application/sdp
>
>      Content-Length: [length of SDP]
>
>
>
> NEW:
>
>
>
>      --boundary71
>
>      Content-Type: application/sdp
>
>
>
>
>
> Section 9.1., paragraph 9:
>
> OLD:
>
>
>
>      --boundary71
>
>      Content-Type: image/jpeg
>
>      Content-Transfer-Encoding: binary
>
>      Content-ID:<id2@alicepc.example.com>
>
>      Content-Length: [length of image]
>
>      Content-Disposition: icon
>
>
>
> NEW:
>
>
>
>      --boundary71
>
>      Content-Type: image/jpeg
>
>      Content-Transfer-Encoding: binary
>
>      Content-ID:<id2@alicepc.example.com>
>
>      Content-Disposition: icon
>
>
>
>
>
> Section 9.2., paragraph 24:
>
> OLD:
>
>
>
>      --boundary71
>
>      Content-Type: application/sdp
>
>      Content-Length: [length of SDP]
>
>
>
> NEW:
>
>
>
>      --boundary71
>
>      Content-Type: application/sdp
>
>
>
>
>
> Section 9.2., paragraph 26:
>
> OLD:
>
>
>
>      --boundary71
>
>      Content-Type: image/jpeg
>
>      Content-Transfer-Encoding: binary
>
>      Content-ID:<id3@alicepc.example.com>
>
>      Content-Length: [length of image]
>
>      Content-Disposition: icon
>
>
>
> NEW:
>
>
>
>      --boundary71
>
>      Content-Type: image/jpeg
>
>      Content-Transfer-Encoding: binary
>
>      Content-ID:<id3@alicepc.example.com>
>
>      Content-Disposition: icon
>
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.
>
>
>
> This was discussed on both the SIP Implementors and SIP Core mailing lists.
>
> 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.
>
> --------------------------------------
> RFC5547 (draft-ietf-mmusic-file-transfer-mech-11)
> --------------------------------------
> Title               : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
> Publication Date    : May 2009
> Author(s)           : M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat
> Category            : PROPOSED STANDARD
> Source              : Multiparty Multimedia Session Control
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain