Registration of media type application/vnd.emclient.accessrequest+xml

[Filip Navara]

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 at coactus.com> 
> To: Filip Navara <navara at emclient.com> 
> Cc: "ietf-types at iana.org" <ietf-types at 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 at 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.