Subject: [ietf-types] Request for review of standards tree registration request for OpenXPS

From: Brian Clubb <[email-masked]>
Date: Wed, 12 Jan 2011 18:40:17 +0000

To whom it may concern:

Pursuant to RFC 4288 section 5.1, I am submitting the following registration template describing the OpenXPS format for community review with the goal of adding this registration to the standards tree.  The two-week comment period will conclude on  27 January 2011.

Thank you in advance for your review and consideration!

Brian Clubb
Chairman - Ecma TC46  (Ecma 388: Open XML Paper Specification)
Microsoft Corporation
[email-masked]

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.  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)

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.
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

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/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 :

1. Magic number(s) : ZIP archive CRC-32: 0xdebb20e3 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt
2. File extension(s) : .oxps
3. Macintosh file type code : N/A
4. Object Identifiers: N/A

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]

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.

---

From: Paul Libbrecht <[email-masked]>
Date: Thu, 13 Jan 2011 22:54:03 +0100

Brian,

I have four little comments of a non expert:

Le 12 janv. 2011 à 19:40, Brian Clubb a écrit :
> [...] 

should be application lower-case

> MIME subtype name : Standards Tree – OpenXPS

should be openxps, lower case.

> Encoding considerations : 8-bit

Wouldn't zip appear here?

[...]
> 4. Object Identifiers: N/A

Could I request that clipboard names be also described?
One for the Windows OS (a simple string).
One for the Macintosh OS (a Universal Type Identifer).

paul

---

From: Brian Clubb <[email-masked]>
Date: Tue, 25 Jan 2011 23:33:10 +0000

Paul,

Thanks for your feedback on my submission template!

For your feedback on changing certain responses to lower-case, I will do so in my final submission.  I appreciate your attention to detail on this matter.

For the comment on encoding, per rfc4288 section 4.8, the possible responses here are 7bit, 8bit, binary, and framed.  This response appears to be correct for ZIP archives and matches a previous registration for Microsoft's version of XPS (http://www.iana.org/assignments/media-types/application/vnd.ms-xpsdocument).  If there is some other consideration here, I am happy to make a note of it elsewhere in the template as needed.

As to the clipboard request, I checked the clipboard values on both Windows OS and Mac OS.  For Windows, the clipboard contains the full file path to the copied .oxps file as a string.  On a Mac OS (10.x), the filename plus extension is provided on the clipboard as "text / items".  Since these conventions may change over time based on the OS independent of any changes to OpenXPS, I am not certain this would be useful as part of the template.

Thanks again for your feedback!  I appreciate your time and efforts to review this!

Brian 

-----Original Message-----
From: Paul Libbrecht [mailto:[email-masked]] 
Sent: Thursday, January 13, 2011 1:54 PM
To: Brian Clubb
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS

Brian,

[...]

paul

---

From: Paul Libbrecht <[email-masked]>
Date: Wed, 26 Jan 2011 22:45:00 +0100

> For your feedback on changing certain responses to lower-case, I will do so in my final submission.  I appreciate your attention to detail on this matter.

good.

> For the comment on encoding, per rfc4288 section 4.8, the possible responses here are 7bit, 8bit, binary, and framed.  This response appears to be correct for ZIP archives and matches a previous re…

I am too little of an expert here.

> As to the clipboard request, I checked the clipboard values on both Windows OS and Mac OS.  For Windows, the clipboard contains the full file path to the copied .oxps file as a string.  On a Mac OS…

I'm afraid you misunderstood my request.
The objective was to specify within this registration names that would denote one of the alternate representations of a fragment copied to clipboard to be encoded in OpenXPS. This would allow fragments to be stored by one application in the clipboard at the copy command and to be read from the clipboard at the paste command.

Lack of specifying this in the past for MathML has lead to a multitude of names, mostly killing interoperability, with the last suggest being... put the XML in the text flavor (which is clearly wrong for, say, a mail).

(see the MathML and SVG registrations for examples)

paul

---

From: Brian Clubb <[email-masked]>
Date: Mon, 31 Jan 2011 18:33:23 +0000

Paul,

