Hello, sorry for late reply. You might be right about the "version" parameter, we included it only to prevent compatibility problems in future and we actually don't plan to use it. Your suggestion of new MIME type seems reasonable and we might as well drop the parameter entirely (and keep the "1.0" value as only possible, for compatibility). The "Encoding considerations" section has been changed to match RFC 3023. It's primarily used as XML MIME part inside an e-mail message. There is no published specification currently and there will not be one until May or so. Thanks for suggestions. Best regards, Filip Navara
-----Original Message----- From: Mark Baker <mark@coactus.com> To: Filip Navara <navara@emclient.com> Cc: "ietf-types@iana.org" <ietf-types@iana.org> Date: 02/19/09 22:17 Subject: Re: Registration of media type application/vnd.emclient.accessrequest+xml
On Thu, Jan 22, 2009 at 11:14 AM, Filip Navara <navara@emclient.com> wrote:
Type name: application
Subtype name: Vendor Tree - vnd.emclient.accessrequest+xml
Required parameters: none
Optional parameters:
version - in the X.Y notation where X specifies major version change and Y specifies minor version change. Applications supporting this MIME type should not try to process the content unless the major version number is recognize by the particular implementation.
I would recommend against this approach if not too late to change it in your software. If a change occurs to the format such that old software will not be able to process new documents, then you should mint a new media type.
Encoding considerations:
The content of this media type consists of lines of 7bit or 8bit text. In the latter case use of quoted-printable or base64 may be needed when operating over 7bit transports.
I'm confused. If you're using the "+xml" suffix, the format needs to be XML based and not some transformed version of XML. Transfer codings ala HTTP are of course permitted, but it's not clear to me that this is what you're talking.
Security considerations:
The type exists to provide a limited and safe subset of operations to media authors, but the full spectrum of security issues associated with this type has not been completely assessed. Explicit actions based on the content should be done only after confirmation by the recepient. Embedding inside S/MIME container with digital signature is recommended. See RFC 3023, section 10 for a more complete analysis of XML related security issues.
Interoperability considerations:
There are no special known interoperability issues, but the full spectrum of interoperability issues associated with this type has not been completely assessed.
Published specification:
Is there one?
Mark.