Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED

Christian Groves <Christian.Groves@nteczone.com> Wed, 13 August 2014 23:42 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4401A0250 for <mmusic@ietfa.amsl.com>; Wed, 13 Aug 2014 16:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.3
X-Spam-Level: *
X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6] autolearn=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 qMP8D0Y0Q9RG for <mmusic@ietfa.amsl.com>; Wed, 13 Aug 2014 16:42:36 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410611A01AF for <mmusic@ietf.org>; Wed, 13 Aug 2014 16:42:36 -0700 (PDT)
Received: from ppp118-209-186-33.lns20.mel6.internode.on.net ([118.209.186.33]:53357 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1XHi9d-0003Bf-VX for mmusic@ietf.org; Thu, 14 Aug 2014 09:40:30 +1000
Message-ID: <53EBF7E4.8030502@nteczone.com>
Date: Thu, 14 Aug 2014 09:42:28 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic mailing list <mmusic@ietf.org>
References: <53E93F39.5090401@alum.mit.edu> <53E97AA4.7050000@nteczone.com> <53EA3BC4.6090506@alum.mit.edu> <53EAC3BC.9050209@nteczone.com>
In-Reply-To: <53EAC3BC.9050209@nteczone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TXSRcWIM5yrFxnflvQMZnTFFNw8
Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 13 Aug 2014 23:42:37 -0000

> Hello Paul,
>
> No worries. Please see below.
>
> I guess the question is whether you want to use the same syntax as 
> what has already been defined or whether you want to offer new syntax 
> imposing extra restrictions. No clear answer on that one.
>
> Regards, Christian
>
> On 13/08/2014 2:07 AM, Paul Kyzivat wrote:
>> Christian,
>>
>> Thanks for being the first with feedback! Comments inline.
>>
>>     Thanks,
>>     Paul
>>
>> On 8/11/14 10:23 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> A few comments:
>>>
>>> a=rtpmap:
>>> -----------
>>>      a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
>>>        parameters>]
>>>
>>>           Syntax:
>>>
>>>           rtpmap-value = payload-type SP encoding-name "/" clock-rate
>>>             [ "/" encoding-params ]
>>>           payload-type = integer
>>>           encoding-name = token ; ?
>>>           clock-rate = integer
>>>             ; do we want to define a limited range for this?
>>>           encoding-params = token ; ?
>>>             ; 4566 is vague about what this can be. The only example is
>>> an integer.
>>>             ; nor is it clear how multiple params would be encoded
>>>
>>> 1) Would you be better sticking to "fmt" for the payload-type as 
>>> that is
>>> what is already used in the 4566 syntax? i.e.
>>>
>>>     media-field =         %x6d "=" media SP port ["/" integer]
>>>                           SP proto 1*(SP fmt) CRLF
>>
>> rtpmap is only used for protos from the rtp family, where the fmts 
>> are integers. So I don't think we should be more general than that.
>>
>> IIUC, the pt is carried in a fixed size field in RTP, so we might 
>> want to limit the range to what that allows.
> [CNG] I was thinking also of consistency. Your a=ftmp syntax uses 
> "fmt" for the same field.
>
>>
>>> 2) encoding-name: According to RFC4855 the media subtype 
>>> (encoding-name)
>>> is encoding according to RFC2045 i.e. subtype := extension-token /
>>> iana-token. If you want to get more precise you could refer to RFC4288
>>> cl. 4.2.
>>
>> Thanks for the research!
>>
>> Section 3 of RFC4855 (Media Type Registration of RTP Payload Formats) 
>> says that encoding-name is equivalent to <subtype> defined in RFC2045.
>> This ultimately seems to be <token> defined in that rfc. And that is:
>>
>>      token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>>                  or tspecials>
>>
>>      tspecials :=  "(" / ")" / "<" / ">" / "@" /
>>                    "," / ";" / ":" / "\" / <">
>>                    "/" / "[" / "]" / "?" / "="
>>
>> This is hard to reference directly. But if you study it, it is 
>> equivalent to the RFC4566 definition of <token>.
>>
>> RFC4855 also refers to RFC4288 (Media Type Specifications and 
>> Registration Procedures) as the basic mechanism for registering 
>> encoding-names as mime subtypes. The definition there is more 
>> restrictive:
>>
>>        reg-name = 1*127reg-name-chars
>>        reg-name-chars = ALPHA / DIGIT / "!" /
>>                        "#" / "$" / "&" / "." /
>>                        "+" / "-" / "^" / "_"
>>
>> So I think we have to possibilities:
>>
>>          encoding-name = token
>>          encoding-name = subtype-name
>>            ; as defined in RFC4288
>>
>> Since the names must be registered, I think we are safe in going the 
>> easy way and just using <token>.
> [CNG] I think it would be better to use the restrictive syntax. If the 
> IANA procedures say one thing and the syntax another, its open to 
> heartache at some point. Token doesn't equal reg-name.
>
>>
>>> 3) RFC4855 last paragraph cl.3 indicates case insensitivity.
>>
>> OK. That has to be specified in semantics, not syntax.
> [CNG] Yes
>>
>>> 4) For the Clock Rate and Encoding parameters RFC4288 cl.4.3 indicates
>>> requirements for the names / values.
>>
>> That gives the generic syntax for all names and values. But these 
>> parameters are intended to be numeric. Do we really want to use a 
>> syntax that allows them to be non-numeric?
> [CNG] I agree clock rate is meant to be numeric. The general encoding 
> parameters could basically be anything.
>>
>>> a=sdplang & a=lang
>>> --------------------
>>> 1) Do you have the right reference in:
>>> sdplang-value = Language-Tag ; defined in RFC5234
>>>
>>> should this be RFC5646?
>>
>> Yes. That is where I was looking. I just typed the wrong thing.
>>
>> Examining that definition further, it is a proper subset of SDP 
>> <token>. We may prefer to just use that, since the registries will 
>> enforce the subsetting for valid tags.
> [CNG] Even though it may ultimately be a token I think its worth 
> referencing the RFC5646 syntax. At least people then are forced to try 
> and understand it. If its just left as TOKEN it could be anything.
>>
>>
>>> a=framerate
>>> -----------
>>> 1) positive-real-number = (integer / "0") [ "." *integer ]  is the *
>>> before the last integer needed? It would make sense if integer was 
>>> digit.
>>
>> Oops. What I meant was:
>>
>>          positive-real-number = (integer / "0") [ "." [integer] ]
>>
>> Or we could be more restrictive, as:
>>
>>          positive-real-number = (integer / "0") [ "." integer ]
> [CNG] I can't see why someone would use "1." which the first option 
> would allow. I'd prefer the restrictive option however I can see the 
> argument that given the number of implementations out there it may pay 
> to be more lax.
>>
>>
>>> a=quality
>>> ---------
>>> 1) If the value range is 0 to 10. Should you limit the values in the
>>> syntax also? i.e. just using "integer" would allow sending "11".
>>
>> I saw that. But it says *for video* the range is 0 to 10. But AFAIK 
>> this isn't restricted to use for other types of media. It just 
>> doesn't define what it means for other media.
> [CNG] Perhaps it might be worth proposing that this is only for video 
> and see if anybody screams? If someone is using a value quality=150 
> for audio. What does that mean? Outside of some proprietary usage it 
> doesn't seem particularly interoperable.
>>
>>     Thanks,
>>     Paul
>>