Re: [AVT] Open issue on hdrext draft

Dave Singer <singer@apple.com> Thu, 04 October 2007 15:50 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSxv-00044U-Iz; Thu, 04 Oct 2007 11:50:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdSxt-00043r-Ne for avt@ietf.org; Thu, 04 Oct 2007 11:50:17 -0400
Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdSxl-0005sJ-H0 for avt@ietf.org; Thu, 04 Oct 2007 11:50:17 -0400
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 12832148BFC5; Thu, 4 Oct 2007 08:50:03 -0700 (PDT)
Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id EA34928059; Thu, 4 Oct 2007 08:50:02 -0700 (PDT)
X-AuditID: 11807130-a3bc2bb000004daf-8f-47050baa8a96
Received: from [17.202.37.243] (unknown [17.151.104.94]) by relay11.apple.com (Apple SCV relay) with ESMTP id 714402804E; Thu, 4 Oct 2007 08:50:02 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240828c32aba6c7498@[17.202.37.243]>
In-Reply-To: <4704D1F5.3010809@ericsson.com>
References: <C84E0A4ABA6DD74DA5221E0833A35DF30A00EA36@esebe101.NOE.Nokia.com> <4704D1F5.3010809@ericsson.com>
Date: Thu, 04 Oct 2007 08:48:23 -0700
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Imed.Bouazizi@nokia.com
From: Dave Singer <singer@apple.com>
Subject: Re: [AVT] Open issue on hdrext draft
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: fluffy@cisco.com, tom.taylor@rogers.com, avt-chairs@tools.ietf.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

At 13:43  +0200 4/10/07, Magnus Westerlund wrote:
>Imed.Bouazizi@nokia.com skrev:
>>  Hi,
>>
>>  An RTP gateway (translator/mixer) that for some reason does not
>>  receive/parse the SDP and is then not aware of the mapping between the
>>  RTP header extension and the ID will not be able to process the RTP
>>  packet appropriately. This speaks for IETF agreed registration (option
>>  c).
>
>I think this is an irrelevant comment as any mixer or translator that
>needs to understand the packet content anyway will require to be part of
>the signalling context. Thus, I don't think there is a any benefit at
>all with static mappings.

I agree;  the general question "should RTP packets be comprehensible 
without their signaling context" is outside the scope of this 
discussion (though my sense is that the consensus direction is "no", 
as shown, for example, by the fact that we no longer approve of 
static payload type mappings).

>
>What we are discussing is what rules applies for the IETF URN space,
>i.e. the header extensions that will look like they are blessed by IETF.
>The current draft version was in fact a) as this specified
>"Specification Required" from RFC 2434:
>
>"      Specification Required - Values and their meaning must be
>            documented in an RFC or other permanent and readily available
>            reference, in sufficient detail so that interoperability
>            between independent implementations is possible."
>
>I think A is fine but would probably prefer this to be b) with explicit
>rule requiring a publicly available specification.

I'm sorry, I may have mis-written something, since I tried to agree 
with you here!  The current intention is that for the IETF URN space, 
a standards-track RFC is required.  And that for IANA registration, 
an IETF URN is required:

"To be registered
    with IANA, the extension MUST use this IETF URN form; to use the IETF
    URN form, the extension MUST be defined in an RFC."

If there is other text that isn't clear, can you tell me what it is?

>Having an expert look
>at any registrations to ensure that they are not totally wacko is in my
>book a good thing.

Me too, no dispute here.

>But at the same time put minimal bar on the
>registrations. Other SDOs should basically be able to send in an email
>with a request containing a reference and things usually go through.
>

So, you would permit non-IETF URIs in the IANA registry, also, after, 
what 'expert review' and with 'publicly available specification 
required'?

That's fine by me also.

-- 
David Singer
Apple/QuickTime

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt