Re: [MMUSIC] Draft new version: T140-data-channel -02 - Reference RFC 4566 for direction attributes and not RFC 3264

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 05 September 2019 15:22 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 581BA120255 for <mmusic@ietfa.amsl.com>; Thu, 5 Sep 2019 08:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr-Y8Au9csRJ for <mmusic@ietfa.amsl.com>; Thu, 5 Sep 2019 08:22:54 -0700 (PDT)
Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 AF44D120154 for <mmusic@ietf.org>; Thu, 5 Sep 2019 08:22:53 -0700 (PDT)
X-Halon-ID: fb91e185-cff0-11e9-bdc3-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id fb91e185-cff0-11e9-bdc3-005056917a89; Thu, 05 Sep 2019 17:22:33 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <74EDF323-AE38-4D58-8006-D50B89348CFA@ericsson.com> <a0d1110e-5be2-6e69-dbc4-9fd9f2995a47@omnitor.se> <F6296225-7402-41FE-A5DF-C7265DC4B97B@ericsson.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <308eedff-2b7e-d3e2-3ff4-9dc7c7c1beca@omnitor.se>
Date: Thu, 05 Sep 2019 17:22:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <F6296225-7402-41FE-A5DF-C7265DC4B97B@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/10LGlmYSkcatKGuKP14sdup8YrU>
Subject: Re: [MMUSIC] Draft new version: T140-data-channel -02 - Reference RFC 4566 for direction attributes and not RFC 3264
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: Thu, 05 Sep 2019 15:22:58 -0000

Hi,

Den 2019-09-05 kl. 07:04, skrev Christer Holmberg:
> Hi,
>
>> I have created a number of pull requests to the GitHub repository for  draft-holmberg-mmusic-t140-usage-data-channel-02
>>
>> Many are editorial. A few require discussion in the list.
>>
>> This is one that requires discussion:
>>
>> I suggest that RFC 3264 is deleted as reference for how the direction attributes 'sendonly' etc. RFC 4566 is already also used as reference
>> for how to handle the direction attributes. This is in section 3.2.3
>> I think that RFC 3264 just adds confusion and a lot of detail for RTP use of the direction attributes that is irrelevant for the T.140 data channel case.
> This can be split into two parts:
>
> First, since we do mention "offer/answer" (as we define the o/a T.140 data channel procedures for the direction attributes), we DO at least need a reference to 3264 for terminology purpose.
>
> Second, the draft DOES define the offer/answer procedures for the T.140 direction attributes, so from that perspective we do not need a reference the procedures in 3264. However, I DO think it is a good idea to indicate that the procedures are based on the procedures in 3264. It makes it more clear for implementers etc.

Yes, "the procedures are based on the procedures in 3264" sounds 
suitable. The wording about the direction attributes in RFC 3264 is full 
of wording about ports and payload types etc. In many cases, but not 
all, it mentions what is only valid for RTP transport, so it would not 
be right to say that it is the RFC 3264 procedures that are used. But OK 
for referencing RFC 3264 in a mild way. I hope you can propose wording.

Regards

Gunnar

>
> Regards,
>
> Christer
>
>
>
>
>
> Den 2019-09-03 kl. 14:10, skrev Christer Holmberg:
> Hi,
>   
> I have mereged the following PR:
>   
> https://protect2.fireeye.com/url?k=b96a065f-e5e3dc4f-b96a46c4-0cc47ad93e2a-665164b51729ecbf&q=1&u=https://github.com/cdh4u/draft-datachannel-t140/pull/6
>   
> …and submitted a new version (-02) of draft-holmberg-mmusic-t140-usage-data-channel.
>   
> The main changes are:
>   
> - IANA registry update for SDP attributes that can be included in dcsa attributes
> - Detailed procedures on usage of the direction attributes inside dcsa attributes
>   
> Regards,
>   
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> mailto:mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288