Registration review for vnd.americandynamics.acc

[Sands, Gary]

Colin,

 

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.

 

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."

 

(BTW this is fairly close to the language mentioned in RFC 4855 Section
2.2.)

 

Regards,

 

Gary

 

________________________________

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

 

Gary,

 

Note that media type registrations for types designed for transfer using
RTP should follow the guidelines and recommendations of RFC 4855, in
addition to those in RFC 4288. In particular, RFC 4855 requires
additional documentation to indicate whether the type is defined for
both RTP and non-RTP use, and if so, to specify any required framing.
Such documentation is missing from this draft registration.

 

Regards,

Colin Perkins (IETF AVT co-chair)

 

 

 

 

 

On 27 Nov 2007, at 04:15, Sands, Gary wrote:

	
	American Dynamics intends to submit the following registration
to IANA.
	As recommended by RFC4288 I submit the intended registration for
a two week review period.
	 
	   Type name: video
	 
	   Subtype name: vnd.americandynamics.acc
	 
	   Required parameters: rate (RTP only)
	 
	   Optional parameters: none
	 
	   Encoding considerations:
	   ACC video data is binary data and must be encoded for
non-binary transport - typically BASE64.
	 
	   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 type may be transmitted over RTP.
	 
	   Author: gsands AT tycoint.com
	 
	   Change controller: gsands AT tycoint.com
	 
	 
	 
	Other information
	 
	Active Content Compression (ACC) is a proprietary video
compression that is optimised for CCTV applications. ACC has been
deployed world-wide in security applications since 1997.
	 
	A white paper on ACC is available at 
	
http://americandynamics.net/webapps/getdocument.aspx?filename=whitepaper
_acc_lt_en.pdf
	 
	 

	 

	 

	 

	
________________________________


	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.

 

-- 

Colin Perkins

http://csperkins.org/





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20071210/5b832fa6/attachment-0001.html