While the OpenXPS package contains XML, the document itself requires the hierarchical tree structure of pages and resources to be functional.  It is intended that only a complete OpenXPS document would ever be posted to the clipboard.  Posting a fragment of an OpenXPS file to the clipboard would not be a useful scenario in the same way that I understand it would work in MathML or SVG.  The resource tree in OpenXPS is integral to its functionality.

For example, copying the XML for a fixed page out of one file onto the clipboard would not take into account the image and font resources which are stored in other locations in the OpenXPS file.  Furthermore, re-integrating that page markup into the structure of another OpenXPS file would be extraordinarily complex.  If one were to wish to copy pages from one OpenXPS file to another, they would need to create a complete OpenXPS package containing just the required pages plus the required resources from the original OpenXPS package then post the new OpenXPS file to the clipboard.  The consuming application would then be able to access that file and its resources reliably and logically insert the pages and resources into their OpenXPS document package as needed.

If an application such as an XPS Viewer were to allow selecting and copying of the text or image elements displayed on the screen, that data would be placed on the clipboard as text or whatever image format the application chooses to provide, but posting the markup for the selection to the clipboard would not provide the relevant resource data and hierarchy and would thus be unusable as OpenXPS at that point.

I believe, then, that it is correct to say that the clipboard format would always be a complete OpenXPS file with .oxps extension.  It is the only format for the clipboard that would provide the required interoperability between OpenXPS-consuming applications.

Thanks!
Brian

-----Original Message-----
From: Paul Libbrecht [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 1:45 PM
To: Brian Clubb
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS

good.

paul

---

From: Paul Libbrecht <[email-masked]>
Date: Mon, 31 Jan 2011 21:56:19 +0100

Hello Brian, 

Le 31 janv. 2011 à 19:33, Brian Clubb a écrit :
> While the OpenXPS package contains XML, the document itself requires the hierarchical tree structure of pages and resources to be functional.  It is intended that only a complete OpenXPS document would ever be posted to the clipboard.  

Sure. Only well formed data here (and well formedness is more than XML's).

> Posting a fragment of an OpenXPS file to the clipboard would not be a useful scenario in the same way that I understand it would work in MathML or SVG.  The resource tree in OpenXPS is integral to its functionality.

But that is clear.
It doesn't remove the usefulness of such a thing.

As I said, PDF is the preferred flavor for vector graphics on MacOSX.
And rest assured that copying from a page of a 200 pages book with Apple Preview does not create a PDF with  many pages when copying a rectangle.

Earlier examples on the mac of such transfers include the PICT format and the Adobe "AIFB" (?? I think ??) format which was taken huge time to be produced when you had just copied something, say, in PhotoShop and was switching away from it (in MaOS 7-9, I suppose the same must have been done on Windows).

> For example, copying the XML for a fixed page out of one file onto the clipboard would not take into account the image and font resources which are stored in other locations in the OpenXPS file.  

That's the duty of the clipboard exporter. A normal composition programme can do that but viewers may have difficulties "at first", this is true.

In the very same fashion copying html in a browser also inlines all the styles (even coming from very far from this element) when going out to, say, an email or word-processing application (in html or rtf).

> Furthermore, re-integrating that page markup into the structure of another OpenXPS file would be extraordinarily complex.  If one were to wish to copy pages from one OpenXPS file to another, they would need to create a complete OpenXPS package containing just the required pages plus the required resources from the original OpenXPS package then post the new OpenXPS file to the clipboard.  The consuming application would then be able to access that file and its resources reliably and logically insert the pages and resources into their OpenXPS document package as needed.

I'm sure this can be and has been already done.

> If an application such as an XPS Viewer were to allow selecting and copying of the text or image elements displayed on the screen, that data would be placed on the clipboard as text or whatever image format the application chooses to provide,

right.
And one day that format might be openXPS.

> but posting the markup for the selection to the clipboard would not provide the relevant resource data and hierarchy and would thus be unusable as OpenXPS at that point.

no markup only copy.

> I believe, then, that it is correct to say that the clipboard format would always be a complete OpenXPS file with .oxps extension.  It is the only format for the clipboard that would provide the re…

I think this is correct.

paul

---

From: Paul Libbrecht <[email-masked]>
Date: Mon, 31 Jan 2011 21:57:47 +0100

Hello Brian, 

But that is clear.

right.

no markup only copy.

I think this is correct.

paul