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.
On 11/13/07, Ted Hardie <hardie(a)qualcomm.com> wrote:
> This is a request for review application/lost+xml, which is
> described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt .
> Comments to the authors or the working group mailing list (ecrit(a)ietf.org)
> would be welcome; cc'ing any comments to the AD (Jon Peterson,
> jon.peterson(a)neustar.biz) would also be welcome since this is currently
> also in his review queue.
The media type registration itself is pretty straightforward, though
the security considerations section needs work.
I have some other comments too, while I'm here.
It's unfortunate that HTTP continues to be referred to, and used as, a
"transport" protocol. This draft isn't as bad as some others in that
respect, but I have some concerns. Chief amoungst these is that LoST
errors are returned with HTTP success status codes, which they should
not be: even SOAP managed to get this one right 8-). Also, the names
of the root XML elements seem to conflate data and protocol, i.e.
"findService" and "findServiceResponse". It's the application
protocol that determines what constitutes a request and a response, as
well as whether the operation is "find" or not (it's not, it's POST).
If I were doing this, I'd use "serviceDescription" and "service" or
something like that. This is largely aesthetic right now, but in my
experience such a change can prevent problems down the line, such as
suggesting the use of new root elements for new services that might be
added in the future, instead of the proper HTTP-friendly way, new
URIs.
More generally, I think it would be useful to show evidence that BCP
56 has been consulted in the preparation of the HTTP binding.
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
This is a request for review application/lost+xml, which is
described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt .
Comments to the authors or the working group mailing list (ecrit(a)ietf.org)
would be welcome; cc'ing any comments to the AD (Jon Peterson,
jon.peterson(a)neustar.biz) would also be welcome since this is currently
also in his review queue.
thanks,
Ted
Hi,
RFC 2616 discourages naming media type parameters "q" as it uses the
name for content negotiation in the Accept header. Unfortunately this
never made its way into the registration procedures document. Is there
anything we can and should do to transfer the discouragement into BCP
13 (errata, let RFC 2616bis update BCP 13, ...)?
regards,
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
