Registration review for vnd.americandynamics.acc

[Sands, Gary]

Colin,

Thanks for your advice. I'll submit the registration request with your
suggestions for RTP only as follows.

-------

Type name: video
 
   Subtype name: vnd.americandynamics.acc
 
   Required parameters: rate (RTP only)
 
   Optional parameters: none
 
   Encoding considerations: This media type is framed binary data (see
RFC 4288, Section 4.8)

   Security considerations: ACC is a binary file format that contains no
active content and no textual information.
 
   Interoperability considerations: none
 
   Published specification: none
 
   Applications that use this media type: Intellex DVMS, Intellex
Management Suite
 
   Additional information:
 
     Magic number(s):
     File extension(s): acc
     Macintosh file type code(s):
 
   Person & email address to contact for further information: gsands AT
tycoint.com
 
   Intended usage: LIMITED USE
 
   Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP (RFC 3550). Transfer within
other framing protocols is not defined at this time.

   Author: gsands AT tycoint.com
 
   Change controller: gsands AT tycoint.com

-------

Regards,
Gary


 
--------------------------------------------------------

Tyco Safety Products/CEM Systems Ltd.
Registered in Northern Ireland: NI 25728.  Registered Office: Unit 4 Ravenhill Business Park, Ravenhill Road, Belfast, BT6 8AW..
 
Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete any copies in your possession.
 
-----Original Message-----

From: Colin Perkins [mailto:csp at csperkins.org] 
Sent: 12 December 2007 18:38
To: Sands, Gary
Cc: ietf-types at iana.org
Subject: Re: Registration review for vnd.americandynamics.acc

Gary,

On 10 Dec 2007, at 14:23, Sands, Gary wrote:
> My intention was to register this type for RTP use only - hence my  
> statement for "Restrictions on usage" that the type could be  
> transmitted over RTP. I was following RFC 4855 Section 2 part (a)  
> "Not yet registered as a media type" (or so I thought) by stating  
> it defined for RTP transfer and saying nothing else.
>
> It probably would be better phrased as "This type may *only* be  
> transmitted over RTP". Admittedly the original statement is rather  
> terse and the comment for "Encoding considerations" about non- 
> binary transports may have implied the possibility of other  
> transport methods.

Right - I read the registration as allowing transfer over RTP, but  
not being restricted to that environment.

> If someone wanted to use a media sub-type over other transports  
> would a statement for "Restriction on usage" such as the following  
> suffice?
>
> "Restrictions on usage - This type may be transmitted over RTP.  
> However the file format is equivalent to the concatenated sequence  
> of payloads from RTP packets not including the RTP headers or any  
> RTP payload-format headers. Therefore the type may be shared for  
> non-RTP file-based transmission. The file format may/shall include  
> a magic number/header at the start of the file that is not included  
> when the data is transferred via RTP."

If the intent is to register a type for use with RTP only, then the  
usual approach is to state "This media type is framed binary data  
(see RFC 4288, Section 4.8)" under Encoding Considerations (this is  
different to binary data, since it requires knowledge of the framing  
protocol to make sense of the data), and in Restrictions on usage,  
state "This media type depends on RTP framing, and hence is only  
defined for transfer via RTP (RFC 3550). Transfer within other  
framing protocols is not defined at this time".

If you want to define framing for other environments, that's  
appropriate given the constraints from RFC 4855 section 2.2 (that the  
media data is the same in all cases, and only the framing protocol  
differs), but you need to change the wording to indicate what types  
of framing are acceptable, and specify how the framing protocols  
encapsulate the media type. This can be done in the Restrictions on  
Use section, stating something similar to "This media type requires  
knowledge of the framing mechanism to interpret the data. RTP [RFC  
3550] provides one appropriate framing protocol. Alternatively, a  
sequence of complete frames may be concatenated preceded by the magic  
number [whatever] for file storage, or for transport over reliable  
byte stream protocols".

It would be helpful if the RTP payload format or details of the media  
format were publicly documented. The IETF AVT working group can give  
advice on the development and publication an RTP payload format, if  
desired. Note: this doesn't require publishing the codec specification.

-- 
Colin Perkins
http://csperkins.org/