[MMUSIC] UPDATED: draft-ietf-mmusic-rfc4566bis-36.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 18 June 2019 18:27 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6752712041B for <mmusic@ietfa.amsl.com>; Tue, 18 Jun 2019 11:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id R2rJGRY_xQo5 for <mmusic@ietfa.amsl.com>; Tue, 18 Jun 2019 11:27:09 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C0612041A for <mmusic@ietf.org>; Tue, 18 Jun 2019 11:27:08 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x5IIR6eQ009479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Tue, 18 Jun 2019 14:27:07 -0400
References: <156087807039.8279.7260561886700433766.idtracker@ietfa.amsl.com>
To: IETF MMUSIC WG <mmusic@ietf.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Forwarded-Message-Id: <156087807039.8279.7260561886700433766.idtracker@ietfa.amsl.com>
Message-ID: <8fdacb30-9cba-6827-dd53-146e04d6eb40@alum.mit.edu>
Date: Tue, 18 Jun 2019 14:27:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <156087807039.8279.7260561886700433766.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/PvJNQLuNTx2GdzlSv82_D_eRWN4>
Subject: [MMUSIC] UPDATED: draft-ietf-mmusic-rfc4566bis-36.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 18 Jun 2019 18:27:11 -0000

Here is updated version of RFC4566bis. The -36 version addresses IESG 

For just these most recent changes, since -35:

For all changes since RFC4566:

Of particular note:

The description of a=type said that the values it mentions are 
"suggested", implying that others may be possible without defining any 
way to define semantics for them. This wasn't written in a normative way.

I've reworded the section (6.9) so the listed values are exhaustive. But 
I didn't include any mechanism for backward compatible extensions. I'm 
now thinking we should at least provide a hook for other values and a 
statement that unknown values are to be ignored.

That section also said that a=type:broadcast changes the *default* media 
direction to "recvonly" rather than "sendrecv". Again this used 
non-normative language. And "recvonly" in the SDP wouldn't be the right 
thing in an offer/answer context.

I reworded this to say that various values of a=type ought to be 
accompanied by some other option settings without saying that those 
somehow become default.

I'd especially like to have feedback on the revisions to this section.

The other changes are rather extensive. So I would very much like 
careful review of these changes.


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-36.txt
Resent-From: pkyzivat@alum.mit.edu
Date: Tue, 18 Jun 2019 10:14:30 -0700
From: internet-drafts@ietf.org
To: mmusic-chairs@ietf.org, Mark Handley <m.handley@cs.ucl.ac.uk>;, Ali 
Begen <ali.begen@networked.media>;, Colin Perkins <csp@csperkins.org>;, 
Mark Handley <M.Handley@cs.ucl.ac.uk>;, Paul Kyzivat <pkyzivat@alum.mit.edu>;

A new version of I-D, draft-ietf-mmusic-rfc4566bis-36.txt
has been successfully submitted by Paul Kyzivat and posted to the
IETF repository.

Name:		draft-ietf-mmusic-rfc4566bis
Revision:	36
Title:		SDP: Session Description Protocol
Document date:	2019-06-18
Group:		mmusic
Pages:		62
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-36

    This memo defines the Session Description Protocol (SDP).  SDP is
    intended for describing multimedia sessions for the purposes of
    session announcement, session invitation, and other forms of
    multimedia session initiation.  This document obsoletes RFC 4566.


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat