RE: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt

ned.freed@mrochek.com Thu, 09 September 2004 17:00 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04195 for <avt-archive@ietf.org>; Thu, 9 Sep 2004 13:00:12 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5SLJ-00067X-7m for avt-archive@ietf.org; Thu, 09 Sep 2004 13:04:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5S4r-0001XB-3t; Thu, 09 Sep 2004 12:47:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Rx3-0007pm-Ag for avt@megatron.ietf.org; Thu, 09 Sep 2004 12:39:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02178 for <avt@ietf.org>; Thu, 9 Sep 2004 12:39:10 -0400 (EDT)
From: ned.freed@mrochek.com
Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5S0v-0005bJ-IN for avt@ietf.org; Thu, 09 Sep 2004 12:43:15 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LEMZKBB1XC00005R@mauve.mrochek.com> for avt@ietf.org; Thu, 09 Sep 2004 08:41:58 -0700 (PDT)
Date: Thu, 09 Sep 2004 08:37:52 -0700
Subject: RE: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-reply-to: "Your message dated Thu, 09 Sep 2004 11:54:06 +0200" <FDEEJECAGFFPBFPHMIIPCEPLIFAA.rey@panasonic.de>
To: Jose Rey <rey@panasonic.de>
Message-id: <01LENOBSXTWW00005R@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Content-transfer-encoding: 7bit
References: <01LEKW44X2UM00005R@mauve.mrochek.com> <FDEEJECAGFFPBFPHMIIPCEPLIFAA.rey@panasonic.de>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, 'ietf-typesianaorg' <ietf-types@iana.org>, ned.freed@mrochek.com, IETF AVT WG <avt@ietf.org>, John C Klensin <klensin@jck.com>
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>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit

> > > When one has limited usage, like say "only for usage in RTP" I think
> > > there are need to consider some wider interpretation of what "to some
> > > extent readable" means. We had an example in the 3GPP timed text
> > > discussion, where the RTP payload format consists of embedded UTF-8 or
> > > UTF-16 strings in an otherwise binary format. However for RTP that is
> > > the common case. Should such any clarification on the performance of
> > > such consideration be written into this spec or do it belong to a
> > > further registration document in relation do a specific domain of usage?

> > I would say it belongs in the registration document.

> does such a clarification belong under "Encoding considerations" or under
> "Restrictions on usage"?  Until now most payload formats included a sentece
> like "This type is only defined for transfer via RTP." under encoding
> considerations.  In this case, is it not more appropriate to do this under
> "Restrictions on usage"?

Encoding considerations is really intended to be a single value chosen
from a list. As such, this really belongs under restrictions on usage.

> This is how it would look like in our case:

> "Encoding considerations:

> RTP payloads conforming to this payload format do not comply with the strict
> rules for registration under the 'text' top-level MIME type, as outlined in
> RFC 2026 and its revision RFCYYYY [].

Wrong RFC # here,, I believe. Additionally, I don't see this as a case of
noncompliance with the revised rules. A better approach would be to say that
this type is incompatible with use of text media types in other protocols.

> The reason for this is that the RTP
> client must, at least, understand the payload format fields (in binary) in
> order to decode the timed text contents (partly text strings, partly
> binary).  This binary information is not considered 'directly readable'
> without 'special software' as required for 'text' subtypes (in contrast to
> text strings).  Around the 60th IETF it was decided to relax these rules for
> RTP payload formats.  In particular, it was allowed to register RTP payload
> formats under the 'text' top-level type (if appropriate) as long as the
> domain of applicability of the format is clearly specified (e.g. only for
> transmission using RTP).  This payload format complies with these 'relaxed'
> rules.

I don't think having this sort of historical note in a registration is
appropriate either. 

				Ned

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