Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

From: Pete Resnick <[email-masked]>
Date: Fri, 15 Apr 2011 12:18:12 -0500

On 4/5/11 6:34 PM, Brian Clubb wrote:
>
> I am requesting final approval of the MIME type registration for 
> OpenXPS.  I have received two threads with questions during the open 
> comment period and addressed all issues in the template (see threads 
> ending with these links: 
> http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170.html; 
> http://www.ietf.org/mail-archive/web/ietf-types/current/msg01182.html).  
> There have been no additional comments within the last two weeks.
>
> Please let me know if you have any additional concerns with this 
> request.  I look forward to your approval on this matter.
>

Hi Brian,

I was reading this over to get it on the next IESG agenda for approval. 
I had a couple of questions. I apologize if any of them are dumb 
questions or rehashes, but I'm just coming up to speed after taking this 
over from Alexey. You have the misfortune of being the "transition" 
registration. Please be patient with me.

(I'm Cc'ing ietf-types just in case anyone there has any followup.)

> Security considerations :
>
> OpenXPS uses ZIP compression as specified in .ZIP File Format 
> Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed 
> XML requires parsing untrusted XML data and untrusted ZIP data.  
> consumer is responsible for validating the .zip archive, the XML 
> structure, and the resource content.
>

I assume there needs to be a "The" before "consumer"?

> Valid content is described in the EMCA-388 specification 
> (http://www.ecma-international.org/publications/standards/Ecma-388.htm)
>
> Also see section E.3 of ECMA-388 specification 
> (http://www.ecma-international.org/publications/standards/Ecma-388.htm)
>
> OpenXPS Documents follow requirements set out in this Standard, as 
> well as other normative references including the Open Packaging 
> Conventions. Implementations may use the following steps to identify 
> an unknown file or stream as an OpenXPS Document within an Open 
> Packaging Conventions payload.
>

Is everything starting with "OpenXPS Documents follow..." a quote from 
ECMA-388 E.3? If so, it needs to be set off somehow. Would this be a 
reasonable replacement?

Valid content is described in the ECMA-388 specification 
<http://www.ecma-international.org/publications/standards/Ecma-388.htm>. 
Especially take note of section E.3:

     OpenXPS Documents follow requirements set out in this Standard, as
     well as other normative references including the Open Packaging
     Conventions. Implementations may use the following steps to identify
     an unknown file or stream as an OpenXPS Document within an Open
     Packaging Conventions payload.

The formatting on the next bit was mashed up. Is the following correct?

     1. Test that the file or stream is a ZIP file

         a. As required by §9.2 of the Open Packaging Conventions

         b. First four bytes correspond to the local file header
         signature defined in the .ZIP File Format Specification from
         PKWARE, Inc., version 6.2.0 (2004)

     2. Test that a valid Package Relationships zip item exists

         a. As required by §8.3.4 of the Open Packaging Conventions

         b. Check that the content type for the package relationships zip
         item is correctly defined in the Content Types stream (see OPC
         §8.1.2) as a relationships part

     3. Test that the Package Relationships Part contains a relationship
     (see OPC §8.3) whose Target attribute points to a valid
     FixedDocumentSequence Part

         a. As required by §10.2 of this Standard

         b. Check that the content type for the FixedDocumentSequence
         part is correctly defined in the Content Types stream as a
         FixedDocumentSequence part

I'm not entirely clear on the need for this discussion in the template. 
Do folks implementing the media type need to know this?

> Applications which use this media :
>
> The application/oxps MIME type can be used to identify CSTA XML...
>

That's a typo, yes? It should be application/OpenXPS?

> Person & email address to contact for further information:
>
> Ecma International Helpdesk
>
> Rue du Rhone114
>
> CH-1204 Geneva
>
> Switzerland
>
> [email-masked]
>
> Person to contact for further information :
>
> 1. Name : Ecma International Helpdesk
>
> 2. Email : [email-masked]
>

Is that intended to be duplicated?

Thanks for bringing me up to speed. We'll get it on the next agenda and 
get it approved.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Brian Clubb <[email-masked]>
Date: Fri, 15 Apr 2011 18:14:10 +0000

Pete,

Thanks for your response!  I have answered the questions inline.  Please let me know if you have any other items you would like me to address.

Thanks!
Brian

From: Pete Resnick [mailto:[email-masked]]
Sent: Friday, April 15, 2011 10:18 AM
To: Brian Clubb
Cc: [email-masked]
Subject: Re: Request for final approval for OpenXPS MIME type

On 4/5/11 6:34 PM, Brian Clubb wrote:
I am requesting final approval of the MIME type registration for OpenXPS.  I have received two threads with questions during the open comment period and addressed all issues in the template (see threads ending with these links: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170.html; http://www.ietf.org/mail-archive/web/ietf-types/current/msg01182.html).  There have been no additional comments within the last two weeks.

Please let me know if you have any additional concerns with this request.  I look forward to your approval on this matter.

Hi Brian,

I was reading this over to get it on the next IESG agenda for approval. I had a couple of questions. I apologize if any of them are dumb questions or rehashes, but I'm just coming up to speed after taking this over from Alexey. You have the misfortune of being the "transition" registration. Please be patient with me.

Security considerations :
OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires parsing untrusted XML data and untrusted ZIP data.  consumer is responsible for validating the .zip archive, the XML structure, and the resource content.

I assume there needs to be a "The" before "consumer"?
[bclubb]  Yes, you are correct.  Thanks for catching this.

Valid content is described in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm)

Also see section E.3 of ECMA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm)

OpenXPS Documents follow requirements set out in this Standard, as well as other normative references including the Open Packaging Conventions. Implementations may use the following steps to identify an unknown file or stream as an OpenXPS Document within an Open Packaging Conventions payload.

Is everything starting with "OpenXPS Documents follow..." a quote from ECMA-388 E.3? If so, it needs to be set off somehow. Would this be a reasonable replacement?

Valid content is described in the ECMA-388 specification <http://www.ecma-international.org/publications/standards/Ecma-388.htm><http://www.ecma-international.org/publications/standards/Ecma-388.htm>. Especially take note of section E.3:

[bclubb]  this revision is fine.

I'm not entirely clear on the need for this discussion in the template. Do folks implementing the media type need to know this?
[bclubb]  I had feedback from Alexey Melnikov that this section should be expanded from my original draft.  Since the OpenXPS document is a series of XML files in a tree structure contained in a ZIP archive, the consumer needs to validate the contents at some point.  This information is in the OpenXPS specification at the section listed (E.3).  I am happy to simply point the reader to that section in the spec instead of specifying this in the template if that is acceptable.

That's a typo, yes? It should be application/OpenXPS?
[bclubb]  Either OpenXPS or oxps is acceptable.  The original non-standard format registered by Microsoft used application/xps.  The extension on the standard format is .oxps and thus it was used here.  However, I see no issues using application/OpenXPS if that is preferred for standardization reasons.

Person & email address to contact for further information:
Ecma International Helpdesk
Rue du Rhone114
CH-1204 Geneva
Switzerland
[email-masked]<mailto:[email-masked]>

1. Name : Ecma International Helpdesk
2. Email : [email-masked]<mailto:[email-masked]>

Is that intended to be duplicated?
[bclubb]  Yes, the duplication is intentional.

Thanks for bringing me up to speed. We'll get it on the next agenda and get it approved.

pr

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 19 Apr 2011 11:53:30 -0500

On 4/15/11 1:14 PM, Brian Clubb wrote:
> I'm not entirely clear on the need for this discussion in the 
> template. Do folks implementing the media type need to know this?
> [bclubb]  I had feedback from Alexey Melnikov that this section should 
> be expanded from my original draft.  Since the OpenXPS document is a 
> series of XML files in a tree structure contained in a ZIP archive, 
> the consumer needs to validate the contents at some point.  This 
> information is in the OpenXPS specification at the section listed 
> (E.3).  I am happy to simply point the reader to that section in the 
> spec instead of specifying this in the template if that is acceptable.
>

I chatted with Alexey about this a bit, and he agrees that it would be 
fine to simply have a pointer instead. So, you can replace all of the 
above with something like this:

"Valid content is described in the ECMA-388 specification 
<http://www.ecma-international.org/publications/standards/Ecma-388.htm>. 
Especially take note of section E.3, which describes steps that can be 
taken to validate the contents of the payload."

> [bclubb]  Either OpenXPS or oxps is acceptable.  The original 
> non-standard format registered by Microsoft used application/xps.  The 
> extension on the standard format is .oxps and thus it was used here.  
> However, I see no issues using application/OpenXPS if that is 
> preferred for standardization reasons.
>

The file type is ".oxps", not the MIME type. The only thing in this 
registration for a MIME type is "application/openxps". Either you have 
to *only* use "application/openxps", or you have to also register 
"application/oxps" if you think both are going to be used. I don't 
really care which.

pr

---

From: Brian Clubb <[email-masked]>
Date: Tue, 19 Apr 2011 17:19:18 +0000

Thanks, Pete!

I updated the template with the last set of edits (replaced long description in Security Considerations with pointer to spec, used application/OpenXPS for MIME type).  I have included the revised template below and attached text file.

Thanks!
Brian

<template>
Name : Brian Clubb

Email : [email-masked]

MIME media type name : application

MIME subtype name : Standards Tree - OpenXPS

Required parameters : N/A

Optional parameters :N/A

Encoding considerations : 8-bit

Security considerations :
OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires parsing untrusted XML data and untrusted ZIP data.  The consumer is responsible for validating the .zip archive, the XML structure, and the resource content.  Per spec, there should be no active content provided as part of the OpenXPS format.  The consumer must ensure that no malicious active content is erroneously provided in the OpenXPS document.  Valid content is described in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm).  Especially take note of section E.3, which describes steps that can be taken to validate the contents of the payload.

Interoperability considerations :
application/OpenXPS documents are specified by the XML schemas
   standardized in ECMA-388.
Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc.

Published specification :
The published Standard ECMA-388 is available at:
http://www.ecma-international.org/publications/standards/Ecma-388.htm

Applications which use this media :
The application/OpenXPS MIME type can be used to identify CSTA XML
(ECMA-388) instance documents.  No published applications or print drivers currently use OpenXPS.  The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information :

1. Magic number(s) : ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive is a valid OpenXPS structure.
2. File extension(s) : .oxps
3. Macintosh uniform type identifier : org.ecma.oxps conforms to com.pkware.zip-archive
4. Object Identifiers: N/A
5. Windows clipboard name:  "OpenXPS"

To ensure interoperability, the clipboard format must be a complete OpenXPS file with .oxps extension.

Intended usage : Common
This type will be used for all documents conforming to the Open XML
   Paper Specifcation's (ECMA-388) Open XPS Document format, published
   by ECMA.

Author/Change controller : The ECMA-388 Standard is developed and
   maintained by the Ecma TC46 Working Group.

</template>

From: Pete Resnick [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 9:54 AM
To: Brian Clubb
Cc: [email-masked]
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

I chatted with Alexey about this a bit, and he agrees that it would be fine to simply have a pointer instead. So, you can replace all of the above with something like this:

"Valid content is described in the ECMA-388 specification <http://www.ecma-international.org/publications/standards/Ecma-388.htm><http://www.ecma-international.org/publications/standards/Ecma-388.htm>. Especially take note of section E.3, which describes steps that can be taken to validate the contents of the payload."

The file type is ".oxps", not the MIME type. The only thing in this registration for a MIME type is "application/openxps". Either you have to *only* use "application/openxps", or you have to also register "application/oxps" if you think both are going to be used. I don't really care which.

pr

--

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Apr 2011 19:32:22 +0200

>MIME subtype name : Standards Tree - OpenXPS

You are using an outdated template; the current one is specified in RFC
4288. It uses different names for some of the fields and distributes the
pieces of information differently.

>Encoding considerations : 8-bit

It seems this should be "binary", see the definitions in RFC 4288.

>2. Email : [email-masked]

It is customary to write this as

  Ecma International Helpdesk <[email-masked]>

(And I am not sure "Ecma" is the preferred spelling).

>Intended usage : Common

This should be spelled COMMON.

I note that per RFC 4288 section 4.10:

  As stated previously, standards tree registrations for media types
  defined in documents produced by other standards bodies MUST be
  described by a formal standards specification produced by that body.
  Such specifications MUST contain an appropriate media type
  registration template taken from Section 10.  Additionally, the
  copyright on the registration template MUST allow the IANA to copy it
  into the IANA registry.

Which section of the specification does include the template, or, if
none at the moment, should we expect the specification to be revised to
include it "soon"?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Brian Clubb <[email-masked]>
Date: Tue, 19 Apr 2011 18:08:53 +0000

Sorry, when I first saw the question about the duplication I thought the question was on the e-mail address provided, I missed the title was duplicated as well.  Yes, this should be struck.  I have attached the updated template without the duplicated section.

Thanks!
Brian

-----Original Message-----
From: Franklin Tse [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2011 11:02 AM
To: Brian Clubb
Cc: [email-masked]
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

Dear Brian,

> [bclubb]  Yes, the duplication is intentional.

The duplication seems not necessary. Why was it intended?

Regards,
Franklin Tse

---

From: "Franklin Tse" <[email-masked]>
Date: Wed, 20 Apr 2011 02:02:29 +0800

Dear Brian,

Regards,
Franklin Tse

---

From: Brian Clubb <[email-masked]>
Date: Thu, 21 Apr 2011 15:47:42 +0000

Bjoern,

Thanks for the feedback!

I have updated the registration using the new template (attached).  "Ecma" is the preferred case usage when talking about the organization but "ECMA" is used when referencing specs; thus "Ecma International Helpdesk" and "Ecma Technical Committee TC46" but the specification is "ECMA-388".

The current ECMA-388 specification is due for editorial reviews and updates this year.  I will make sure that the approved template is in that revision.

Let me know if there is anything else.  I have attached the revised template and provided it below as well.

Thanks!
Brian

<template>
Type name: application/OpenXPS

Subtype name:  Standards Tree - OpenXPS

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary

Security considerations:

Interoperability considerations:
application/OpenXPS documents are specified by the XML schemas standardized in ECMA-388.
Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc.

Published specification:
The published standard ECMA-388 is available at:
http://www.ecma-international.org/publications/standards/Ecma-388.htm

Applications that use this media type:
The application/OpenXPS MIME type can be used to identify CSTA XML
(ECMA-388) instance documents.  No published applications or print drivers currently use OpenXPS.  The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information:

  Magic number(s):  ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive is a valid OpenXPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  org.ecma.oxps conforms to com.pkware.zip-archive

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<[email-masked]>

Intended usage: COMMON

Restrictions on usage:  N/A

Author:  The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46.

Change controller:  The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46.
</template

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2011 10:32 AM
To: Brian Clubb
Cc: Pete Resnick; [email-masked]
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

>MIME subtype name : Standards Tree - OpenXPS

You are using an outdated template; the current one is specified in RFC 4288. It uses different names for some of the fields and distributes the pieces of information differently.

Which section of the specification does include the template, or, if none at the moment, should we expect the specification to be revised to include it "soon"?
--
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Paul Libbrecht <[email-masked]>
Date: Thu, 21 Apr 2011 18:20:07 +0200

Brian,

I note that my comment of March 21st was not responded to, you still use wrongly Macintosh filetype. 
Moreover it appears that the windows clipboard name has disappeared.

Have I missed a bit of discussion about this?

paul

Le 21 avr. 2011 à 17:47, Brian Clubb a écrit :

> <MIMEReg.txt>_______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Brian Clubb <[email-masked]>
Date: Thu, 21 Apr 2011 16:30:11 +0000

Paul,

Please see notes from Bjoern from 19 April.  He pointed out that there is a new template in the RFC and I have used that template in the revision.  I will add the clipboard compatibility note back into the Interoperability section.  However, I will look for guidance from IETF to see if there is any issue with changing "Macintosh file type code(s)" to "Macintosh Uniform Type Identifier" in the prescribed template.

Edited template is attached and provided below.

Thanks!
Brian

<template>

Required parameters:  N/A

Optional parameters:  N/A

Security considerations:
OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires parsing untrusted XML data 

and untrusted ZIP data.  The consumer is responsible for validating the .zip archive, the XML structure, and the resource content.  Per spec, there should be no active content 

provided as part of the OpenXPS format.  The consumer must ensure that no malicious active content is erroneously provided in the OpenXPS document.  Valid content is described 

in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm).  Especially take note of section E.3, which describes steps that can be 

taken to validate the contents of the payload.

Interoperability considerations:
application/OpenXPS documents are specified by the XML schemas standardized in ECMA-388.
Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two 

specifications, such as namespace, print ticket usage, use of JPEG XR, etc.

Published specification:

Applications that use this media type:
The application/OpenXPS MIME type can be used to identify CSTA XML
(ECMA-388) instance documents.  No published applications or print drivers currently use OpenXPS.  The intent is for any application or driver that can currently 

produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, 

Microsoft Internet Explorer 9.

Additional information:

  Magic number(s):  ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of the consumer to ensure that 

the contents of the ZIP archive is a valid OpenXPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  org.ecma.oxps conforms to com.pkware.zip-archive

Intended usage: COMMON

-----Original Message-----
From: Paul Libbrecht [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 9:20 AM
To: Brian Clubb
Cc: Bjoern Hoehrmann; Pete Resnick; [email-masked]
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

Brian,

paul

Le 21 avr. 2011 à 17:47, Brian Clubb a écrit :

>> 1. Name : Ecma International Helpdesk 2. Email : 
> Björn Höhrmann · mailto:[email-masked] · 
> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 
> · http://www.bjoernsworld.de

---

From: Paul Libbrecht <[email-masked]>
Date: Thu, 21 Apr 2011 18:37:06 +0200

Brian,

Indeed adding clipboard types is not part of an RFC (yet?).
Nonetheless, it is possible to ADD additional information without removing the template prescribed ones.
I believe:
- you should leave Macintosh file type and put it as not available
- you should add the two clipboard flavor names (Macintosh UTI and Windows)
- you should any additional information you had in the previous submission (wasn't there a "type identifier" as well?)

paul

Le 21 avr. 2011 à 18:30, Brian Clubb a écrit :

> <MIMEReg.txt>

---

From: Brian Clubb <[email-masked]>
Date: Thu, 21 Apr 2011 17:41:02 +0000

Paul,

That works for me!  Revision attached and included below.  :-)

Thanks!
Brian 

<template>

Required parameters:  N/A

Optional parameters:  N/A

Security considerations:

Published specification:

Additional information:

the contents of the ZIP archive is a valid OpenXPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  not available
	
  Windows Clipboard Name: "OpenXPS"
  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.zip-archive

Intended usage: COMMON

-----Original Message-----
From: Paul Libbrecht [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 9:37 AM
To: Brian Clubb
Cc: Bjoern Hoehrmann; Pete Resnick; [email-masked]
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

Brian,

paul

Le 21 avr. 2011 à 18:30, Brian Clubb a écrit :

> XML requires parsing untrusted XML data
> 
> and untrusted ZIP data.  The consumer is responsible for validating 
> the .zip archive, the XML structure, and the resource content.  Per 
> spec, there should be no active content
> 
> provided as part of the OpenXPS format.  The consumer must ensure that 
> no malicious active content is erroneously provided in the OpenXPS 
> document.  Valid content is described
> 
> in the EMCA-388 specification 
> (http://www.ecma-international.org/publications/standards/Ecma-388.htm
> ).  Especially take note of section E.3, which describes steps that 
> can be
> 
> Applications and drivers currently producing/consuming Microsoft XPS 
> content cannot directly produce/consume OpenXPS.  Changes are required 
> to address differences in the two
> 
> (ECMA-388) instance documents.  No published applications or print 
> drivers currently use OpenXPS.  The intent is for any application or 
> driver that can currently
> 
> produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such 
> applications would include but are not limited to:  Microsoft XPS 
> Viewer, Microsoft XPS Document Writer,
> 
>  Magic number(s):  ZIP archive CRC-32: 504b 0304 per 
> http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that 
> is it a requirement of the consumer to ensure that
> 
>> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: 
>> +49(0)160/4415681 · http://www.bjoernsworld.de

---

From: Paul Libbrecht <[email-masked]>
Date: Thu, 21 Apr 2011 20:01:26 +0200

Thanks, 
fits me

paul

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 21 Apr 2011 20:27:40 +0200

>Thanks for the feedback!

You are quite welcome. This looks okay to me, except "ZIP archive
CRC-32: 504b 0304 per http://www.pkware.com/documents/..." is not
quite right. I'd replace that by something like "See `application/
zip.`; this magic number is unrelated to any CRC-32 "magic number"
and from the brief description it's not clear, say, how the bytes
are ordered; referencing application/zip instead would avoid that.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Brian Clubb <[email-masked]>
Date: Thu, 21 Apr 2011 19:53:16 +0000

Bjoern,

That makes sense.  Here is the updated template.

Thanks!
Brian

<template>

Required parameters:  N/A

Optional parameters:  N/A

Security considerations:

Published specification:

Additional information:

  Magic number(s):  see application/zip.  Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive is a valid OpenXPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  not available

Intended usage: COMMON

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 11:28 AM
To: Brian Clubb
Cc: Pete Resnick; [email-masked]
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

You are quite welcome. This looks okay to me, except "ZIP archive
CRC-32: 504b 0304 per http://www.pkware.com/documents/..." is not quite right. I'd replace that by something like "See `application/ zip.`; this magic number is unrelated to any CRC-32 "magic number"
and from the brief description it's not clear, say, how the bytes are ordered; referencing application/zip instead would avoid that.
--
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Brian Clubb <[email-masked]>
Date: Mon, 25 Apr 2011 16:09:20 +0000

Franklin,

The decision is to revert the registration back to application/oxps and discuss in committee if we wish to also register application/OpenXPS in the future as a separate registration.  I appreciate you bringing this to our attention.  

I am attaching a final revision of the template and including in the message below.

Thanks!
Brian

<template>
Type name: application/oxps
Subtype name:  Standards Tree - OpenXPS
Required parameters:  N/A
Optional parameters:  N/A
Encoding considerations:  binary

Security considerations:

Interoperability considerations:
application/oxps documents are specified by the XML schemas standardized in ECMA-388.  Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc.
To ensure interoperability, the clipboard format must be a complete OpenXPS file with .oxps extension.

Published specification:

Applications that use this media type:
The application/oxps MIME type can be used to identify CSTA XML (ECMA-388) instance documents.  No published applications or print drivers currently use OpenXPS.  The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information:

Intended usage: COMMON

-----Original Message-----
From: Brian Clubb 
Sent: Sunday, April 24, 2011 10:30 PM
To: Franklin Tse
Subject: RE: [ietf-types] Request for final approval for OpenXPS MIME type

Franklin,

Let me check with the working group and reply back.

Thanks!
Brian

Sent from my Windows Phone

-----Original Message-----
From: Franklin Tse
Sent: Sunday, April 24, 2011 9:57 PM
To: Brian Clubb
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

Dear Brian,

I noticed that Section E.1 of the current Open XML Paper Specification recommends "application/oxps" as the content type for .oxps documents, which is different from the content type you are registering. Is it the decision of the working group? Will interoperability be an issue?

Thanks,
Franklin