Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278)
Riccardo Bernardini <riccardo.bernardini@uniud.it> Fri, 06 July 2012 09:39 UTC
Return-Path: <riccardo.bernardini@uniud.it>
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 043FE21F8736 for <mmusic@ietfa.amsl.com>; Fri, 6 Jul 2012 02:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.21
X-Spam-Level:
X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 k2S41FgJKKLj for <mmusic@ietfa.amsl.com>; Fri, 6 Jul 2012 02:39:21 -0700 (PDT)
Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 19EE921F870F for <mmusic@ietf.org>; Fri, 6 Jul 2012 02:39:20 -0700 (PDT)
Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id AE1C0B72C9C for <mmusic@ietf.org>; Fri, 6 Jul 2012 11:39:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at talitha1
Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id 2PtU3MPBU8mS for <mmusic@ietf.org>; Fri, 6 Jul 2012 11:39:34 +0200 (CEST)
Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 94EA0B0035 for <mmusic@ietf.org>; Fri, 6 Jul 2012 11:39:34 +0200 (CEST)
Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Fri, 06 Jul 2012 11:39:34 +0200
Message-ID: <20120706113934.316446cy7mrqdhzq@webmail.uniud.it>
Date: Fri, 06 Jul 2012 11:39:34 +0200
From: Riccardo Bernardini <riccardo.bernardini@uniud.it>
To: mmusic@ietf.org
References: <20120703180119.1CF9F72F1C4@rfc-editor.org> <F81CEE99482EFE438DAE2A652361EE12020AE3@MCHP04MSX.global-ad.net>
In-Reply-To: <F81CEE99482EFE438DAE2A652361EE12020AE3@MCHP04MSX.global-ad.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.7)
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278)
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: Fri, 06 Jul 2012 09:39:22 -0000
"Stach, Thomas" <thomas.stach@siemens-enterprise.com> ha scritto: > All, > > I think this errata should be rejected. > > The text on page 9 is pretty clear and I don't see a conflict with the ABNF. > > Under "Session description" it is explicitly stated that you can > have zero or more media descriptions (as well as time descriptions) > Further down under "Media description, if present" it is elaborated > what a media description includes. > It must at least include exactly one m-line. The a,b,k,i,c-lines are > optional. > Adding the asterisk as proposed would remove this subtlety. > The same technique is used for "Time description". The t-line is > mandatory, the r-lines are optional. OK, let me try to rephrase it: the media-description BLOCK is OPTIONAL and you can have zero media-description blocks; but the "m=" line is MANDATORY whenever you have a media-description block. Maybe this was the reason of my confusion: I interpreted the missing asterisk as ``you cannot have SDP descriptions without m= lines,'' while I should have read ``m= lines are mandatory within a media block, but an SDP without m= lines is OK as long as you have no media blocks.'' I guess that "if present" part should clarify this, but it escaped me, sorry. Note that this type of subtlety does not happen with t= lines since, according to the ABNF, at least one "time-fields" block must be present. OK, I can see why the text on page 9 is correct. Regards Riccardo > > BTW: Being able to provide zero media descriptions is crucial for > certain implementations. An example is tunneling QSIG in SIP. > > Regards > Thomas > >> -----Ursprüngliche Nachricht----- >> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Im Auftrag von RFC Errata System >> Gesendet: Dienstag, 03. Juli 2012 20:01 >> An: M.Handley@cs.ucl.ac.uk; van@packetdesign.com; >> csp@csperkins.org; gonzalo.camarillo@ericsson.com; >> rjsparks@nostrum.com; fandreas@cisco.com; miguel.a.garcia@ericsson.com >> Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org >> Betreff: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) >> >> >> The following errata report has been submitted for RFC4566, >> "SDP: Session Description Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=3278 >> >> -------------------------------------- >> Type: Technical >> Reported by: Riccardo Bernardini <riccardo.bernardini@uniud.it> >> >> Section: 5 >> >> Original Text >> ------------- >> At page 9: >> >> >> Media description, if present >> m= (media name and transport address) >> >> Corrected Text >> -------------- >> >> Media description, if present >> m=* (media name and transport address) >> >> >> >> Notes >> ----- >> A '*' is added making "m=" lines optional >> >> Rationale: >> The description about media lines in section 5, page 9 is >> conflicting with the ABNF syntax of media-description in >> Section 9, page 40 >> >> media-descriptions = *( media-field >> information-field >> *connection-field >> bandwidth-fields >> key-field >> attribute-fields ) >> >> According to the ABNF grammar, an SDP description can have >> zero "m=" lines, but according to the description at page 9, >> at least one line must be present. Note that the conflict >> could be solved also by replacing the media-descriptions >> definition with >> >> media-descriptions = 1*( media-field ... ) >> >> but at page 8 (still Section 5) it is said >> >> An SDP session description consists of a session-level section >> followed by zero or more media-level sections. ... >> ^^^^^^^^^^^^^^^^^^^^^^^^ >> >> so, I guess that the ABNF grammar is correct. >> >> 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. >> >> -------------------------------------- >> RFC4566 (draft-ietf-mmusic-sdp-new-26) >> -------------------------------------- >> Title : SDP: Session Description Protocol >> Publication Date : July 2006 >> Author(s) : M. Handley, V. Jacobson, C. Perkins >> Category : PROPOSED STANDARD >> Source : Multiparty Multimedia Session Control >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine
- [MMUSIC] [Technical Errata Reported] RFC4566 (327… RFC Errata System
- Re: [MMUSIC] [Technical Errata Reported] RFC4566 … Miguel A. Garcia
- Re: [MMUSIC] [Technical Errata Reported] RFC4566 … Stach, Thomas
- Re: [MMUSIC] [Technical Errata Reported] RFC4566 … Riccardo Bernardini
- Re: [MMUSIC] [Technical Errata Reported] RFC4566 … Ali C. Begen (abegen)
- Re: [MMUSIC] [Technical Errata Reported] RFC4566 … Miguel A. Garcia