
From: Brian Clubb <bclubb@microsoft.com>
To: Paul Libbrecht <paul@hoplahup.net>
Thread-Topic: [ietf-types] Request for review of standards tree registration request for OpenXPS
Thread-Index: AQHLs2yK9k1J+5/sU06pLsUqQi6DMZPiZR4wgAH+tQCABxnIkIAAtK+AgADaSgCAAJL8gIAVbz9Q
Date: Tue, 15 Feb 2011 18:08:40 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9171F3C0E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B90A400D@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <F59FFEBA-9E75-4C2F-A34E-BAED919CA1FF@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E1E84@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <E8E16ECE-F281-48EE-8B70-F1D2FAB85037@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E69CD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <B873B716-B10F-4374-A52D-10026EBAEDC8@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E7E66@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <6DABE6BE-2B62-4859-BC60-28F9B1B7BD28@hoplahup.net>
In-Reply-To: <6DABE6BE-2B62-4859-BC60-28F9B1B7BD28@hoplahup.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS
Precedence: list

Paul,

Thanks again for the feedback.  I am making the changes to the template.  I=
 am including, then, the final template in this reply.  If there are no oth=
er issues, then I will submit it for acceptance by the end of this week.

Thanks for all your help!  It is much appreciated!

Brian

<template>
Name : Brian Clubb

Email : bclubb@microsoft.com

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 pars=
ing 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 OpenXP=
S format.  The consumer must ensure that no malicious active content is err=
oneously provided in the OpenXPS document.  Valid content is described in t=
he EMCA-388 specification (http://www.ecma-international.org/publications/s=
tandards/Ecma-388.htm)


