Registration of media type application/vnd.emclient.accessrequest+xml
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. 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. 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: None. Applications that use this media type: eM Client IceWarp Mail Server Additional information: Magic number(s): File extension(s): Macintosh file type code(s): Person & email address to contact for further information: Filip Navara <navara@emclient.com> Libor Grafnetr <grafnetr@emclient.com> Intended usage: COMMON Restrictions on usage: None Author: Filip Navara, Libor Grafnetr Change controller: Filip Navara, Libor Grafnetr
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.
participants (2)
-
Filip Navara -
Mark Baker