Also see section E.3 of ECMA-388 specification (http://www.ecma-internation=
al.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. Implem=
entations may use the following steps to identify an unknown file or stream=
 as an OpenXPS Document within an Open Packaging Conventions payload. 1. Te=
st that the file or stream is a ZIP file a. As required by =A79.2 of the Op=
en Packaging Conventions =20

b. First four bytes correspond to the local file header signature defined i=
n 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 require=
d by =A78.3.4 of the Open Packaging Conventions b. Check that the content t=
ype for the package relationships zip item is correctly defined in the Cont=
ent Types stream (see OPC =A78.1.2) as a relationships part 3. Test that th=
e Package Relationships Part contains a relationship (see OPC =A78.3) whose=
 Target attribute points to a valid FixedDocumentSequence Part a. As requir=
ed by =A710.2 of this Standard b. Check that the content type for the Fixed=
DocumentSequence part is correctly defined in the Content Types stream as a=
 FixedDocumentSequence part=20


Interoperability considerations :
application/OpenXPS documents are specified by the XML schemas
   standardized in ECMA-388.
Applications and drivers currently producing/consuming Microsoft XPS conten=
t cannot directly produce/consume OpenXPS.  Changes are required to address=
 differences in the two specifications, such as namespace, print ticket usa=
ge, 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 ca=
n currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples =
of such applications would include but are not limited to:  Microsoft XPS V=
iewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.


Additional information :

1. Magic number(s) : ZIP archive CRC-32: 0xdebb20e3 per http://www.pkware.c=
om/documents/APPNOTE/APPNOTE-6.2.0.txt
2. File extension(s) : .oxps
3. Macintosh file type code : org.ecma.oxps conforms to com.pkware.zip-arch=
ive
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.

Person & email address to contact for further information:
Ecma International Helpdesk
Rue du Rhone114
CH-1204 Geneva
Switzerland
helpdesk@ecma-international.org


Person to contact for further information :

1. Name : Ecma International Helpdesk
2. Email : helpdesk@ecma-international.org

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


-----Original Message-----
From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
Sent: Tuesday, February 01, 2011 10:45 AM
To: Brian Clubb
Cc: ietf-types@iana.org
Subject: Re: [ietf-types] Request for review of standards tree registration=
 request for OpenXPS

Brian,

my suggestion was to add something similar to the following in the Addition=
al Information section:

    Macintosh Universal Type Identifier code:
        org.ecma.xps conforms to com.pkware.zip-archive
    Windows Clipboard Name:
        "OpenXPS"

This allows putting or expecting OpenXPS in the clipboard or a drag-and-dro=
p, when this comes, to safely put and select by name.

I do not think that stating that it must be a complete OpenXPS file nor any=
thing wrt its name is useful.=20
(the first is natural, the second is not applicable since clipboards don't =
have filenames that are visible).

paul


Le 1 f=E9vr. 2011 =E0 19:27, Brian Clubb a =E9crit :

> Thanks, Paul!  I appreciate the detailed feedback!
>=20
> I propose to add the following to the "Additional Information" section of=
 the template:
>=20
> "To ensure interoperability, the clipboard format must be a complete Open=
XPS file with .oxps extension."
>=20
> Thanks!
> Brian
>=20
>=20
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
> Sent: Monday, January 31, 2011 12:58 PM
> To: Brian Clubb
> Cc: ietf-types@iana.org
> Subject: Re: [ietf-types] Request for review of standards tree registrati=
on request for OpenXPS
>=20
> Hello Brian,=20
>=20
> Le 31 janv. 2011 =E0 19:33, Brian Clubb a =E9crit :
>> While the OpenXPS package contains XML, the document itself requires the=
 hierarchical tree structure of pages and resources to be functional.  It i=
s intended that only a complete OpenXPS document would ever be posted to th=
e clipboard. =20
>=20
> Sure. Only well formed data here (and well formedness is more than XML's)=
.
>=20
>> Posting a fragment of an OpenXPS file to the clipboard would not be a us=
eful 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.
>=20
> But that is clear.
> It doesn't remove the usefulness of such a thing.
>=20
> 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.
>=20
> 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 pr=
oduced when you had just copied something, say, in PhotoShop and was switch=
ing away from it (in MaOS 7-9, I suppose the same must have been done on Wi=
ndows).
>=20
>> For example, copying the XML for a fixed page out of one file onto the c=
lipboard would not take into account the image and font resources which are=
 stored in other locations in the OpenXPS file. =20
>=20
> 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.
>=20
> In the very same fashion copying html in a browser also inlines all the s=
tyles (even coming from very far from this element) when going out to, say,=
 an email or word-processing application (in html or rtf).
>=20
>> Furthermore, re-integrating that page markup into the structure of anoth=
er OpenXPS file would be extraordinarily complex.  If one were to wish to c=
opy pages from one OpenXPS file to another, they would need to create a com=
plete 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 t=
hat file and its resources reliably and logically insert the pages and reso=
urces into their OpenXPS document package as needed.
>=20
> I'm sure this can be and has been already done.
>=20
>> If an application such as an XPS Viewer were to allow selecting and copy=
ing 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,
>=20
> right.
> And one day that format might be openXPS.
>=20
>> but posting the markup for the selection to the clipboard would not prov=
ide the relevant resource data and hierarchy and would thus be unusable as =
OpenXPS at that point.
>=20
> no markup only copy.
>=20
>> I believe, then, that it is correct to say that the clipboard format wou=
ld always be a complete OpenXPS file with .oxps extension.  It is the only =
format for the clipboard that would provide the required interoperability b=
etween OpenXPS-consuming applications.
>=20
> I think this is correct.
>=20
> paul


Return-Path: <derhoermi@gmx.net>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876DD3A6405 for <ietf-types@core3.amsl.com>; Wed,  2 Feb 2011 16:45:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.213
X-Spam-Level: 
X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXRMp5li71W8 for <ietf-types@core3.amsl.com>; Wed,  2 Feb 2011 16:45:42 -0800 (PST)
Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by core3.amsl.com (Postfix) with ESMTP id EC5DB3A6359 for <ietf-types@ietf.org>; Wed,  2 Feb 2011 16:45:41 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora2.lax.icann.org (8.13.8/8.13.8) with SMTP id p130meS1021373 for <ietf-types@iana.org>; Wed, 2 Feb 2011 16:49:01 -0800
Received: (qmail invoked by alias); 03 Feb 2011 00:21:58 -0000
Received: from dslb-094-223-191-191.pools.arcor-ip.net (EHLO hive) [94.223.191.191] by mail.gmx.net (mp040) with SMTP; 03 Feb 2011 01:21:58 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/k2zopvWPkT4vB/PNggaFFvQL6ODd5dfCOQaL7U1 LlEbcnIXn4H5Xf
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: MURATA Makoto <murata@hokkaido.email.ne.jp>
Date: Thu, 03 Feb 2011 01:21:56 +0100
Message-ID: <krsjk6t0d1bnu2ks1rf88fqbnen88rhf3l@hive.bjoern.hoehrmann.de>
References: <010d01c7d9d4$b4f09bb0$6401a8c0@NICKDESK> <20110203084317.FA8D.576FBF33@hokkaido.email.ne.jp>
In-Reply-To: <20110203084317.FA8D.576FBF33@hokkaido.email.ne.jp>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Greylist: Delayed for 00:26:40 by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Wed, 02 Feb 2011 16:49:01 -0800 (PST)
Cc: ietf-types@iana.org, Nick Bogaty <nbogaty@idpf.org>, 'John Rivlin' <john@eBookTechnologies.com>, 'Ric Wright' <riwright@adobe.com>, 'Garth Conboy' <gc@eBookTechnologies.com>
Subject: Re: [ietf-types] Mime Type Reg for "application/epub+zip"
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2011 00:45:43 -0000

* MURATA Makoto wrote:
>For EPUB to be a good citizen of Internet, I think that registration 
>of application/epub+zip is a necessary step.  I am wondering how we 
>should go forward.  Here are some possibilities I can think of.
>
>1) Create an IDPF EPUB3 spec,  describe everything about this media 
>type (including possible frag. identifiers), and request for the
>approval of IESG.
>
>2) Create an ISO or IEC or JTC1 EPUB specification (possible EPUB2),
>describe everything there, and request for the approval of IESG.
>
>3) Begin with an I-D and describe everything there and try to reach 
> (proposed standard?) RFC status, and register the media type.

Well, as far as ietf-types review is concerned, if a type is actually
used, then it should be registered, the registration should not clash
with conflicting usage (like, if the type in question is also used for
something else) and the registration information should meet the re-
quirements of RFC 4288 and dependencies. From that perspective, the
options above seem relatively equal. Your third option seems to have
the best chances to produce results quickly though.
-- 
Bj�rn H�hrmann � mailto:bjoern@hoehrmann.de � 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/ 


Return-Path: <murata@hokkaido.email.ne.jp>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEB23A6CA1 for <ietf-types@core3.amsl.com>; Wed,  2 Feb 2011 15:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miu-J7dczE3s for <ietf-types@core3.amsl.com>; Wed,  2 Feb 2011 15:59:04 -0800 (PST)
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by core3.amsl.com (Postfix) with ESMTP id 847F53A6C91 for <ietf-types@ietf.org>; Wed,  2 Feb 2011 15:59:03 -0800 (PST)
Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p1301kSf024715 for <ietf-types@iana.org>; Wed, 2 Feb 2011 19:02:08 -0500
Received: from [192.168.1.3] (y240121.dynamic.ppp.asahi-net.or.jp [118.243.240.121]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 2160DC5D3B; Thu,  3 Feb 2011 08:43:17 +0900 (JST)
Date: Thu, 03 Feb 2011 08:43:22 +0900
From: MURATA Makoto <murata@hokkaido.email.ne.jp>
To: <ietf-types@iana.org>
In-Reply-To: <010d01c7d9d4$b4f09bb0$6401a8c0@NICKDESK>
References: <010d01c7d9d4$b4f09bb0$6401a8c0@NICKDESK>
Message-Id: <20110203084317.FA8D.576FBF33@hokkaido.email.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.56.04 [ja]
X-Greylist: Delayed for 00:18:25 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Wed, 02 Feb 2011 19:02:09 -0500 (EST)
Cc: 'Ric Wright' <riwright@adobe.com>, Nick Bogaty <nbogaty@idpf.org>, 'John Rivlin' <john@eBookTechnologies.com>, 'Garth Conboy' <gc@eBookTechnologies.com>
Subject: Re: [ietf-types] Mime Type Reg for "application/epub+zip"
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2011 23:59:05 -0000

Dear colleagues,

In 2007, IDPF (http://www.idpf.org/) submitted a request to register a
standard-tree media type "application/epub+zip" for EPUB documents. 
There were no discussions or registrations, however.  The I-D 
at that time, namely http://www.idpf.org/draft-idpf-mime-ocf-01.txt, has
already expired.

Since then, things have changed.  EPUB has become a very important 
e-book format, and is very widely used by Apple, Adobe, Sony, Barns & Noble, 
among others.  EPUB implementations appear to use "application/epub+zip".
The IDPF EPUB WG is actively designing the next version of EPUB, namely
EPUB3, and has committed to finish it in May, 2011.

Standardization of EPUB at ISO, IEC, or JTC1 is also being discussed 
at ISO/IEC JTC1/SC34/AHG4 (EPUB).    IDPF is involved.

Moreover, the EPUB WG of IDPF is currently talking about introducing
fragment identifiers for EPUB3.   A proposal is available at
http://code.google.com/p/epub-revision/wiki/ImplementationProposalFragmentIdentifier

For EPUB to be a good citizen of Internet, I think that registration 
of application/epub+zip is a necessary step.  I am wondering how we 
should go forward.  Here are some possibilities I can think of.

1) Create an IDPF EPUB3 spec,  describe everything about this media 
type (including possible frag. identifiers), and request for the
approval of IESG.

2) Create an ISO or IEC or JTC1 EPUB specification (possible EPUB2),
describe everything there, and request for the approval of IESG.

3) Begin with an I-D and describe everything there and try to reach 
 (proposed standard?) RFC status, and register the media type.

How do people feel?

Cheers,
-- 
MURATA Makoto <murata@hokkaido.email.ne.jp>


Return-Path: <paul@hoplahup.net>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFEA3A6C41 for <ietf-types@core3.amsl.com>; Tue,  1 Feb 2011 10:42:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSm+OHTRlIgC for <ietf-types@core3.amsl.com>; Tue,  1 Feb 2011 10:42:36 -0800 (PST)
Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by core3.amsl.com (Postfix) with ESMTP id D1FCA3A6D8D for <ietf-types@ietf.org>; Tue,  1 Feb 2011 10:42:35 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id p11IjGAY026587 for <ietf-types@iana.org>; Tue, 1 Feb 2011 13:45:36 -0500
Received: from ip-109-84-255-173.web.vodafone.de (ip-109-84-255-173.web.vodafone.de [109.84.255.173]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LnDWH-1QNEsH38ZR-00hvPH; Tue, 01 Feb 2011 19:45:14 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=iso-8859-1
From: Paul Libbrecht <paul@hoplahup.net>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9171E7E66@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Date: Tue, 1 Feb 2011 19:45:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DABE6BE-2B62-4859-BC60-28F9B1B7BD28@hoplahup.net>
References: <FE6603D65048F44AB8F8955AE89A09B90A400D@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <F59FFEBA-9E75-4C2F-A34E-BAED919CA1FF@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E1E84@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <E8E16ECE-F281-48EE-8B70-F1D2FAB85037@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E69CD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <B873B716-B10F-4374-A52D-10026EBAEDC8@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E7E66@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
To: Brian Clubb <bclubb@microsoft.com>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:eFtutV0ujrPX8uZhdDcHAChAmK1zkbZTVJe3NWPA8Yg rjEJwhA8SwF3ckIclm3qJ+YVPj8emqkcn3uvTGDdiCwOezjuqB dCjv2u1I1i8UVV19BmiHGCcjacLW4Wkkn2MYpUuGXB7D+ZWvId riM3L8GYQn8tfSSc08FYNdnuDNBP7p0Rgl1vQRrXKIcMamDaGp 3UmexGbOp583mnz4JwR2oqgmPziMYHq4sDIBWn9zrw=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Tue, 01 Feb 2011 13:45:36 -0500 (EST)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 18:42:37 -0000

Brian,

my suggestion was to add something similar to the following in the =
Additional Information section:

    Macintosh Universal Type Identifier code:
        org.ecma.xps conforms to com.pkware.zip-archive
    Windows Clipboard Name:
        "OpenXPS"

This allows putting or expecting OpenXPS in the clipboard or a =
drag-and-drop, when this comes, to safely put and select by name.

I do not think that stating that it must be a complete OpenXPS file nor =
anything wrt its name is useful.=20
(the first is natural, the second is not applicable since clipboards =
don't have filenames that are visible).

paul


Le 1 f=E9vr. 2011 =E0 19:27, Brian Clubb a =E9crit :

> Thanks, Paul!  I appreciate the detailed feedback!
>=20
> I propose to add the following to the "Additional Information" section =
of the template:
>=20
> "To ensure interoperability, the clipboard format must be a complete =
OpenXPS file with .oxps extension."
>=20
> Thanks!
> Brian
>=20
>=20
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
> Sent: Monday, January 31, 2011 12:58 PM
> To: Brian Clubb
> Cc: ietf-types@iana.org
> Subject: Re: [ietf-types] Request for review of standards tree =
registration request for OpenXPS
>=20
> Hello Brian,=20
>=20
> Le 31 janv. 2011 =E0 19:33, Brian Clubb a =E9crit :
>> 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. =20
>=20
> Sure. Only well formed data here (and well formedness is more than =
XML's).
>=20
>> 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.
>=20
> But that is clear.
> It doesn't remove the usefulness of such a thing.
>=20
> 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.
>=20
> 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).
>=20
>> 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. =20
>=20
> 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.
>=20
> 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).
>=20
>> 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.
>=20
> I'm sure this can be and has been already done.
>=20
>> 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,
>=20
> right.
> And one day that format might be openXPS.
>=20
>> 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.
>=20
> no markup only copy.
>=20
>> 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.
>=20
> I think this is correct.
>=20
> paul


Return-Path: <bclubb@microsoft.com>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CD23A6FD4 for <ietf-types@core3.amsl.com>; Tue,  1 Feb 2011 10:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.921
X-Spam-Level: 
X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.678,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmVDZ-DMLxJ4 for <ietf-types@core3.amsl.com>; Tue,  1 Feb 2011 10:24:45 -0800 (PST)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 7F2FF3A6FB3 for <ietf-types@ietf.org>; Tue,  1 Feb 2011 10:24:44 -0800 (PST)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p11IRfYA025119 for <ietf-types@iana.org>; Tue, 1 Feb 2011 10:28:01 -0800
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Feb 2011 10:27:39 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 1 Feb 2011 10:27:39 -0800
Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.252]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 1 Feb 2011 10:27:39 -0800
From: Brian Clubb <bclubb@microsoft.com>
To: Paul Libbrecht <paul@hoplahup.net>
Thread-Topic: [ietf-types] Request for review of standards tree registration request for OpenXPS
Thread-Index: AQHLs2yK9k1J+5/sU06pLsUqQi6DMZPiZR4wgAH+tQCABxnIkIAAtK+AgADaSgA=
Date: Tue, 1 Feb 2011 18:27:38 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9171E7E66@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B90A400D@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <F59FFEBA-9E75-4C2F-A34E-BAED919CA1FF@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E1E84@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <E8E16ECE-F281-48EE-8B70-F1D2FAB85037@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9171E69CD@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <B873B716-B10F-4374-A52D-10026EBAEDC8@hoplahup.net>
In-Reply-To: <B873B716-B10F-4374-A52D-10026EBAEDC8@hoplahup.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [208.77.188.39]); Tue, 01 Feb 2011 10:28:01 -0800 (PST)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 18:24:46 -0000

Thanks, Paul!  I appreciate the detailed feedback!

I propose to add the following to the "Additional Information" section of t=
he template:

"To ensure interoperability, the clipboard format must be a complete OpenXP=
S file with .oxps extension."

Thanks!
Brian


-----Original Message-----
From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
Sent: Monday, January 31, 2011 12:58 PM
To: Brian Clubb
Cc: ietf-types@iana.org
Subject: Re: [ietf-types] Request for review of standards tree registration=
 request for OpenXPS

Hello Brian,=20

Le 31 janv. 2011 =E0 19:33, Brian Clubb a =E9crit :
> 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. =20

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 use=
ful scenario in the same way that I understand it would work in MathML or S=
VG.  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 Pr=
eview 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 t=
he Adobe "AIFB" (?? I think ??) format which was taken huge time to be prod=
uced when you had just copied something, say, in PhotoShop and was switchin=
g away from it (in MaOS 7-9, I suppose the same must have been done on Wind=
ows).

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

That's the duty of the clipboard exporter. A normal composition programme c=
an 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 sty=
les (even coming from very far from this element) when going out to, say, a=
n email or word-processing application (in html or rtf).

> Furthermore, re-integrating that page markup into the structure of anothe=
r OpenXPS file would be extraordinarily complex.  If one were to wish to co=
py pages from one OpenXPS file to another, they would need to create a comp=
lete OpenXPS package containing just the required pages plus the required r=
esources from the original OpenXPS package then post the new OpenXPS file t=
o the clipboard.  The consuming application would then be able to access th=
at file and its resources reliably and logically insert the pages and resou=
rces 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 copyi=
ng of the text or image elements displayed on the screen, that data would b=
e 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 provi=
de the relevant resource data and hierarchy and would thus be unusable as O=
penXPS at that point.

no markup only copy.

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

I think this is correct.

paul