Return-Path: <Even.roni@huawei.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B377E062A for <ietf-types@ietfa.amsl.com>; Thu, 28 Apr 2011 01:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.607
X-Spam-Level: 
X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXFuJiaYR3f8 for <ietf-types@ietfa.amsl.com>; Thu, 28 Apr 2011 01:51:41 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5BE06CC for <ietf-types@ietf.org>; Thu, 28 Apr 2011 01:51:41 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3S8p6G9015653 for <ietf-types@iana.org>; Thu, 28 Apr 2011 01:51:26 -0700
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC008S9T06V2@szxga05-in.huawei.com> for ietf-types@iana.org; Thu, 28 Apr 2011 16:31:18 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKC000K5T05J6@szxga05-in.huawei.com> for ietf-types@iana.org; Thu, 28 Apr 2011 16:31:18 +0800 (CST)
Received: from windows8d787f9 (bzq-109-64-7-230.red.bezeqint.net [109.64.7.230]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LKC00E7ASZZHK@szxml12-in.huawei.com>; Thu, 28 Apr 2011 16:31:17 +0800 (CST)
Date: Thu, 28 Apr 2011 11:30:11 +0300
From: Roni Even <Even.roni@huawei.com>
To: ietf-types@iana.org
Message-id: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1ShHKE41PqhVUDULtvvRkQ)"
Content-language: en-us
Thread-index: AcwFfnxjlHJkjafvSnuGYHRK//xRTg==
X-Greylist: Delayed for 00:18:53 by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 28 Apr 2011 01:51:26 -0700 (PDT)
Cc: "'Ali C. Begen \(abegen\)'" <abegen@cisco.com>, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org
Subject: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Apr 2011 08:51:42 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_1ShHKE41PqhVUDULtvvRkQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

 

Hi,

 

draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT
Working Group (currently Payload). The document updates the media subtypes
"MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in
Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair

 


--Boundary_(ID_1ShHKE41PqhVUDULtvvRkQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Hi,<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes &quot;MP4A-LATM&quot; and &quot;MP4V-ES&quot;&nbsp; from RFC 3016.&nbsp; The new registrations are in Section 6.1 and&nbsp;&nbsp; Section 6.3 of the document.<o:p></o:p></p><p class=MsoNormal>Comments on the registration are welcome.<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Thanks<o:p></o:p></p><p class=MsoNormal>Roni Even<o:p></o:p></p><p class=MsoNormal>Payload WG co-chair<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>

--Boundary_(ID_1ShHKE41PqhVUDULtvvRkQ)--

Return-Path: <presnick@qualcomm.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47B92E06CC for <ietf-types@ietfc.amsl.com>; Mon, 25 Apr 2011 09:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.467
X-Spam-Level: 
X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFRbi6UN4n75 for <ietf-types@ietfc.amsl.com>; Mon, 25 Apr 2011 09:43:58 -0700 (PDT)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfc.amsl.com (Postfix) with ESMTP id EF4EDE06A9 for <ietf-types@ietf.org>; Mon, 25 Apr 2011 09:43:57 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3PGhals020392 for <ietf-types@iana.org>; Mon, 25 Apr 2011 09:43:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1303749837; x=1335285837; h=message-id:date:from:user-agent:mime-version:to:cc: subject:content-type:x-originating-ip; z=Message-ID:=20<4DB5A49A.8020901@qualcomm.com>|Date:=20Mo n,=2025=20Apr=202011=2011:43:06=20-0500|From:=20Pete=20Re snick=20<presnick@qualcomm.com>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"ietf-types@iana.org"=20<ietf- types@iana.org>|CC:=20Brian=20Clubb=20<Brian.Clubb@micros oft.com>|Subject:=20Registration=20of=20application/oxps =20MIME=20type=20(Was:=20Request=20for=20final=0D=0A=20ap proval=20for=20OpenXPS=20MIME=20type)|Content-Type:=20mul tipart/mixed=3B=0D=0A=09boundary=3D"------------050303010 803010008000307"|X-Originating-IP:=20[172.30.48.1]; bh=1z4/SsMMVTAD2c3q1jPpzH6xKjkLdykDqT0VpIVWhcM=; b=kQaJQS7QpYgeoglF3TbyrVmLPGk6Y5BdJezt+zh49UyIE7oNfIo1rXYt 7IcbNieqDEEsDncdBRg10qkShUu4Iy1/YC92SzmjausfUdak3v8wlZL9f nm8imkMWUYTAVysXwezJY3F7UGseIKMATyNpFUkqgT3B8cLT2iwHJxAbs w=;
X-IronPort-AV: E=McAfee;i="5400,1158,6327"; a="87508137"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 25 Apr 2011 09:43:35 -0700
X-IronPort-AV: E=Sophos;i="4.64,265,1301900400";  d="txt'?scan'208";a="137089750"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Apr 2011 09:43:21 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 25 Apr 2011 09:43:09 -0700
Message-ID: <4DB5A49A.8020901@qualcomm.com>
Date: Mon, 25 Apr 2011 11:43:06 -0500
From: Pete Resnick <presnick@qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "ietf-types@iana.org" <ietf-types@iana.org>
Content-Type: multipart/mixed; boundary="------------050303010803010008000307"
X-Originating-IP: [172.30.48.1]
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 25 Apr 2011 09:43:57 -0700 (PDT)
Cc: Brian Clubb <Brian.Clubb@microsoft.com>
Subject: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type)
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 25 Apr 2011 16:43:59 -0000

--------------050303010803010008000307
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I am re-posting this with a new thread because I would like to get some 
confirmation from the list that this is OK. I suspect it is, but I'm 
going to postpone bringing before the IESG until the May 12 telechat to 
give the list some time to review.

The proposal is to register application/oxps instead of 
application/OpenXPS to better align with the Open XML Paper Specification.

pr

-------- Original Message --------
Subject:     Re: [ietf-types] Request for final approval for OpenXPS 
MIME type
Date:     Mon, 25 Apr 2011 16:09:20 +0000
From:     Brian Clubb <Brian.Clubb@microsoft.com>
To:     Franklin Tse <peaceable_whale@hotmail.com>, Pete Resnick 
<presnick@qualcomm.com>
CC:     'ietf-types@iana.org' <ietf-types@iana.org>



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

   Windows Clipboard Name: "OpenXPS"
   Macintosh Uniform Type Identifier: org.ecma.oxps conforms to 
com.pkware.zip-archive

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

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


--------------050303010803010008000307
Content-Type: text/plain; name="MIMEReg.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="MIMEReg.txt"

Type name: application/oxps

Subtype name:  Standards Tree – OpenXPS

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary

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

  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):  not available
	
  Windows Clipboard Name: "OpenXPS"
  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.zip-archive

Person & email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

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.

--------------050303010803010008000307--


Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CDE3E075C for <ietf-types@ietfc.amsl.com>; Mon, 25 Apr 2011 09:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.699
X-Spam-Level: 
X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[AWL=2.900,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyM89FiN9Kxh for <ietf-types@ietfc.amsl.com>; Mon, 25 Apr 2011 09:09:43 -0700 (PDT)
Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by ietfc.amsl.com (Postfix) with ESMTP id 68664E06C7 for <ietf-types@ietf.org>; Mon, 25 Apr 2011 09:09:43 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3PG9Mfw008468 for <ietf-types@iana.org>; Mon, 25 Apr 2011 09:09:42 -0700
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Apr 2011 09:09:21 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 25 Apr 2011 09:09:21 -0700
Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.83]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Mon, 25 Apr 2011 09:09:21 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Franklin Tse <peaceable_whale@hotmail.com>, Pete Resnick <presnick@qualcomm.com>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAuzKiAAAN+U7w//+bEQD//W5rEIAFxbIAgABeFXCABQkBgP//k5rH//9PR5A=
Date: Mon, 25 Apr 2011 16:09:20 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B91730D8EE@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
References: <4DA87DD4.7070105@qualcomm.com><FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com><4DADBE0A.80309@qualcomm.com><FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com><7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de><FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com><r4t0r61sqiiqkfsc4blq4t469vlslsmn2i@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FD14E@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>, <COL122-DS11B07F03A16799A83D3059F960@phx.gbl> <FE6603D65048F44AB8F8955AE89A09B9173087F0@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9173087F0@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/mixed; boundary="_002_FE6603D65048F44AB8F8955AE89A09B91730D8EETK5EX14MBXW652w_"
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Mon, 25 Apr 2011 09:09:42 -0700 (PDT)
Cc: "'ietf-types@iana.org'" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 25 Apr 2011 16:09:45 -0000

--_002_FE6603D65048F44AB8F8955AE89A09B91730D8EETK5EX14MBXW652w_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Franklin,

The decision is to revert the registration back to application/oxps and dis=
cuss in committee if we wish to also register application/OpenXPS in the fu=
ture as a separate registration.  I appreciate you bringing this to our att=
ention. =20

I am attaching a final revision of the template and including in the messag=
e 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:
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.  The consumer is responsible=
 for validating the .zip archive, the XML structure, and the resource conte=
nt.  Per spec, there should be no active content provided as part of the Op=
enXPS 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/publicatio=
ns/standards/Ecma-388.htm).  Especially take note of section E.3, which des=
cribes steps that can be taken to validate the contents of the payload.

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

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/oxps MIME type can be used to identify CSTA XML (ECMA-388) =
instance documents.  No published applications or print drivers currently u=
se OpenXPS.  The intent is for any application or driver that can currently=
 produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such app=
lications would include but are not limited to:  Microsoft XPS Viewer, Micr=
osoft XPS Document Writer, Microsoft Internet Explorer 9.

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 Open=
XPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  not available
=09
  Windows Clipboard Name: "OpenXPS"
  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.z=
ip-archive

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

Intended usage: COMMON

Restrictions on usage:  N/A

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

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

-----Original Message-----
From: Brian Clubb=20
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 reco=
mmends "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

--_002_FE6603D65048F44AB8F8955AE89A09B91730D8EETK5EX14MBXW652w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=2993;
	creation-date="Wed, 20 Apr 2011 16:58:49 GMT";
	modification-date="Mon, 25 Apr 2011 16:02:01 GMT"
Content-Transfer-Encoding: base64

VHlwZSBuYW1lOiBhcHBsaWNhdGlvbi9veHBzDQoNClN1YnR5cGUgbmFtZTogIFN0YW5kYXJkcyBU
cmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzOiAgTi9BDQoNCk9wdGlvbmFsIHBh
cmFtZXRlcnM6ICBOL0ENCg0KRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6ICBiaW5hcnkNCg0KU2Vj
dXJpdHkgY29uc2lkZXJhdGlvbnM6DQpPcGVuWFBTIHVzZXMgWklQIGNvbXByZXNzaW9uIGFzIHNw
ZWNpZmllZCBpbiAuWklQIEZpbGUgRm9ybWF0IFNwZWNpZmljYXRpb24gZnJvbSBQS1dBUkUsIElu
Yy4sIHZlcnNpb24gNi4yLjAgKDIwMDQpLiAgWklQIGNvbXByZXNzZWQgWE1MIHJlcXVpcmVzIHBh
cnNpbmcgdW50cnVzdGVkIFhNTCBkYXRhIGFuZCB1bnRydXN0ZWQgWklQIGRhdGEuICBUaGUgY29u
c3VtZXIgaXMgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhlIC56aXAgYXJjaGl2ZSwgdGhl
IFhNTCBzdHJ1Y3R1cmUsIGFuZCB0aGUgcmVzb3VyY2UgY29udGVudC4gIFBlciBzcGVjLCB0aGVy
ZSBzaG91bGQgYmUgbm8gYWN0aXZlIGNvbnRlbnQgcHJvdmlkZWQgYXMgcGFydCBvZiB0aGUgT3Bl
blhQUyBmb3JtYXQuICBUaGUgY29uc3VtZXIgbXVzdCBlbnN1cmUgdGhhdCBubyBtYWxpY2lvdXMg
YWN0aXZlIGNvbnRlbnQgaXMgZXJyb25lb3VzbHkgcHJvdmlkZWQgaW4gdGhlIE9wZW5YUFMgZG9j
dW1lbnQuICBWYWxpZCBjb250ZW50IGlzIGRlc2NyaWJlZCBpbiB0aGUgRU1DQS0zODggc3BlY2lm
aWNhdGlvbiAoaHR0cDovL3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL3B1YmxpY2F0aW9ucy9z
dGFuZGFyZHMvRWNtYS0zODguaHRtKS4gIEVzcGVjaWFsbHkgdGFrZSBub3RlIG9mIHNlY3Rpb24g
RS4zLCB3aGljaCBkZXNjcmliZXMgc3RlcHMgdGhhdCBjYW4gYmUgdGFrZW4gdG8gdmFsaWRhdGUg
dGhlIGNvbnRlbnRzIG9mIHRoZSBwYXlsb2FkLg0KDQoNCkludGVyb3BlcmFiaWxpdHkgY29uc2lk
ZXJhdGlvbnM6DQphcHBsaWNhdGlvbi9veHBzIGRvY3VtZW50cyBhcmUgc3BlY2lmaWVkIGJ5IHRo
ZSBYTUwgc2NoZW1hcyBzdGFuZGFyZGl6ZWQgaW4gRUNNQS0zODguDQpBcHBsaWNhdGlvbnMgYW5k
IGRyaXZlcnMgY3VycmVudGx5IHByb2R1Y2luZy9jb25zdW1pbmcgTWljcm9zb2Z0IFhQUyBjb250
ZW50IGNhbm5vdCBkaXJlY3RseSBwcm9kdWNlL2NvbnN1bWUgT3BlblhQUy4gIENoYW5nZXMgYXJl
IHJlcXVpcmVkIHRvIGFkZHJlc3MgZGlmZmVyZW5jZXMgaW4gdGhlIHR3byBzcGVjaWZpY2F0aW9u
cywgc3VjaCBhcyBuYW1lc3BhY2UsIHByaW50IHRpY2tldCB1c2FnZSwgdXNlIG9mIEpQRUcgWFIs
IGV0Yy4NCg0KVG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHksIHRoZSBjbGlwYm9hcmQgZm9ybWF0
IG11c3QgYmUgYSBjb21wbGV0ZSBPcGVuWFBTIGZpbGUgd2l0aCAub3hwcyBleHRlbnNpb24uDQoN
ClB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOg0KVGhlIHB1Ymxpc2hlZCBzdGFuZGFyZCBFQ01BLTM4
OCBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5vcmcvcHVi
bGljYXRpb25zL3N0YW5kYXJkcy9FY21hLTM4OC5odG0NCg0KQXBwbGljYXRpb25zIHRoYXQgdXNl
IHRoaXMgbWVkaWEgdHlwZToNClRoZSBhcHBsaWNhdGlvbi9veHBzIE1JTUUgdHlwZSBjYW4gYmUg
dXNlZCB0byBpZGVudGlmeSBDU1RBIFhNTA0KKEVDTUEtMzg4KSBpbnN0YW5jZSBkb2N1bWVudHMu
ICBObyBwdWJsaXNoZWQgYXBwbGljYXRpb25zIG9yIHByaW50IGRyaXZlcnMgY3VycmVudGx5IHVz
ZSBPcGVuWFBTLiAgVGhlIGludGVudCBpcyBmb3IgYW55IGFwcGxpY2F0aW9uIG9yIGRyaXZlciB0
aGF0IGNhbiBjdXJyZW50bHkgcHJvZHVjZS9jb25zdW1lIE1pY3Jvc29mdCBYUFMgdG8gYWxzbyBh
ZG9wdCBPcGVuWFBTLiAgRXhhbXBsZXMgb2Ygc3VjaCBhcHBsaWNhdGlvbnMgd291bGQgaW5jbHVk
ZSBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOiAgTWljcm9zb2Z0IFhQUyBWaWV3ZXIsIE1pY3Jvc29m
dCBYUFMgRG9jdW1lbnQgV3JpdGVyLCBNaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9yZXIgOS4NCg0K
QWRkaXRpb25hbCBpbmZvcm1hdGlvbjoNCg0KICBNYWdpYyBudW1iZXIocyk6ICBaSVAgYXJjaGl2
ZSBDUkMtMzI6IDUwNGIgMDMwNCBwZXIgaHR0cDovL3d3dy5wa3dhcmUuY29tL2RvY3VtZW50cy9B
UFBOT1RFL0FQUE5PVEUtNi4yLjAudHh0LiAgTm90ZSB0aGF0IGlzIGl0IGEgcmVxdWlyZW1lbnQg
b2YgdGhlIGNvbnN1bWVyIHRvIGVuc3VyZSB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUgWklQIGFy
Y2hpdmUgaXMgYSB2YWxpZCBPcGVuWFBTIHN0cnVjdHVyZS4NCiAgRmlsZSBleHRlbnNpb24ocyk6
IC5veHBzDQogIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZShzKTogIG5vdCBhdmFpbGFibGUNCgkN
CiAgV2luZG93cyBDbGlwYm9hcmQgTmFtZTogIk9wZW5YUFMiDQogIE1hY2ludG9zaCBVbmlmb3Jt
IFR5cGUgSWRlbnRpZmllcjogb3JnLmVjbWEub3hwcyBjb25mb3JtcyB0byBjb20ucGt3YXJlLnpp
cC1hcmNoaXZlDQoNClBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhl
ciBpbmZvcm1hdGlvbjoNCg0KRWNtYSBJbnRlcm5hdGlvbmFsIEhlbHBkZXNrDQpSdWUgZHUgUmhv
bmUgMTE0DQpDSC0xMjA0IEdlbmV2YQ0KU3dpdHplcmxhbmQNCkVjbWEgSW50ZXJuYXRpb25hbCBI
ZWxwZGVzazxoZWxwZGVza0BlY21hLWludGVybmF0aW9uYWwub3JnPg0KDQpJbnRlbmRlZCB1c2Fn
ZTogQ09NTU9ODQoNCg0KUmVzdHJpY3Rpb25zIG9uIHVzYWdlOiAgTi9BDQoNCg0KQXV0aG9yOiAg
VGhlIEVDTUEtMzg4IFN0YW5kYXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBieSB0aGUg
RWNtYSBUZWNobmljYWwgQ29tbWl0dGVlIFRDNDYuDQoNCkNoYW5nZSBjb250cm9sbGVyOiAgVGhl
IEVDTUEtMzg4IFN0YW5kYXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgRWNt
YSBUZWNobmljYWwgQ29tbWl0dGVlIFRDNDYuDQo=

--_002_FE6603D65048F44AB8F8955AE89A09B91730D8EETK5EX14MBXW652w_--


Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B7374E07A4 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 12:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.882
X-Spam-Level: 
X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyeFXBB7IqYb for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 12:53:55 -0700 (PDT)
Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfc.amsl.com (Postfix) with ESMTP id 1B89AE06A7 for <ietf-types@ietf.org>; Thu, 21 Apr 2011 12:53:54 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3LJrImi000474 for <ietf-types@iana.org>; Thu, 21 Apr 2011 12:53:38 -0700
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 12:53:17 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 12:53:17 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Thu, 21 Apr 2011 12:53:17 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAuzKiAAAN+U7w//+bEQD//W5rEIAFxbIAgABeFXA=
Date: Thu, 21 Apr 2011 19:53:16 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172FD14E@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <r4t0r61sqiiqkfsc4blq4t469vlslsmn2i@hive.bjoern.hoehrmann.de>
In-Reply-To: <r4t0r61sqiiqkfsc4blq4t469vlslsmn2i@hive.bjoern.hoehrmann.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.30]
Content-Type: multipart/mixed; boundary="_002_FE6603D65048F44AB8F8955AE89A09B9172FD14ETK5EX14MBXW651w_"
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Thu, 21 Apr 2011 12:53:39 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 19:53:56 -0000

--_002_FE6603D65048F44AB8F8955AE89A09B9172FD14ETK5EX14MBXW651w_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bjoern,

That makes sense.  Here is the updated template.

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:
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.  The consumer is responsible=
 for validating the .zip archive, the XML structure, and the resource conte=
nt.  Per spec, there should be no active content provided as part of the Op=
enXPS 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/publicatio=
ns/standards/Ecma-388.htm).  Especially take note of section E.3, which des=
cribes 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 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.

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

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

  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 Open=
XPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  not available
=09
  Windows Clipboard Name: "OpenXPS"
  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.z=
ip-archive

Person & email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

Intended usage: COMMON


Restrictions on usage:  N/A


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

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

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]=20
Sent: Thursday, April 21, 2011 11:28 AM
To: Brian Clubb
Cc: Pete Resnick; ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

* Brian Clubb wrote:
>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 rig=
ht. 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 order=
ed; referencing application/zip instead would avoid that.
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma=
nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsw=
orld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20


--_002_FE6603D65048F44AB8F8955AE89A09B9172FD14ETK5EX14MBXW651w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=2930;
	creation-date="Tue, 19 Apr 2011 18:06:28 GMT";
	modification-date="Thu, 21 Apr 2011 19:50:21 GMT"
Content-Transfer-Encoding: base64

VHlwZSBuYW1lOiBhcHBsaWNhdGlvbi9PcGVuWFBTDQoNClN1YnR5cGUgbmFtZTogIFN0YW5kYXJk
cyBUcmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzOiAgTi9BDQoNCk9wdGlvbmFs
IHBhcmFtZXRlcnM6ICBOL0ENCg0KRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6ICBiaW5hcnkNCg0K
U2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQpPcGVuWFBTIHVzZXMgWklQIGNvbXByZXNzaW9uIGFz
IHNwZWNpZmllZCBpbiAuWklQIEZpbGUgRm9ybWF0IFNwZWNpZmljYXRpb24gZnJvbSBQS1dBUkUs
IEluYy4sIHZlcnNpb24gNi4yLjAgKDIwMDQpLiAgWklQIGNvbXByZXNzZWQgWE1MIHJlcXVpcmVz
IHBhcnNpbmcgdW50cnVzdGVkIFhNTCBkYXRhIGFuZCB1bnRydXN0ZWQgWklQIGRhdGEuICBUaGUg
Y29uc3VtZXIgaXMgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhlIC56aXAgYXJjaGl2ZSwg
dGhlIFhNTCBzdHJ1Y3R1cmUsIGFuZCB0aGUgcmVzb3VyY2UgY29udGVudC4gIFBlciBzcGVjLCB0
aGVyZSBzaG91bGQgYmUgbm8gYWN0aXZlIGNvbnRlbnQgcHJvdmlkZWQgYXMgcGFydCBvZiB0aGUg
T3BlblhQUyBmb3JtYXQuICBUaGUgY29uc3VtZXIgbXVzdCBlbnN1cmUgdGhhdCBubyBtYWxpY2lv
dXMgYWN0aXZlIGNvbnRlbnQgaXMgZXJyb25lb3VzbHkgcHJvdmlkZWQgaW4gdGhlIE9wZW5YUFMg
ZG9jdW1lbnQuICBWYWxpZCBjb250ZW50IGlzIGRlc2NyaWJlZCBpbiB0aGUgRU1DQS0zODggc3Bl
Y2lmaWNhdGlvbiAoaHR0cDovL3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL3B1YmxpY2F0aW9u
cy9zdGFuZGFyZHMvRWNtYS0zODguaHRtKS4gIEVzcGVjaWFsbHkgdGFrZSBub3RlIG9mIHNlY3Rp
b24gRS4zLCB3aGljaCBkZXNjcmliZXMgc3RlcHMgdGhhdCBjYW4gYmUgdGFrZW4gdG8gdmFsaWRh
dGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBwYXlsb2FkLg0KDQoNCkludGVyb3BlcmFiaWxpdHkgY29u
c2lkZXJhdGlvbnM6DQphcHBsaWNhdGlvbi9PcGVuWFBTIGRvY3VtZW50cyBhcmUgc3BlY2lmaWVk
IGJ5IHRoZSBYTUwgc2NoZW1hcyBzdGFuZGFyZGl6ZWQgaW4gRUNNQS0zODguDQpBcHBsaWNhdGlv
bnMgYW5kIGRyaXZlcnMgY3VycmVudGx5IHByb2R1Y2luZy9jb25zdW1pbmcgTWljcm9zb2Z0IFhQ
UyBjb250ZW50IGNhbm5vdCBkaXJlY3RseSBwcm9kdWNlL2NvbnN1bWUgT3BlblhQUy4gIENoYW5n
ZXMgYXJlIHJlcXVpcmVkIHRvIGFkZHJlc3MgZGlmZmVyZW5jZXMgaW4gdGhlIHR3byBzcGVjaWZp
Y2F0aW9ucywgc3VjaCBhcyBuYW1lc3BhY2UsIHByaW50IHRpY2tldCB1c2FnZSwgdXNlIG9mIEpQ
RUcgWFIsIGV0Yy4NCg0KVG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHksIHRoZSBjbGlwYm9hcmQg
Zm9ybWF0IG11c3QgYmUgYSBjb21wbGV0ZSBPcGVuWFBTIGZpbGUgd2l0aCAub3hwcyBleHRlbnNp
b24uDQoNClB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOg0KVGhlIHB1Ymxpc2hlZCBzdGFuZGFyZCBF
Q01BLTM4OCBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5v
cmcvcHVibGljYXRpb25zL3N0YW5kYXJkcy9FY21hLTM4OC5odG0NCg0KQXBwbGljYXRpb25zIHRo
YXQgdXNlIHRoaXMgbWVkaWEgdHlwZToNClRoZSBhcHBsaWNhdGlvbi9PcGVuWFBTIE1JTUUgdHlw
ZSBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSBDU1RBIFhNTA0KKEVDTUEtMzg4KSBpbnN0YW5jZSBk
b2N1bWVudHMuICBObyBwdWJsaXNoZWQgYXBwbGljYXRpb25zIG9yIHByaW50IGRyaXZlcnMgY3Vy
cmVudGx5IHVzZSBPcGVuWFBTLiAgVGhlIGludGVudCBpcyBmb3IgYW55IGFwcGxpY2F0aW9uIG9y
IGRyaXZlciB0aGF0IGNhbiBjdXJyZW50bHkgcHJvZHVjZS9jb25zdW1lIE1pY3Jvc29mdCBYUFMg
dG8gYWxzbyBhZG9wdCBPcGVuWFBTLiAgRXhhbXBsZXMgb2Ygc3VjaCBhcHBsaWNhdGlvbnMgd291
bGQgaW5jbHVkZSBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOiAgTWljcm9zb2Z0IFhQUyBWaWV3ZXIs
IE1pY3Jvc29mdCBYUFMgRG9jdW1lbnQgV3JpdGVyLCBNaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9y
ZXIgOS4NCg0KQWRkaXRpb25hbCBpbmZvcm1hdGlvbjoNCg0KICBNYWdpYyBudW1iZXIocyk6ICBz
ZWUgYXBwbGljYXRpb24vemlwLiAgTm90ZSB0aGF0IGlzIGl0IGEgcmVxdWlyZW1lbnQgb2YgdGhl
IGNvbnN1bWVyIHRvIGVuc3VyZSB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUgWklQIGFyY2hpdmUg
aXMgYSB2YWxpZCBPcGVuWFBTIHN0cnVjdHVyZS4NCiAgRmlsZSBleHRlbnNpb24ocyk6IC5veHBz
DQogIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZShzKTogIG5vdCBhdmFpbGFibGUNCgkNCiAgV2lu
ZG93cyBDbGlwYm9hcmQgTmFtZTogIk9wZW5YUFMiDQogIE1hY2ludG9zaCBVbmlmb3JtIFR5cGUg
SWRlbnRpZmllcjogb3JnLmVjbWEub3hwcyBjb25mb3JtcyB0byBjb20ucGt3YXJlLnppcC1hcmNo
aXZlDQoNClBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBpbmZv
cm1hdGlvbjoNCg0KRWNtYSBJbnRlcm5hdGlvbmFsIEhlbHBkZXNrDQpSdWUgZHUgUmhvbmUgMTE0
DQpDSC0xMjA0IEdlbmV2YQ0KU3dpdHplcmxhbmQNCkVjbWEgSW50ZXJuYXRpb25hbCBIZWxwZGVz
azxoZWxwZGVza0BlY21hLWludGVybmF0aW9uYWwub3JnPg0KDQpJbnRlbmRlZCB1c2FnZTogQ09N
TU9ODQoNCg0KUmVzdHJpY3Rpb25zIG9uIHVzYWdlOiAgTi9BDQoNCg0KQXV0aG9yOiAgVGhlIEVD
TUEtMzg4IFN0YW5kYXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgRWNtYSBU
ZWNobmljYWwgQ29tbWl0dGVlIFRDNDYuDQoNCkNoYW5nZSBjb250cm9sbGVyOiAgVGhlIEVDTUEt
Mzg4IFN0YW5kYXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgRWNtYSBUZWNo
bmljYWwgQ29tbWl0dGVlIFRDNDYuDQo=

--_002_FE6603D65048F44AB8F8955AE89A09B9172FD14ETK5EX14MBXW651w_--


Return-Path: <derhoermi@gmx.net>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5CA14E0701 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 11:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.306
X-Spam-Level: 
X-Spam-Status: No, score=-4.306 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCKHon8vmZ18 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 11:28:09 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfc.amsl.com (Postfix) with ESMTP id 71172E06CE for <ietf-types@ietf.org>; Thu, 21 Apr 2011 11:28:08 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora1.lax.icann.org (8.13.8/8.13.8) with SMTP id p3LIRWRh008735 for <ietf-types@iana.org>; Thu, 21 Apr 2011 11:27:53 -0700
Received: (qmail invoked by alias); 21 Apr 2011 18:27:30 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp022) with SMTP; 21 Apr 2011 20:27:30 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18DBGklmY8DUAyNQE6NFyjQRpcSdRuxDq77lJNxdD gEzmjnYjcc32Ks
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Brian Clubb <Brian.Clubb@microsoft.com>
Date: Thu, 21 Apr 2011 20:27:40 +0200
Message-ID: <r4t0r61sqiiqkfsc4blq4t469vlslsmn2i@hive.bjoern.hoehrmann.de>
References: <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 21 Apr 2011 11:27:53 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 18:28:10 -0000

* Brian Clubb wrote:
>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: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: <paul@hoplahup.net>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DBDE7E0820 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 11:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJUz1Kk30nPA for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 11:02:32 -0700 (PDT)
Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by ietfc.amsl.com (Postfix) with ESMTP id BDEE3E0824 for <ietf-types@ietf.org>; Thu, 21 Apr 2011 11:02:31 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3LI1tXs020734 for <ietf-types@iana.org>; Thu, 21 Apr 2011 14:02:16 -0400
Received: from [192.168.178.137] (srbk-4db7fa50.pool.mediaWays.net [77.183.250.80]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MSr7l-1QN2uo3rNN-00Rq5f; Thu, 21 Apr 2011 20:01:28 +0200
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: <FE6603D65048F44AB8F8955AE89A09B9172FCFA1@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 21 Apr 2011 20:01:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1886CA5-CAFD-4EF8-B1AE-94439D3309E9@hoplahup.net>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <8F525887-A607-4334-926D-700DDA0102A9@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9172FCDED@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <F0D22CBD-886A-420F-AE25-A4B501B84BB8@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9172FCFA1@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
To: Brian Clubb <Brian.Clubb@microsoft.com>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:vAAiS019hNNSwvXIrH5jgGLMdEfHP9zXJA3egKX67Km clyRRnSoDiGbkrzO6DQQagxeLD7nM3gBCJo3DHeod6T3/QBHwv Tk0BVQxlAvQ9gpd/IG5PIfc+RdJ5gDDRSgQ3rR7qRZLt6cN0nH MkYDHIAQoJhibBUe51HFy4raqTa4mgKnfNjEKENfRnKyT6G7WV TuiOynd5sI38TKokdbmbBWygqMXMrbqxW/lVekj7hU=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Thu, 21 Apr 2011 14:02:16 -0400 (EDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 18:02:34 -0000

Thanks,=20
fits me

paul


Le 21 avr. 2011 =E0 19:41, Brian Clubb a =E9crit :

> Paul,
>=20
> That works for me!  Revision attached and included below.  :-)
>=20
> Thanks!
> Brian=20
>=20
> <template>
> Type name: application/OpenXPS
>=20
> Subtype name:  Standards Tree - OpenXPS
>=20
> Required parameters:  N/A
>=20
> Optional parameters:  N/A
>=20
> Encoding considerations:  binary
>=20
> 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=20
>=20
> 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=20
>=20
> 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=20
>=20
> 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=20=

>=20
> taken to validate the contents of the payload.
>=20
>=20
> 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=20
>=20
> specifications, such as namespace, print ticket usage, use of JPEG XR, =
etc.
>=20
> To ensure interoperability, the clipboard format must be a complete =
OpenXPS file with .oxps extension.
>=20
> Published specification:
> The published standard ECMA-388 is available at:
> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>=20
> 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=20
>=20
> 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,=20
>=20
> Microsoft Internet Explorer 9.
>=20
> Additional information:
>=20
>  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=20
>=20
> the contents of the ZIP archive is a valid OpenXPS structure.
>  File extension(s): .oxps
>  Macintosh file type code(s):  not available
> =09
>  Windows Clipboard Name: "OpenXPS"
>  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to =
com.pkware.zip-archive
>=20
> Person & email address to contact for further information:
>=20
> Ecma International Helpdesk
> Rue du Rhone 114
> CH-1204 Geneva
> Switzerland
> Ecma International Helpdesk<helpdesk@ecma-international.org>
>=20
> Intended usage: COMMON
>=20
>=20
> Restrictions on usage:  N/A
>=20
>=20
> Author:  The ECMA-388 Standard is developed and maintained by the Ecma =
Technical Committee TC46.
>=20
> Change controller:  The ECMA-388 Standard is developed and maintained =
by the Ecma Technical Committee TC46.
> </template>
>=20
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
> Sent: Thursday, April 21, 2011 9:37 AM
> To: Brian Clubb
> Cc: Bjoern Hoehrmann; Pete Resnick; ietf-types@iana.org
> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME =
type
>=20
> Brian,
>=20
> 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?)
>=20
> paul
>=20
>=20
> Le 21 avr. 2011 =E0 18:30, Brian Clubb a =E9crit :
>=20
>> Paul,
>>=20
>> 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.
>>=20
>> Edited template is attached and provided below.
>>=20
>> Thanks!
>> Brian
>>=20
>> <template>
>> Type name: application/OpenXPS
>>=20
>> Subtype name:  Standards Tree - OpenXPS
>>=20
>> Required parameters:  N/A
>>=20
>> Optional parameters:  N/A
>>=20
>> Encoding considerations:  binary
>>=20
>> Security considerations:
>> OpenXPS uses ZIP compression as specified in .ZIP File Format=20
>> Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP =
compressed=20
>> XML requires parsing untrusted XML data
>>=20
>> and untrusted ZIP data.  The consumer is responsible for validating=20=

>> the .zip archive, the XML structure, and the resource content.  Per=20=

>> spec, there should be no active content
>>=20
>> provided as part of the OpenXPS format.  The consumer must ensure =
that=20
>> no malicious active content is erroneously provided in the OpenXPS=20
>> document.  Valid content is described
>>=20
>> in the EMCA-388 specification=20
>> =
(http://www.ecma-international.org/publications/standards/Ecma-388.htm
>> ).  Especially take note of section E.3, which describes steps that=20=

>> can be
>>=20
>> taken to validate the contents of the payload.
>>=20
>>=20
>> Interoperability considerations:
>> application/OpenXPS documents are specified by the XML schemas =
standardized in ECMA-388.
>> Applications and drivers currently producing/consuming Microsoft XPS=20=

>> content cannot directly produce/consume OpenXPS.  Changes are =
required=20
>> to address differences in the two
>>=20
>> specifications, such as namespace, print ticket usage, use of JPEG =
XR, etc.
>>=20
>> To ensure interoperability, the clipboard format must be a complete =
OpenXPS file with .oxps extension.
>>=20
>> Published specification:
>> The published standard ECMA-388 is available at:
>> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>>=20
>> 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=20
>> drivers currently use OpenXPS.  The intent is for any application or=20=

>> driver that can currently
>>=20
>> produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of =
such=20
>> applications would include but are not limited to:  Microsoft XPS=20
>> Viewer, Microsoft XPS Document Writer,
>>=20
>> Microsoft Internet Explorer 9.
>>=20
>> Additional information:
>>=20
>> Magic number(s):  ZIP archive CRC-32: 504b 0304 per=20
>> http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that=20=

>> is it a requirement of the consumer to ensure that
>>=20
>> 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=20
>> com.pkware.zip-archive
>>=20
>> Person & email address to contact for further information:
>>=20
>> Ecma International Helpdesk
>> Rue du Rhone 114
>> CH-1204 Geneva
>> Switzerland
>> Ecma International Helpdesk<helpdesk@ecma-international.org>
>>=20
>> Intended usage: COMMON
>>=20
>>=20
>> Restrictions on usage:  N/A
>>=20
>>=20
>> Author:  The ECMA-388 Standard is developed and maintained by the =
Ecma Technical Committee TC46.
>>=20
>> Change controller:  The ECMA-388 Standard is developed and maintained =
by the Ecma Technical Committee TC46.
>> </template>
>>=20
>> -----Original Message-----
>> From: Paul Libbrecht [mailto:paul@hoplahup.net]
>> Sent: Thursday, April 21, 2011 9:20 AM
>> To: Brian Clubb
>> Cc: Bjoern Hoehrmann; Pete Resnick; ietf-types@iana.org
>> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME=20=

>> type
>>=20
>> Brian,
>>=20
>> I note that my comment of March 21st was not responded to, you still =
use wrongly Macintosh filetype.=20
>> Moreover it appears that the windows clipboard name has disappeared.
>>=20
>> Have I missed a bit of discussion about this?
>>=20
>> paul
>>=20
>> Le 21 avr. 2011 =E0 17:47, Brian Clubb a =E9crit :
>>=20
>>> Bjoern,
>>>=20
>>> Thanks for the feedback!
>>>=20
>>> 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".
>>>=20
>>> 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.
>>>=20
>>> Let me know if there is anything else.  I have attached the revised =
template and provided it below as well.
>>>=20
>>> Thanks!
>>> Brian
>>>=20
>>> <template>
>>> Type name: application/OpenXPS
>>>=20
>>> Subtype name:  Standards Tree - OpenXPS
>>>=20
>>> Required parameters:  N/A
>>>=20
>>> Optional parameters:  N/A
>>>=20
>>> Encoding considerations:  binary
>>>=20
>>> 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.
>>>=20
>>>=20
>>> 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.
>>>=20
>>> Published specification:
>>> The published standard ECMA-388 is available at:
>>> =
http://www.ecma-international.org/publications/standards/Ecma-388.htm
>>>=20
>>> 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.
>>>=20
>>> Additional information:
>>>=20
>>> 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=20
>>> com.pkware.zip-archive
>>>=20
>>> Person & email address to contact for further information:
>>>=20
>>> Ecma International Helpdesk
>>> Rue du Rhone 114
>>> CH-1204 Geneva
>>> Switzerland
>>> Ecma International Helpdesk<helpdesk@ecma-international.org>
>>>=20
>>> Intended usage: COMMON
>>>=20
>>>=20
>>> Restrictions on usage:  N/A
>>>=20
>>>=20
>>> Author:  The ECMA-388 Standard is developed and maintained by the =
Ecma Technical Committee TC46.
>>>=20
>>> Change controller:  The ECMA-388 Standard is developed and =
maintained by the Ecma Technical Committee TC46.
>>> </template
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
>>> Sent: Tuesday, April 19, 2011 10:32 AM
>>> To: Brian Clubb
>>> Cc: Pete Resnick; ietf-types@iana.org
>>> Subject: Re: [ietf-types] Request for final approval for OpenXPS =
MIME=20
>>> type
>>>=20
>>> * Brian Clubb wrote:
>>>> <template>
>>>> Name : Brian Clubb
>>>>=20
>>>> Email : bclubb@microsoft.com
>>>>=20
>>>> MIME media type name : application
>>>>=20
>>>> MIME subtype name : Standards Tree - OpenXPS
>>>=20
>>> 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.
>>>=20
>>>> Required parameters : N/A
>>>>=20
>>>> Optional parameters :N/A
>>>>=20
>>>> Encoding considerations : 8-bit
>>>=20
>>> It seems this should be "binary", see the definitions in RFC 4288.
>>>=20
>>>> Person to contact for further information :
>>>>=20
>>>> 1. Name : Ecma International Helpdesk 2. Email :=20
>>>> helpdesk@ecma-international.org
>>>=20
>>> It is customary to write this as
>>>=20
>>> Ecma International Helpdesk <helpdesk@ecma-international.org>
>>>=20
>>> (And I am not sure "Ecma" is the preferred spelling).
>>>=20
>>>> Intended usage : Common
>>>=20
>>> This should be spelled COMMON.
>>>=20
>>> I note that per RFC 4288 section 4.10:
>>>=20
>>> As stated previously, standards tree registrations for media types=20=

>>> defined in documents produced by other standards bodies MUST be=20
>>> described by a formal standards specification produced by that body.
>>> Such specifications MUST contain an appropriate media type=20
>>> registration template taken from Section 10.  Additionally, the=20
>>> copyright on the registration template MUST allow the IANA to copy =
it=20
>>> into the IANA registry.
>>>=20
>>> 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=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20
>>> http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon:=20
>>> +49(0)160/4415681 =B7 http://www.bjoernsworld.de
>>> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20
>>> http://www.websitedev.de/
>>>=20
>>> <MIMEReg.txt>_______________________________________________
>>> ietf-types mailing list
>>> ietf-types@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-types
>>=20
>>=20
>> <MIMEReg.txt>
>=20
>=20
> <MIMEReg.txt>



Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2230E07D7 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 10:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.139
X-Spam-Level: 
X-Spam-Status: No, score=-4.139 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HkeqEY3XVtk for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 10:41:41 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfc.amsl.com (Postfix) with ESMTP id 27965E0757 for <ietf-types@ietf.org>; Thu, 21 Apr 2011 10:41:39 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3LHf4Kd024955 for <ietf-types@iana.org>; Thu, 21 Apr 2011 10:41:24 -0700
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 10:41:03 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 10:41:02 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Thu, 21 Apr 2011 10:41:02 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Paul Libbrecht <paul@hoplahup.net>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAuzKiAAAN+U7w//+bEQD//W5rEIAFog+AgAB0x6D//4/4AIAAY8eQ
Date: Thu, 21 Apr 2011 17:41:02 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172FCFA1@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <8F525887-A607-4334-926D-700DDA0102A9@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9172FCDED@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <F0D22CBD-886A-420F-AE25-A4B501B84BB8@hoplahup.net>
In-Reply-To: <F0D22CBD-886A-420F-AE25-A4B501B84BB8@hoplahup.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/mixed; boundary="_002_FE6603D65048F44AB8F8955AE89A09B9172FCFA1TK5EX14MBXW651w_"
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 21 Apr 2011 10:41:24 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 17:41:43 -0000

--_002_FE6603D65048F44AB8F8955AE89A09B9172FCFA1TK5EX14MBXW651w_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Paul,

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

Thanks!
Brian=20

<template>
Type name: application/OpenXPS

Subtype name:  Standards Tree - OpenXPS

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary

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=20

and untrusted ZIP data.  The consumer is responsible for validating the .zi=
p archive, the XML structure, and the resource content.  Per spec, there sh=
ould be no active content=20

provided as part of the OpenXPS format.  The consumer must ensure that no m=
alicious active content is erroneously provided in the OpenXPS document.  V=
alid content is described=20

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

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 conten=
t cannot directly produce/consume OpenXPS.  Changes are required to address=
 differences in the two=20

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:
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 ca=
n currently=20

produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such appl=
ications would include but are not limited to:  Microsoft XPS Viewer, Micro=
soft XPS Document Writer,=20

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=20

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

Person & email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

Intended usage: COMMON


Restrictions on usage:  N/A


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

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

-----Original Message-----
From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
Sent: Thursday, April 21, 2011 9:37 AM
To: Brian Clubb
Cc: Bjoern Hoehrmann; Pete Resnick; ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

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 =E0 18:30, Brian Clubb a =E9crit :

> Paul,
>=20
> 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 an=
y issue with changing "Macintosh file type code(s)" to "Macintosh Uniform T=
ype Identifier" in the prescribed template.
>=20
> Edited template is attached and provided below.
>=20
> Thanks!
> Brian
>=20
> <template>
> Type name: application/OpenXPS
>=20
> Subtype name:  Standards Tree - OpenXPS
>=20
> Required parameters:  N/A
>=20
> Optional parameters:  N/A
>=20
> Encoding considerations:  binary
>=20
> Security considerations:
> OpenXPS uses ZIP compression as specified in .ZIP File Format=20
> Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed=20
> XML requires parsing untrusted XML data
>=20
> and untrusted ZIP data.  The consumer is responsible for validating=20
> the .zip archive, the XML structure, and the resource content.  Per=20
> spec, there should be no active content
>=20
> provided as part of the OpenXPS format.  The consumer must ensure that=20
> no malicious active content is erroneously provided in the OpenXPS=20
> document.  Valid content is described
>=20
> in the EMCA-388 specification=20
> (http://www.ecma-international.org/publications/standards/Ecma-388.htm
> ).  Especially take note of section E.3, which describes steps that=20
> can be
>=20
> taken to validate the contents of the payload.
>=20
>=20
> Interoperability considerations:
> application/OpenXPS documents are specified by the XML schemas standardiz=
ed in ECMA-388.
> Applications and drivers currently producing/consuming Microsoft XPS=20
> content cannot directly produce/consume OpenXPS.  Changes are required=20
> to address differences in the two
>=20
> specifications, such as namespace, print ticket usage, use of JPEG XR, et=
c.
>=20
> To ensure interoperability, the clipboard format must be a complete OpenX=
PS file with .oxps extension.
>=20
> Published specification:
> The published standard ECMA-388 is available at:
> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>=20
> 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=20
> drivers currently use OpenXPS.  The intent is for any application or=20
> driver that can currently
>=20
> produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such=20
> applications would include but are not limited to:  Microsoft XPS=20
> Viewer, Microsoft XPS Document Writer,
>=20
> Microsoft Internet Explorer 9.
>=20
> Additional information:
>=20
>  Magic number(s):  ZIP archive CRC-32: 504b 0304 per=20
> http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that=20
> is it a requirement of the consumer to ensure that
>=20
> 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=20
> com.pkware.zip-archive
>=20
> Person & email address to contact for further information:
>=20
> Ecma International Helpdesk
> Rue du Rhone 114
> CH-1204 Geneva
> Switzerland
> Ecma International Helpdesk<helpdesk@ecma-international.org>
>=20
> Intended usage: COMMON
>=20
>=20
> Restrictions on usage:  N/A
>=20
>=20
> Author:  The ECMA-388 Standard is developed and maintained by the Ecma Te=
chnical Committee TC46.
>=20
> Change controller:  The ECMA-388 Standard is developed and maintained by =
the Ecma Technical Committee TC46.
> </template>
>=20
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@hoplahup.net]
> Sent: Thursday, April 21, 2011 9:20 AM
> To: Brian Clubb
> Cc: Bjoern Hoehrmann; Pete Resnick; ietf-types@iana.org
> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME=20
> type
>=20
> Brian,
>=20
> I note that my comment of March 21st was not responded to, you still use =
wrongly Macintosh filetype.=20
> Moreover it appears that the windows clipboard name has disappeared.
>=20
> Have I missed a bit of discussion about this?
>=20
> paul
>=20
> Le 21 avr. 2011 =E0 17:47, Brian Clubb a =E9crit :
>=20
>> Bjoern,
>>=20
>> Thanks for the feedback!
>>=20
>> I have updated the registration using the new template (attached).  "Ecm=
a" is the preferred case usage when talking about the organization but "ECM=
A" is used when referencing specs; thus "Ecma International Helpdesk" and "=
Ecma Technical Committee TC46" but the specification is "ECMA-388".
>>=20
>> The current ECMA-388 specification is due for editorial reviews and upda=
tes this year.  I will make sure that the approved template is in that revi=
sion.
>>=20
>> Let me know if there is anything else.  I have attached the revised temp=
late and provided it below as well.
>>=20
>> Thanks!
>> Brian
>>=20
>> <template>
>> Type name: application/OpenXPS
>>=20
>> Subtype name:  Standards Tree - OpenXPS
>>=20
>> Required parameters:  N/A
>>=20
>> Optional parameters:  N/A
>>=20
>> Encoding considerations:  binary
>>=20
>> Security considerations:
>> OpenXPS uses ZIP compression as specified in .ZIP File Format Specificat=
ion from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires p=
arsing untrusted XML data and untrusted ZIP data.  The consumer is responsi=
ble for validating the .zip archive, the XML structure, and the resource co=
ntent.  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 describ=
ed in the EMCA-388 specification (http://www.ecma-international.org/publica=
tions/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.
>>=20
>>=20
>> Interoperability considerations:
>> application/OpenXPS documents are specified by the XML schemas standardi=
zed in ECMA-388.
>> Applications and drivers currently producing/consuming Microsoft XPS con=
tent cannot directly produce/consume OpenXPS.  Changes are required to addr=
ess differences in the two specifications, such as namespace, print ticket =
usage, use of JPEG XR, etc.
>>=20
>> Published specification:
>> The published standard ECMA-388 is available at:
>> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>>=20
>> 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 drive=
rs currently use OpenXPS.  The intent is for any application or driver that=
 can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Exampl=
es of such applications would include but are not limited to:  Microsoft XP=
S Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.
>>=20
>> Additional information:
>>=20
>> Magic number(s):  ZIP archive CRC-32: 504b 0304 per http://www.pkware.co=
m/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of th=
e consumer to ensure that the contents of the ZIP archive is a valid OpenXP=
S structure.
>> File extension(s): .oxps
>> Macintosh file type code(s):  org.ecma.oxps conforms to=20
>> com.pkware.zip-archive
>>=20
>> Person & email address to contact for further information:
>>=20
>> Ecma International Helpdesk
>> Rue du Rhone 114
>> CH-1204 Geneva
>> Switzerland
>> Ecma International Helpdesk<helpdesk@ecma-international.org>
>>=20
>> Intended usage: COMMON
>>=20
>>=20
>> Restrictions on usage:  N/A
>>=20
>>=20
>> Author:  The ECMA-388 Standard is developed and maintained by the Ecma T=
echnical Committee TC46.
>>=20
>> Change controller:  The ECMA-388 Standard is developed and maintained by=
 the Ecma Technical Committee TC46.
>> </template
>>=20
>>=20
>> -----Original Message-----
>> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
>> Sent: Tuesday, April 19, 2011 10:32 AM
>> To: Brian Clubb
>> Cc: Pete Resnick; ietf-types@iana.org
>> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME=20
>> type
>>=20
>> * Brian Clubb wrote:
>>> <template>
>>> Name : Brian Clubb
>>>=20
>>> Email : bclubb@microsoft.com
>>>=20
>>> MIME media type name : application
>>>=20
>>> MIME subtype name : Standards Tree - OpenXPS
>>=20
>> 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 pi=
eces of information differently.
>>=20
>>> Required parameters : N/A
>>>=20
>>> Optional parameters :N/A
>>>=20
>>> Encoding considerations : 8-bit
>>=20
>> It seems this should be "binary", see the definitions in RFC 4288.
>>=20
>>> Person to contact for further information :
>>>=20
>>> 1. Name : Ecma International Helpdesk 2. Email :=20
>>> helpdesk@ecma-international.org
>>=20
>> It is customary to write this as
>>=20
>> Ecma International Helpdesk <helpdesk@ecma-international.org>
>>=20
>> (And I am not sure "Ecma" is the preferred spelling).
>>=20
>>> Intended usage : Common
>>=20
>> This should be spelled COMMON.
>>=20
>> I note that per RFC 4288 section 4.10:
>>=20
>> As stated previously, standards tree registrations for media types=20
>> defined in documents produced by other standards bodies MUST be=20
>> described by a formal standards specification produced by that body.
>> Such specifications MUST contain an appropriate media type=20
>> registration template taken from Section 10.  Additionally, the=20
>> copyright on the registration template MUST allow the IANA to copy it=20
>> into the IANA registry.
>>=20
>> Which section of the specification does include the template, or, if non=
e at the moment, should we expect the specification to be revised to includ=
e it "soon"?
>> --
>> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20
>> http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon:=20
>> +49(0)160/4415681 =B7 http://www.bjoernsworld.de
>> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20
>> http://www.websitedev.de/
>>=20
>> <MIMEReg.txt>_______________________________________________
>> ietf-types mailing list
>> ietf-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-types
>=20
>=20
> <MIMEReg.txt>



--_002_FE6603D65048F44AB8F8955AE89A09B9172FCFA1TK5EX14MBXW651w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=3002;
	creation-date="Wed, 20 Apr 2011 16:58:49 GMT";
	modification-date="Thu, 21 Apr 2011 17:40:40 GMT"
Content-Transfer-Encoding: base64

VHlwZSBuYW1lOiBhcHBsaWNhdGlvbi9PcGVuWFBTDQoNClN1YnR5cGUgbmFtZTogIFN0YW5kYXJk
cyBUcmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzOiAgTi9BDQoNCk9wdGlvbmFs
IHBhcmFtZXRlcnM6ICBOL0ENCg0KRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6ICBiaW5hcnkNCg0K
U2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQpPcGVuWFBTIHVzZXMgWklQIGNvbXByZXNzaW9uIGFz
IHNwZWNpZmllZCBpbiAuWklQIEZpbGUgRm9ybWF0IFNwZWNpZmljYXRpb24gZnJvbSBQS1dBUkUs
IEluYy4sIHZlcnNpb24gNi4yLjAgKDIwMDQpLiAgWklQIGNvbXByZXNzZWQgWE1MIHJlcXVpcmVz
IHBhcnNpbmcgdW50cnVzdGVkIFhNTCBkYXRhIGFuZCB1bnRydXN0ZWQgWklQIGRhdGEuICBUaGUg
Y29uc3VtZXIgaXMgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhlIC56aXAgYXJjaGl2ZSwg
dGhlIFhNTCBzdHJ1Y3R1cmUsIGFuZCB0aGUgcmVzb3VyY2UgY29udGVudC4gIFBlciBzcGVjLCB0
aGVyZSBzaG91bGQgYmUgbm8gYWN0aXZlIGNvbnRlbnQgcHJvdmlkZWQgYXMgcGFydCBvZiB0aGUg
T3BlblhQUyBmb3JtYXQuICBUaGUgY29uc3VtZXIgbXVzdCBlbnN1cmUgdGhhdCBubyBtYWxpY2lv
dXMgYWN0aXZlIGNvbnRlbnQgaXMgZXJyb25lb3VzbHkgcHJvdmlkZWQgaW4gdGhlIE9wZW5YUFMg
ZG9jdW1lbnQuICBWYWxpZCBjb250ZW50IGlzIGRlc2NyaWJlZCBpbiB0aGUgRU1DQS0zODggc3Bl
Y2lmaWNhdGlvbiAoaHR0cDovL3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL3B1YmxpY2F0aW9u
cy9zdGFuZGFyZHMvRWNtYS0zODguaHRtKS4gIEVzcGVjaWFsbHkgdGFrZSBub3RlIG9mIHNlY3Rp
b24gRS4zLCB3aGljaCBkZXNjcmliZXMgc3RlcHMgdGhhdCBjYW4gYmUgdGFrZW4gdG8gdmFsaWRh
dGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBwYXlsb2FkLg0KDQoNCkludGVyb3BlcmFiaWxpdHkgY29u
c2lkZXJhdGlvbnM6DQphcHBsaWNhdGlvbi9PcGVuWFBTIGRvY3VtZW50cyBhcmUgc3BlY2lmaWVk
IGJ5IHRoZSBYTUwgc2NoZW1hcyBzdGFuZGFyZGl6ZWQgaW4gRUNNQS0zODguDQpBcHBsaWNhdGlv
bnMgYW5kIGRyaXZlcnMgY3VycmVudGx5IHByb2R1Y2luZy9jb25zdW1pbmcgTWljcm9zb2Z0IFhQ
UyBjb250ZW50IGNhbm5vdCBkaXJlY3RseSBwcm9kdWNlL2NvbnN1bWUgT3BlblhQUy4gIENoYW5n
ZXMgYXJlIHJlcXVpcmVkIHRvIGFkZHJlc3MgZGlmZmVyZW5jZXMgaW4gdGhlIHR3byBzcGVjaWZp
Y2F0aW9ucywgc3VjaCBhcyBuYW1lc3BhY2UsIHByaW50IHRpY2tldCB1c2FnZSwgdXNlIG9mIEpQ
RUcgWFIsIGV0Yy4NCg0KVG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHksIHRoZSBjbGlwYm9hcmQg
Zm9ybWF0IG11c3QgYmUgYSBjb21wbGV0ZSBPcGVuWFBTIGZpbGUgd2l0aCAub3hwcyBleHRlbnNp
b24uDQoNClB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOg0KVGhlIHB1Ymxpc2hlZCBzdGFuZGFyZCBF
Q01BLTM4OCBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5v
cmcvcHVibGljYXRpb25zL3N0YW5kYXJkcy9FY21hLTM4OC5odG0NCg0KQXBwbGljYXRpb25zIHRo
YXQgdXNlIHRoaXMgbWVkaWEgdHlwZToNClRoZSBhcHBsaWNhdGlvbi9PcGVuWFBTIE1JTUUgdHlw
ZSBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSBDU1RBIFhNTA0KKEVDTUEtMzg4KSBpbnN0YW5jZSBk
b2N1bWVudHMuICBObyBwdWJsaXNoZWQgYXBwbGljYXRpb25zIG9yIHByaW50IGRyaXZlcnMgY3Vy
cmVudGx5IHVzZSBPcGVuWFBTLiAgVGhlIGludGVudCBpcyBmb3IgYW55IGFwcGxpY2F0aW9uIG9y
IGRyaXZlciB0aGF0IGNhbiBjdXJyZW50bHkgcHJvZHVjZS9jb25zdW1lIE1pY3Jvc29mdCBYUFMg
dG8gYWxzbyBhZG9wdCBPcGVuWFBTLiAgRXhhbXBsZXMgb2Ygc3VjaCBhcHBsaWNhdGlvbnMgd291
bGQgaW5jbHVkZSBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOiAgTWljcm9zb2Z0IFhQUyBWaWV3ZXIs
IE1pY3Jvc29mdCBYUFMgRG9jdW1lbnQgV3JpdGVyLCBNaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9y
ZXIgOS4NCg0KQWRkaXRpb25hbCBpbmZvcm1hdGlvbjoNCg0KICBNYWdpYyBudW1iZXIocyk6ICBa
SVAgYXJjaGl2ZSBDUkMtMzI6IDUwNGIgMDMwNCBwZXIgaHR0cDovL3d3dy5wa3dhcmUuY29tL2Rv
Y3VtZW50cy9BUFBOT1RFL0FQUE5PVEUtNi4yLjAudHh0LiAgTm90ZSB0aGF0IGlzIGl0IGEgcmVx
dWlyZW1lbnQgb2YgdGhlIGNvbnN1bWVyIHRvIGVuc3VyZSB0aGF0IHRoZSBjb250ZW50cyBvZiB0
aGUgWklQIGFyY2hpdmUgaXMgYSB2YWxpZCBPcGVuWFBTIHN0cnVjdHVyZS4NCiAgRmlsZSBleHRl
bnNpb24ocyk6IC5veHBzDQogIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZShzKTogIG5vdCBhdmFp
bGFibGUNCgkNCiAgV2luZG93cyBDbGlwYm9hcmQgTmFtZTogIk9wZW5YUFMiDQogIE1hY2ludG9z
aCBVbmlmb3JtIFR5cGUgSWRlbnRpZmllcjogb3JnLmVjbWEub3hwcyBjb25mb3JtcyB0byBjb20u
cGt3YXJlLnppcC1hcmNoaXZlDQoNClBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBm
b3IgZnVydGhlciBpbmZvcm1hdGlvbjoNCg0KRWNtYSBJbnRlcm5hdGlvbmFsIEhlbHBkZXNrDQpS
dWUgZHUgUmhvbmUgMTE0DQpDSC0xMjA0IEdlbmV2YQ0KU3dpdHplcmxhbmQNCkVjbWEgSW50ZXJu
YXRpb25hbCBIZWxwZGVzazxoZWxwZGVza0BlY21hLWludGVybmF0aW9uYWwub3JnPg0KDQpJbnRl
bmRlZCB1c2FnZTogQ09NTU9ODQoNCg0KUmVzdHJpY3Rpb25zIG9uIHVzYWdlOiAgTi9BDQoNCg0K
QXV0aG9yOiAgVGhlIEVDTUEtMzg4IFN0YW5kYXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5l
ZCBieSB0aGUgRWNtYSBUZWNobmljYWwgQ29tbWl0dGVlIFRDNDYuDQoNCkNoYW5nZSBjb250cm9s
bGVyOiAgVGhlIEVDTUEtMzg4IFN0YW5kYXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBi
eSB0aGUgRWNtYSBUZWNobmljYWwgQ29tbWl0dGVlIFRDNDYuDQo=

--_002_FE6603D65048F44AB8F8955AE89A09B9172FCFA1TK5EX14MBXW651w_--


Return-Path: <paul@hoplahup.net>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C26BCE07AC for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 09:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quRVfiS9MZVK for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 09:37:33 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfc.amsl.com (Postfix) with ESMTP id 35B2FE07A3 for <ietf-types@ietf.org>; Thu, 21 Apr 2011 09:37:33 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3LGbCnb030505 for <ietf-types@iana.org>; Thu, 21 Apr 2011 12:37:32 -0400
Received: from brouwer.fritz.box (srbk-4db7fa50.pool.mediaWays.net [77.183.250.80]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M2M3o-1PwVzL1vrI-00s4BZ; Thu, 21 Apr 2011 18:37:08 +0200
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: <FE6603D65048F44AB8F8955AE89A09B9172FCDED@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 21 Apr 2011 18:37:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0D22CBD-886A-420F-AE25-A4B501B84BB8@hoplahup.net>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <8F525887-A607-4334-926D-700DDA0102A9@hoplahup.net> <FE6603D65048F44AB8F8955AE89A09B9172FCDED@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
To: Brian Clubb <Brian.Clubb@microsoft.com>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:iQuCHqoHogcNgP/IduAgUE4hrDC12g2G6Xxm7W/AAHd YlH1d299pgKcwvcmpaXTXB7jHxNiZtxSSsl6MFFX/pfscdXuni tURPtn+TJa4L5aEdsnPwyJ+yyAFDCWBeNOQUgXLB5XJSIa9N9V QepgW4crvG6UGRTKR2Axhh5q83yv9NtlcQstOwAVYbxXPhCKiI usCVHgO8f0+LX7MfiN9LcO/bg7YxCRZZZc78WhFOTQ=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Thu, 21 Apr 2011 12:37:32 -0400 (EDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 16:37:34 -0000

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 =E0 18:30, Brian Clubb a =E9crit :

> Paul,
>=20
> 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.
>=20
> Edited template is attached and provided below.
>=20
> Thanks!
> Brian
>=20
> <template>
> Type name: application/OpenXPS
>=20
> Subtype name:  Standards Tree - OpenXPS
>=20
> Required parameters:  N/A
>=20
> Optional parameters:  N/A
>=20
> Encoding considerations:  binary
>=20
> 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=20
>=20
> 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=20
>=20
> 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=20
>=20
> 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=20=

>=20
> taken to validate the contents of the payload.
>=20
>=20
> 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=20
>=20
> specifications, such as namespace, print ticket usage, use of JPEG XR, =
etc.
>=20
> To ensure interoperability, the clipboard format must be a complete =
OpenXPS file with .oxps extension.
>=20
> Published specification:
> The published standard ECMA-388 is available at:
> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>=20
> 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=20
>=20
> 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,=20
>=20
> Microsoft Internet Explorer 9.
>=20
> Additional information:
>=20
>  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=20
>=20
> 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
>=20
> Person & email address to contact for further information:
>=20
> Ecma International Helpdesk
> Rue du Rhone 114
> CH-1204 Geneva
> Switzerland
> Ecma International Helpdesk<helpdesk@ecma-international.org>
>=20
> Intended usage: COMMON
>=20
>=20
> Restrictions on usage:  N/A
>=20
>=20
> Author:  The ECMA-388 Standard is developed and maintained by the Ecma =
Technical Committee TC46.
>=20
> Change controller:  The ECMA-388 Standard is developed and maintained =
by the Ecma Technical Committee TC46.
> </template>
>=20
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
> Sent: Thursday, April 21, 2011 9:20 AM
> To: Brian Clubb
> Cc: Bjoern Hoehrmann; Pete Resnick; ietf-types@iana.org
> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME =
type
>=20
> Brian,
>=20
> I note that my comment of March 21st was not responded to, you still =
use wrongly Macintosh filetype.=20
> Moreover it appears that the windows clipboard name has disappeared.
>=20
> Have I missed a bit of discussion about this?
>=20
> paul
>=20
> Le 21 avr. 2011 =E0 17:47, Brian Clubb a =E9crit :
>=20
>> Bjoern,
>>=20
>> Thanks for the feedback!
>>=20
>> 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".
>>=20
>> 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.
>>=20
>> Let me know if there is anything else.  I have attached the revised =
template and provided it below as well.
>>=20
>> Thanks!
>> Brian
>>=20
>> <template>
>> Type name: application/OpenXPS
>>=20
>> Subtype name:  Standards Tree - OpenXPS
>>=20
>> Required parameters:  N/A
>>=20
>> Optional parameters:  N/A
>>=20
>> Encoding considerations:  binary
>>=20
>> 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.
>>=20
>>=20
>> 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.
>>=20
>> Published specification:
>> The published standard ECMA-388 is available at:
>> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>>=20
>> 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.
>>=20
>> Additional information:
>>=20
>> 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=20
>> com.pkware.zip-archive
>>=20
>> Person & email address to contact for further information:
>>=20
>> Ecma International Helpdesk
>> Rue du Rhone 114
>> CH-1204 Geneva
>> Switzerland
>> Ecma International Helpdesk<helpdesk@ecma-international.org>
>>=20
>> Intended usage: COMMON
>>=20
>>=20
>> Restrictions on usage:  N/A
>>=20
>>=20
>> Author:  The ECMA-388 Standard is developed and maintained by the =
Ecma Technical Committee TC46.
>>=20
>> Change controller:  The ECMA-388 Standard is developed and maintained =
by the Ecma Technical Committee TC46.
>> </template
>>=20
>>=20
>> -----Original Message-----
>> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
>> Sent: Tuesday, April 19, 2011 10:32 AM
>> To: Brian Clubb
>> Cc: Pete Resnick; ietf-types@iana.org
>> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME=20=

>> type
>>=20
>> * Brian Clubb wrote:
>>> <template>
>>> Name : Brian Clubb
>>>=20
>>> Email : bclubb@microsoft.com
>>>=20
>>> MIME media type name : application
>>>=20
>>> MIME subtype name : Standards Tree - OpenXPS
>>=20
>> 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.
>>=20
>>> Required parameters : N/A
>>>=20
>>> Optional parameters :N/A
>>>=20
>>> Encoding considerations : 8-bit
>>=20
>> It seems this should be "binary", see the definitions in RFC 4288.
>>=20
>>> Person to contact for further information :
>>>=20
>>> 1. Name : Ecma International Helpdesk 2. Email :=20
>>> helpdesk@ecma-international.org
>>=20
>> It is customary to write this as
>>=20
>> Ecma International Helpdesk <helpdesk@ecma-international.org>
>>=20
>> (And I am not sure "Ecma" is the preferred spelling).
>>=20
>>> Intended usage : Common
>>=20
>> This should be spelled COMMON.
>>=20
>> I note that per RFC 4288 section 4.10:
>>=20
>> As stated previously, standards tree registrations for media types =20=

>> defined in documents produced by other standards bodies MUST be =20
>> described by a formal standards specification produced by that body.
>> Such specifications MUST contain an appropriate media type =20
>> registration template taken from Section 10.  Additionally, the =20
>> copyright on the registration template MUST allow the IANA to copy it =
=20
>> into the IANA registry.
>>=20
>> 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=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20
>> http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: =
+49(0)160/4415681=20
>> =B7 http://www.bjoernsworld.de
>> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20
>> http://www.websitedev.de/
>>=20
>> <MIMEReg.txt>_______________________________________________
>> ietf-types mailing list
>> ietf-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-types
>=20
>=20
> <MIMEReg.txt>



Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 166EFE073A for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 09:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.524
X-Spam-Level: 
X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cst4t8v668BI for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 09:30:54 -0700 (PDT)
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfc.amsl.com (Postfix) with ESMTP id 8DC0DE0655 for <ietf-types@ietf.org>; Thu, 21 Apr 2011 09:30:53 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3LGUDoJ022905 for <ietf-types@iana.org>; Thu, 21 Apr 2011 12:30:33 -0400
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 09:30:12 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 09:30:12 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 21 Apr 2011 09:30:11 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Paul Libbrecht <paul@hoplahup.net>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAuzKiAAAN+U7w//+bEQD//W5rEIAFog+AgAB0x6A=
Date: Thu, 21 Apr 2011 16:30:11 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172FCDED@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <8F525887-A607-4334-926D-700DDA0102A9@hoplahup.net>
In-Reply-To: <8F525887-A607-4334-926D-700DDA0102A9@hoplahup.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/mixed; boundary="_002_FE6603D65048F44AB8F8955AE89A09B9172FCDEDTK5EX14MBXW651w_"
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Thu, 21 Apr 2011 12:30:34 -0400 (EDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 16:30:56 -0000

--_002_FE6603D65048F44AB8F8955AE89A09B9172FCDEDTK5EX14MBXW651w_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 se=
ction.  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 Typ=
e Identifier" in the prescribed template.

Edited template is attached and provided below.

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:
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=20

and untrusted ZIP data.  The consumer is responsible for validating the .zi=
p archive, the XML structure, and the resource content.  Per spec, there sh=
ould be no active content=20

provided as part of the OpenXPS format.  The consumer must ensure that no m=
alicious active content is erroneously provided in the OpenXPS document.  V=
alid content is described=20

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

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 conten=
t cannot directly produce/consume OpenXPS.  Changes are required to address=
 differences in the two=20

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:
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 ca=
n currently=20

produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such appl=
ications would include but are not limited to:  Microsoft XPS Viewer, Micro=
soft XPS Document Writer,=20

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=20

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-ar=
chive

Person & email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

Intended usage: COMMON


Restrictions on usage:  N/A


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

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

-----Original Message-----
From: Paul Libbrecht [mailto:paul@hoplahup.net]=20
Sent: Thursday, April 21, 2011 9:20 AM
To: Brian Clubb
Cc: Bjoern Hoehrmann; Pete Resnick; ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

Brian,

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

Have I missed a bit of discussion about this?

paul

Le 21 avr. 2011 =E0 17:47, Brian Clubb a =E9crit :

> Bjoern,
>=20
> Thanks for the feedback!
>=20
> 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 "E=
cma Technical Committee TC46" but the specification is "ECMA-388".
>=20
> The current ECMA-388 specification is due for editorial reviews and updat=
es this year.  I will make sure that the approved template is in that revis=
ion.
>=20
> Let me know if there is anything else.  I have attached the revised templ=
ate and provided it below as well.
>=20
> Thanks!
> Brian
>=20
> <template>
> Type name: application/OpenXPS
>=20
> Subtype name:  Standards Tree - OpenXPS
>=20
> Required parameters:  N/A
>=20
> Optional parameters:  N/A
>=20
> Encoding considerations:  binary
>=20
> Security considerations:
> OpenXPS uses ZIP compression as specified in .ZIP File Format Specificati=
on from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires pa=
rsing untrusted XML data and untrusted ZIP data.  The consumer is responsib=
le for validating the .zip archive, the XML structure, and the resource con=
tent.  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 describe=
d in the EMCA-388 specification (http://www.ecma-international.org/publicat=
ions/standards/Ecma-388.htm).  Especially take note of section E.3, which d=
escribes steps that can be taken to validate the contents of the payload.
>=20
>=20
> Interoperability considerations:
> application/OpenXPS documents are specified by the XML schemas standardiz=
ed in ECMA-388.
> Applications and drivers currently producing/consuming Microsoft XPS cont=
ent cannot directly produce/consume OpenXPS.  Changes are required to addre=
ss differences in the two specifications, such as namespace, print ticket u=
sage, use of JPEG XR, etc.
>=20
> Published specification:
> The published standard ECMA-388 is available at:
> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>=20
> 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 driver=
s currently use OpenXPS.  The intent is for any application or driver that =
can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Example=
s of such applications would include but are not limited to:  Microsoft XPS=
 Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.
>=20
> Additional information:
>=20
>  Magic number(s):  ZIP archive CRC-32: 504b 0304 per http://www.pkware.co=
m/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of th=
e consumer to ensure that the contents of the ZIP archive is a valid OpenXP=
S structure.
>  File extension(s): .oxps
>  Macintosh file type code(s):  org.ecma.oxps conforms to=20
> com.pkware.zip-archive
>=20
> Person & email address to contact for further information:
>=20
> Ecma International Helpdesk
> Rue du Rhone 114
> CH-1204 Geneva
> Switzerland
> Ecma International Helpdesk<helpdesk@ecma-international.org>
>=20
> Intended usage: COMMON
>=20
>=20
> Restrictions on usage:  N/A
>=20
>=20
> Author:  The ECMA-388 Standard is developed and maintained by the Ecma Te=
chnical Committee TC46.
>=20
> Change controller:  The ECMA-388 Standard is developed and maintained by =
the Ecma Technical Committee TC46.
> </template
>=20
>=20
> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> Sent: Tuesday, April 19, 2011 10:32 AM
> To: Brian Clubb
> Cc: Pete Resnick; ietf-types@iana.org
> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME=20
> type
>=20
> * Brian Clubb wrote:
>> <template>
>> Name : Brian Clubb
>>=20
>> Email : bclubb@microsoft.com
>>=20
>> MIME media type name : application
>>=20
>> MIME subtype name : Standards Tree - OpenXPS
>=20
> You are using an outdated template; the current one is specified in RFC 4=
288. It uses different names for some of the fields and distributes the pie=
ces of information differently.
>=20
>> Required parameters : N/A
>>=20
>> Optional parameters :N/A
>>=20
>> Encoding considerations : 8-bit
>=20
> It seems this should be "binary", see the definitions in RFC 4288.
>=20
>> Person to contact for further information :
>>=20
>> 1. Name : Ecma International Helpdesk 2. Email :=20
>> helpdesk@ecma-international.org
>=20
> It is customary to write this as
>=20
>  Ecma International Helpdesk <helpdesk@ecma-international.org>
>=20
> (And I am not sure "Ecma" is the preferred spelling).
>=20
>> Intended usage : Common
>=20
> This should be spelled COMMON.
>=20
> I note that per RFC 4288 section 4.10:
>=20
>  As stated previously, standards tree registrations for media types =20
> defined in documents produced by other standards bodies MUST be =20
> described by a formal standards specification produced by that body.
>  Such specifications MUST contain an appropriate media type =20
> registration template taken from Section 10.  Additionally, the =20
> copyright on the registration template MUST allow the IANA to copy it =20
> into the IANA registry.
>=20
> 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=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20
> http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681=
=20
> =B7 http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20
> http://www.websitedev.de/
>=20
> <MIMEReg.txt>_______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types



--_002_FE6603D65048F44AB8F8955AE89A09B9172FCDEDTK5EX14MBXW651w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=2910;
	creation-date="Wed, 20 Apr 2011 16:58:49 GMT";
	modification-date="Thu, 21 Apr 2011 16:29:22 GMT"
Content-Transfer-Encoding: base64

VHlwZSBuYW1lOiBhcHBsaWNhdGlvbi9PcGVuWFBTDQoNClN1YnR5cGUgbmFtZTogIFN0YW5kYXJk
cyBUcmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzOiAgTi9BDQoNCk9wdGlvbmFs
IHBhcmFtZXRlcnM6ICBOL0ENCg0KRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6ICBiaW5hcnkNCg0K
U2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQpPcGVuWFBTIHVzZXMgWklQIGNvbXByZXNzaW9uIGFz
IHNwZWNpZmllZCBpbiAuWklQIEZpbGUgRm9ybWF0IFNwZWNpZmljYXRpb24gZnJvbSBQS1dBUkUs
IEluYy4sIHZlcnNpb24gNi4yLjAgKDIwMDQpLiAgWklQIGNvbXByZXNzZWQgWE1MIHJlcXVpcmVz
IHBhcnNpbmcgdW50cnVzdGVkIFhNTCBkYXRhIGFuZCB1bnRydXN0ZWQgWklQIGRhdGEuICBUaGUg
Y29uc3VtZXIgaXMgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhlIC56aXAgYXJjaGl2ZSwg
dGhlIFhNTCBzdHJ1Y3R1cmUsIGFuZCB0aGUgcmVzb3VyY2UgY29udGVudC4gIFBlciBzcGVjLCB0
aGVyZSBzaG91bGQgYmUgbm8gYWN0aXZlIGNvbnRlbnQgcHJvdmlkZWQgYXMgcGFydCBvZiB0aGUg
T3BlblhQUyBmb3JtYXQuICBUaGUgY29uc3VtZXIgbXVzdCBlbnN1cmUgdGhhdCBubyBtYWxpY2lv
dXMgYWN0aXZlIGNvbnRlbnQgaXMgZXJyb25lb3VzbHkgcHJvdmlkZWQgaW4gdGhlIE9wZW5YUFMg
ZG9jdW1lbnQuICBWYWxpZCBjb250ZW50IGlzIGRlc2NyaWJlZCBpbiB0aGUgRU1DQS0zODggc3Bl
Y2lmaWNhdGlvbiAoaHR0cDovL3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL3B1YmxpY2F0aW9u
cy9zdGFuZGFyZHMvRWNtYS0zODguaHRtKS4gIEVzcGVjaWFsbHkgdGFrZSBub3RlIG9mIHNlY3Rp
b24gRS4zLCB3aGljaCBkZXNjcmliZXMgc3RlcHMgdGhhdCBjYW4gYmUgdGFrZW4gdG8gdmFsaWRh
dGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBwYXlsb2FkLg0KDQoNCkludGVyb3BlcmFiaWxpdHkgY29u
c2lkZXJhdGlvbnM6DQphcHBsaWNhdGlvbi9PcGVuWFBTIGRvY3VtZW50cyBhcmUgc3BlY2lmaWVk
IGJ5IHRoZSBYTUwgc2NoZW1hcyBzdGFuZGFyZGl6ZWQgaW4gRUNNQS0zODguDQpBcHBsaWNhdGlv
bnMgYW5kIGRyaXZlcnMgY3VycmVudGx5IHByb2R1Y2luZy9jb25zdW1pbmcgTWljcm9zb2Z0IFhQ
UyBjb250ZW50IGNhbm5vdCBkaXJlY3RseSBwcm9kdWNlL2NvbnN1bWUgT3BlblhQUy4gIENoYW5n
ZXMgYXJlIHJlcXVpcmVkIHRvIGFkZHJlc3MgZGlmZmVyZW5jZXMgaW4gdGhlIHR3byBzcGVjaWZp
Y2F0aW9ucywgc3VjaCBhcyBuYW1lc3BhY2UsIHByaW50IHRpY2tldCB1c2FnZSwgdXNlIG9mIEpQ
RUcgWFIsIGV0Yy4NCg0KVG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHksIHRoZSBjbGlwYm9hcmQg
Zm9ybWF0IG11c3QgYmUgYSBjb21wbGV0ZSBPcGVuWFBTIGZpbGUgd2l0aCAub3hwcyBleHRlbnNp
b24uDQoNClB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOg0KVGhlIHB1Ymxpc2hlZCBzdGFuZGFyZCBF
Q01BLTM4OCBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5v
cmcvcHVibGljYXRpb25zL3N0YW5kYXJkcy9FY21hLTM4OC5odG0NCg0KQXBwbGljYXRpb25zIHRo
YXQgdXNlIHRoaXMgbWVkaWEgdHlwZToNClRoZSBhcHBsaWNhdGlvbi9PcGVuWFBTIE1JTUUgdHlw
ZSBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSBDU1RBIFhNTA0KKEVDTUEtMzg4KSBpbnN0YW5jZSBk
b2N1bWVudHMuICBObyBwdWJsaXNoZWQgYXBwbGljYXRpb25zIG9yIHByaW50IGRyaXZlcnMgY3Vy
cmVudGx5IHVzZSBPcGVuWFBTLiAgVGhlIGludGVudCBpcyBmb3IgYW55IGFwcGxpY2F0aW9uIG9y
IGRyaXZlciB0aGF0IGNhbiBjdXJyZW50bHkgcHJvZHVjZS9jb25zdW1lIE1pY3Jvc29mdCBYUFMg
dG8gYWxzbyBhZG9wdCBPcGVuWFBTLiAgRXhhbXBsZXMgb2Ygc3VjaCBhcHBsaWNhdGlvbnMgd291
bGQgaW5jbHVkZSBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOiAgTWljcm9zb2Z0IFhQUyBWaWV3ZXIs
IE1pY3Jvc29mdCBYUFMgRG9jdW1lbnQgV3JpdGVyLCBNaWNyb3NvZnQgSW50ZXJuZXQgRXhwbG9y
ZXIgOS4NCg0KQWRkaXRpb25hbCBpbmZvcm1hdGlvbjoNCg0KICBNYWdpYyBudW1iZXIocyk6ICBa
SVAgYXJjaGl2ZSBDUkMtMzI6IDUwNGIgMDMwNCBwZXIgaHR0cDovL3d3dy5wa3dhcmUuY29tL2Rv
Y3VtZW50cy9BUFBOT1RFL0FQUE5PVEUtNi4yLjAudHh0LiAgTm90ZSB0aGF0IGlzIGl0IGEgcmVx
dWlyZW1lbnQgb2YgdGhlIGNvbnN1bWVyIHRvIGVuc3VyZSB0aGF0IHRoZSBjb250ZW50cyBvZiB0
aGUgWklQIGFyY2hpdmUgaXMgYSB2YWxpZCBPcGVuWFBTIHN0cnVjdHVyZS4NCiAgRmlsZSBleHRl
bnNpb24ocyk6IC5veHBzDQogIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZShzKTogIG9yZy5lY21h
Lm94cHMgY29uZm9ybXMgdG8gY29tLnBrd2FyZS56aXAtYXJjaGl2ZQ0KDQpQZXJzb24gJiBlbWFp
bCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246DQoNCkVjbWEgSW50
ZXJuYXRpb25hbCBIZWxwZGVzaw0KUnVlIGR1IFJob25lIDExNA0KQ0gtMTIwNCBHZW5ldmENClN3
aXR6ZXJsYW5kDQpFY21hIEludGVybmF0aW9uYWwgSGVscGRlc2s8aGVscGRlc2tAZWNtYS1pbnRl
cm5hdGlvbmFsLm9yZz4NCg0KSW50ZW5kZWQgdXNhZ2U6IENPTU1PTg0KDQoNClJlc3RyaWN0aW9u
cyBvbiB1c2FnZTogIE4vQQ0KDQoNCkF1dGhvcjogIFRoZSBFQ01BLTM4OCBTdGFuZGFyZCBpcyBk
ZXZlbG9wZWQgYW5kIG1haW50YWluZWQgYnkgdGhlIEVjbWEgVGVjaG5pY2FsIENvbW1pdHRlZSBU
QzQ2Lg0KDQpDaGFuZ2UgY29udHJvbGxlcjogIFRoZSBFQ01BLTM4OCBTdGFuZGFyZCBpcyBkZXZl
bG9wZWQgYW5kIG1haW50YWluZWQgYnkgdGhlIEVjbWEgVGVjaG5pY2FsIENvbW1pdHRlZSBUQzQ2
Lg0K

--_002_FE6603D65048F44AB8F8955AE89A09B9172FCDEDTK5EX14MBXW651w_--


Return-Path: <paul@hoplahup.net>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6567AE065C for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 09:20:54 -0700 (PDT)
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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2vDrE8OGvH2 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 09:20:53 -0700 (PDT)
Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfc.amsl.com (Postfix) with ESMTP id C82FEE0663 for <ietf-types@ietf.org>; Thu, 21 Apr 2011 09:20:51 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3LGKEHw023742 for <ietf-types@iana.org>; Thu, 21 Apr 2011 09:20:35 -0700
Received: from [192.168.178.47] (srbk-4db7fa50.pool.mediaWays.net [77.183.250.80]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0M3jZR-1Pvgm93RlB-00rEzk; Thu, 21 Apr 2011 18:20:09 +0200
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: <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 21 Apr 2011 18:20:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F525887-A607-4334-926D-700DDA0102A9@hoplahup.net>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de> <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
To: Brian Clubb <Brian.Clubb@microsoft.com>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:DTFB4pXwZ5osxFZPRh1JDitN959T/K2hWKoJLgG6k1/ vbVITCmshz1FhmUdf6U6PKmLE3/ib+6VtvYy1dtQ3tO6c6Z20b MfUaXunkL4paIe+n7qPn40dYg5T8+JLlstmqMdfHM4vTBCFM7B znCVhagBh6KwCCTYnfZh9rSNKUEPv8h7nKX3uK72NMxjn3QNPa dTb5FvQbD3B4miJITMYHb+qIAKo58EiBJTv7RqyBwU=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Thu, 21 Apr 2011 09:20:36 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 16:20:54 -0000

Brian,

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

Have I missed a bit of discussion about this?

paul

Le 21 avr. 2011 =E0 17:47, Brian Clubb a =E9crit :

> Bjoern,
>=20
> Thanks for the feedback!
>=20
> 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".
>=20
> 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.
>=20
> Let me know if there is anything else.  I have attached the revised =
template and provided it below as well.
>=20
> Thanks!
> Brian
>=20
> <template>
> Type name: application/OpenXPS
>=20
> Subtype name:  Standards Tree - OpenXPS
>=20
> Required parameters:  N/A
>=20
> Optional parameters:  N/A
>=20
> Encoding considerations:  binary
>=20
> 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.
>=20
>=20
> 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.
>=20
> Published specification:
> The published standard ECMA-388 is available at:
> http://www.ecma-international.org/publications/standards/Ecma-388.htm
>=20
> 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.
>=20
> Additional information:
>=20
>  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
>=20
> Person & email address to contact for further information:
>=20
> Ecma International Helpdesk
> Rue du Rhone 114
> CH-1204 Geneva
> Switzerland
> Ecma International Helpdesk<helpdesk@ecma-international.org>
>=20
> Intended usage: COMMON
>=20
>=20
> Restrictions on usage:  N/A
>=20
>=20
> Author:  The ECMA-388 Standard is developed and maintained by the Ecma =
Technical Committee TC46.
>=20
> Change controller:  The ECMA-388 Standard is developed and maintained =
by the Ecma Technical Committee TC46.
> </template
>=20
>=20
> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]=20
> Sent: Tuesday, April 19, 2011 10:32 AM
> To: Brian Clubb
> Cc: Pete Resnick; ietf-types@iana.org
> Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME =
type
>=20
> * Brian Clubb wrote:
>> <template>
>> Name : Brian Clubb
>>=20
>> Email : bclubb@microsoft.com
>>=20
>> MIME media type name : application
>>=20
>> MIME subtype name : Standards Tree - OpenXPS
>=20
> 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.
>=20
>> Required parameters : N/A
>>=20
>> Optional parameters :N/A
>>=20
>> Encoding considerations : 8-bit
>=20
> It seems this should be "binary", see the definitions in RFC 4288.
>=20
>> Person to contact for further information :
>>=20
>> 1. Name : Ecma International Helpdesk
>> 2. Email : helpdesk@ecma-international.org
>=20
> It is customary to write this as
>=20
>  Ecma International Helpdesk <helpdesk@ecma-international.org>
>=20
> (And I am not sure "Ecma" is the preferred spelling).
>=20
>> Intended usage : Common
>=20
> This should be spelled COMMON.
>=20
> I note that per RFC 4288 section 4.10:
>=20
>  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.
>=20
> 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=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 =
http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =
=B7 http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/=20
>=20
> <MIMEReg.txt>_______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types



Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF7E4E07B0 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 08:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.832
X-Spam-Level: 
X-Spam-Status: No, score=-7.832 tagged_above=-999 required=5 tests=[AWL=2.767,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HGqGm+xtH+2 for <ietf-types@ietfc.amsl.com>; Thu, 21 Apr 2011 08:48:06 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by ietfc.amsl.com (Postfix) with ESMTP id 8995EE078A for <ietf-types@ietf.org>; Thu, 21 Apr 2011 08:48:05 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3LFliOQ024776 for <ietf-types@iana.org>; Thu, 21 Apr 2011 08:48:04 -0700
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 21 Apr 2011 08:47:43 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 21 Apr 2011 08:47:43 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 21 Apr 2011 08:47:42 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAuzKiAAAN+U7w//+bEQD//W5rEA==
Date: Thu, 21 Apr 2011 15:47:42 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172FCD62@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de>
In-Reply-To: <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/mixed; boundary="_002_FE6603D65048F44AB8F8955AE89A09B9172FCD62TK5EX14MBXW651w_"
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]); Thu, 21 Apr 2011 08:48:04 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Apr 2011 15:48:08 -0000

--_002_FE6603D65048F44AB8F8955AE89A09B9172FCD62TK5EX14MBXW651w_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 "Ecm=
a 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 revisio=
n.

Let me know if there is anything else.  I have attached the revised templat=
e 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:
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.  The consumer is responsible=
 for validating the .zip archive, the XML structure, and the resource conte=
nt.  Per spec, there should be no active content provided as part of the Op=
enXPS 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/publicatio=
ns/standards/Ecma-388.htm).  Especially take note of section E.3, which des=
cribes 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 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 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 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:

  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-ar=
chive

Person & email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

Intended usage: COMMON


Restrictions on usage:  N/A


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

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


-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]=20
Sent: Tuesday, April 19, 2011 10:32 AM
To: Brian Clubb
Cc: Pete Resnick; ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

* Brian Clubb wrote:
><template>
>Name : Brian Clubb
>
>Email : bclubb@microsoft.com
>
>MIME media type name : application
>
>MIME subtype name : Standards Tree - OpenXPS

You are using an outdated template; the current one is specified in RFC 428=
8. It uses different names for some of the fields and distributes the piece=
s of information differently.

>Required parameters : N/A
>
>Optional parameters :N/A
>
>Encoding considerations : 8-bit

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

>Person to contact for further information :
>
>1. Name : Ecma International Helpdesk
>2. Email : helpdesk@ecma-international.org

It is customary to write this as

  Ecma International Helpdesk <helpdesk@ecma-international.org>

(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 a=
t the moment, should we expect the specification to be revised to include i=
t "soon"?
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma=
nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsw=
orld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d=
e/=20


--_002_FE6603D65048F44AB8F8955AE89A09B9172FCD62TK5EX14MBXW651w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=2804;
	creation-date="Wed, 20 Apr 2011 16:58:49 GMT";
	modification-date="Wed, 20 Apr 2011 17:25:10 GMT"
Content-Transfer-Encoding: base64

VHlwZSBuYW1lOiBhcHBsaWNhdGlvbi9PcGVuWFBTDQoNClN1YnR5cGUgbmFtZTogIFN0YW5kYXJk
cyBUcmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzOiAgTi9BDQoNCk9wdGlvbmFs
IHBhcmFtZXRlcnM6ICBOL0ENCg0KRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6ICBiaW5hcnkNCg0K
U2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQpPcGVuWFBTIHVzZXMgWklQIGNvbXByZXNzaW9uIGFz
IHNwZWNpZmllZCBpbiAuWklQIEZpbGUgRm9ybWF0IFNwZWNpZmljYXRpb24gZnJvbSBQS1dBUkUs
IEluYy4sIHZlcnNpb24gNi4yLjAgKDIwMDQpLiAgWklQIGNvbXByZXNzZWQgWE1MIHJlcXVpcmVz
IHBhcnNpbmcgdW50cnVzdGVkIFhNTCBkYXRhIGFuZCB1bnRydXN0ZWQgWklQIGRhdGEuICBUaGUg
Y29uc3VtZXIgaXMgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhlIC56aXAgYXJjaGl2ZSwg
dGhlIFhNTCBzdHJ1Y3R1cmUsIGFuZCB0aGUgcmVzb3VyY2UgY29udGVudC4gIFBlciBzcGVjLCB0
aGVyZSBzaG91bGQgYmUgbm8gYWN0aXZlIGNvbnRlbnQgcHJvdmlkZWQgYXMgcGFydCBvZiB0aGUg
T3BlblhQUyBmb3JtYXQuICBUaGUgY29uc3VtZXIgbXVzdCBlbnN1cmUgdGhhdCBubyBtYWxpY2lv
dXMgYWN0aXZlIGNvbnRlbnQgaXMgZXJyb25lb3VzbHkgcHJvdmlkZWQgaW4gdGhlIE9wZW5YUFMg
ZG9jdW1lbnQuICBWYWxpZCBjb250ZW50IGlzIGRlc2NyaWJlZCBpbiB0aGUgRU1DQS0zODggc3Bl
Y2lmaWNhdGlvbiAoaHR0cDovL3d3dy5lY21hLWludGVybmF0aW9uYWwub3JnL3B1YmxpY2F0aW9u
cy9zdGFuZGFyZHMvRWNtYS0zODguaHRtKS4gIEVzcGVjaWFsbHkgdGFrZSBub3RlIG9mIHNlY3Rp
b24gRS4zLCB3aGljaCBkZXNjcmliZXMgc3RlcHMgdGhhdCBjYW4gYmUgdGFrZW4gdG8gdmFsaWRh
dGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBwYXlsb2FkLg0KDQoNCkludGVyb3BlcmFiaWxpdHkgY29u
c2lkZXJhdGlvbnM6DQphcHBsaWNhdGlvbi9PcGVuWFBTIGRvY3VtZW50cyBhcmUgc3BlY2lmaWVk
IGJ5IHRoZSBYTUwgc2NoZW1hcyBzdGFuZGFyZGl6ZWQgaW4gRUNNQS0zODguDQpBcHBsaWNhdGlv
bnMgYW5kIGRyaXZlcnMgY3VycmVudGx5IHByb2R1Y2luZy9jb25zdW1pbmcgTWljcm9zb2Z0IFhQ
UyBjb250ZW50IGNhbm5vdCBkaXJlY3RseSBwcm9kdWNlL2NvbnN1bWUgT3BlblhQUy4gIENoYW5n
ZXMgYXJlIHJlcXVpcmVkIHRvIGFkZHJlc3MgZGlmZmVyZW5jZXMgaW4gdGhlIHR3byBzcGVjaWZp
Y2F0aW9ucywgc3VjaCBhcyBuYW1lc3BhY2UsIHByaW50IHRpY2tldCB1c2FnZSwgdXNlIG9mIEpQ
RUcgWFIsIGV0Yy4NCg0KUHVibGlzaGVkIHNwZWNpZmljYXRpb246DQpUaGUgcHVibGlzaGVkIHN0
YW5kYXJkIEVDTUEtMzg4IGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuZWNtYS1pbnRlcm5h
dGlvbmFsLm9yZy9wdWJsaWNhdGlvbnMvc3RhbmRhcmRzL0VjbWEtMzg4Lmh0bQ0KDQpBcHBsaWNh
dGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBlOg0KVGhlIGFwcGxpY2F0aW9uL09wZW5YUFMg
TUlNRSB0eXBlIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IENTVEEgWE1MDQooRUNNQS0zODgpIGlu
c3RhbmNlIGRvY3VtZW50cy4gIE5vIHB1Ymxpc2hlZCBhcHBsaWNhdGlvbnMgb3IgcHJpbnQgZHJp
dmVycyBjdXJyZW50bHkgdXNlIE9wZW5YUFMuICBUaGUgaW50ZW50IGlzIGZvciBhbnkgYXBwbGlj
YXRpb24gb3IgZHJpdmVyIHRoYXQgY2FuIGN1cnJlbnRseSBwcm9kdWNlL2NvbnN1bWUgTWljcm9z
b2Z0IFhQUyB0byBhbHNvIGFkb3B0IE9wZW5YUFMuICBFeGFtcGxlcyBvZiBzdWNoIGFwcGxpY2F0
aW9ucyB3b3VsZCBpbmNsdWRlIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86ICBNaWNyb3NvZnQgWFBT
IFZpZXdlciwgTWljcm9zb2Z0IFhQUyBEb2N1bWVudCBXcml0ZXIsIE1pY3Jvc29mdCBJbnRlcm5l
dCBFeHBsb3JlciA5Lg0KDQpBZGRpdGlvbmFsIGluZm9ybWF0aW9uOg0KDQogIE1hZ2ljIG51bWJl
cihzKTogIFpJUCBhcmNoaXZlIENSQy0zMjogNTA0YiAwMzA0IHBlciBodHRwOi8vd3d3LnBrd2Fy
ZS5jb20vZG9jdW1lbnRzL0FQUE5PVEUvQVBQTk9URS02LjIuMC50eHQuICBOb3RlIHRoYXQgaXMg
aXQgYSByZXF1aXJlbWVudCBvZiB0aGUgY29uc3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbnRl
bnRzIG9mIHRoZSBaSVAgYXJjaGl2ZSBpcyBhIHZhbGlkIE9wZW5YUFMgc3RydWN0dXJlLg0KICBG
aWxlIGV4dGVuc2lvbihzKTogLm94cHMNCiAgTWFjaW50b3NoIGZpbGUgdHlwZSBjb2RlKHMpOiAg
b3JnLmVjbWEub3hwcyBjb25mb3JtcyB0byBjb20ucGt3YXJlLnppcC1hcmNoaXZlDQoNClBlcnNv
biAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoNCg0K
RWNtYSBJbnRlcm5hdGlvbmFsIEhlbHBkZXNrDQpSdWUgZHUgUmhvbmUgMTE0DQpDSC0xMjA0IEdl
bmV2YQ0KU3dpdHplcmxhbmQNCkVjbWEgSW50ZXJuYXRpb25hbCBIZWxwZGVzazxoZWxwZGVza0Bl
Y21hLWludGVybmF0aW9uYWwub3JnPg0KDQpJbnRlbmRlZCB1c2FnZTogQ09NTU9ODQoNCg0KUmVz
dHJpY3Rpb25zIG9uIHVzYWdlOiAgTi9BDQoNCg0KQXV0aG9yOiAgVGhlIEVDTUEtMzg4IFN0YW5k
YXJkIGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgRWNtYSBUZWNobmljYWwgQ29t
bWl0dGVlIFRDNDYuDQoNCkNoYW5nZSBjb250cm9sbGVyOiAgVGhlIEVDTUEtMzg4IFN0YW5kYXJk
IGlzIGRldmVsb3BlZCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgRWNtYSBUZWNobmljYWwgQ29tbWl0
dGVlIFRDNDYuDQo=

--_002_FE6603D65048F44AB8F8955AE89A09B9172FCD62TK5EX14MBXW651w_--


Return-Path: <peaceable_whale@hotmail.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B48BBE0856 for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 11:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or7dBwydzIRn for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 11:19:03 -0700 (PDT)
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfc.amsl.com (Postfix) with ESMTP id B4F31E0685 for <ietf-types@ietf.org>; Tue, 19 Apr 2011 11:19:01 -0700 (PDT)
Received: from col0-omc3-s14.col0.hotmail.com (col0-omc3-s14.col0.hotmail.com [65.55.34.152]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3JIIPNv031388 for <ietf-types@iana.org>; Tue, 19 Apr 2011 14:18:45 -0400
Received: from COL122-DS9 ([65.55.34.136]) by col0-omc3-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 19 Apr 2011 11:02:33 -0700
X-Originating-IP: [14.136.19.151]
X-Originating-Email: [peaceable_whale@hotmail.com]
Message-ID: <COL122-DS96480FC5657B91371601D9F900@phx.gbl>
From: "Franklin Tse" <peaceable_whale@hotmail.com>
To: "Brian Clubb" <Brian.Clubb@microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com><4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Date: Wed, 20 Apr 2011 02:02:29 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 14.0.8117.416
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
X-OriginalArrivalTime: 19 Apr 2011 18:02:33.0334 (UTC) FILETIME=[F505F960:01CBFEBB]
X-Greylist: Delayed for 00:15:51 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Tue, 19 Apr 2011 14:18:46 -0400 (EDT)
Cc: ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Apr 2011 18:19:03 -0000

RGVhciBCcmlhbiwNCg0KPiBQZXJzb24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1
cnRoZXIgaW5mb3JtYXRpb246DQo+IEVjbWEgSW50ZXJuYXRpb25hbCBIZWxwZGVzaw0KPiBSdWUg
ZHUgUmhvbmUxMTQNCj4gQ0gtMTIwNCBHZW5ldmENCj4gU3dpdHplcmxhbmQNCj4gaGVscGRlc2tA
ZWNtYS1pbnRlcm5hdGlvbmFsLm9yZzxtYWlsdG86aGVscGRlc2tAZWNtYS1pbnRlcm5hdGlvbmFs
Lm9yZz4NCj4gDQo+IFBlcnNvbiB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uIDoN
Cj4gDQo+IDEuIE5hbWUgOiBFY21hIEludGVybmF0aW9uYWwgSGVscGRlc2sNCj4gMi4gRW1haWwg
OiBoZWxwZGVza0BlY21hLWludGVybmF0aW9uYWwub3JnPG1haWx0bzpoZWxwZGVza0BlY21hLWlu
dGVybmF0aW9uYWwub3JnPg0KPiANCj4gSXMgdGhhdCBpbnRlbmRlZCB0byBiZSBkdXBsaWNhdGVk
Pw0KPiBbYmNsdWJiXSAgWWVzLCB0aGUgZHVwbGljYXRpb24gaXMgaW50ZW50aW9uYWwuDQoNClRo
ZSBkdXBsaWNhdGlvbiBzZWVtcyBub3QgbmVjZXNzYXJ5LiBXaHkgd2FzIGl0IGludGVuZGVkPw0K
DQpSZWdhcmRzLA0KRnJhbmtsaW4gVHNlIA==



Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ABF04E07FB for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 11:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=4.151,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQHKuNezNAia for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 11:09:16 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by ietfc.amsl.com (Postfix) with ESMTP id 56AEBE0685 for <ietf-types@ietf.org>; Tue, 19 Apr 2011 11:09:16 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3JI8t6Y005107 for <ietf-types@iana.org>; Tue, 19 Apr 2011 11:09:15 -0700
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Apr 2011 11:08:55 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 19 Apr 2011 11:08:54 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Tue, 19 Apr 2011 11:08:54 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Franklin Tse <peaceable_whale@hotmail.com>, "Pete Resnick (presnick@qualcomm.com)" <presnick@qualcomm.com>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAvZtkgAAOmNiw
Date: Tue, 19 Apr 2011 18:08:53 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172FA8C9@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com><4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <COL122-DS96480FC5657B91371601D9F900@phx.gbl>
In-Reply-To: <COL122-DS96480FC5657B91371601D9F900@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/mixed; boundary="_002_FE6603D65048F44AB8F8955AE89A09B9172FA8C9TK5EX14MBXW651w_"
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, 19 Apr 2011 11:09:15 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Apr 2011 18:09:17 -0000

--_002_FE6603D65048F44AB8F8955AE89A09B9172FA8C9TK5EX14MBXW651w_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U29ycnksIHdoZW4gSSBmaXJzdCBzYXcgdGhlIHF1ZXN0aW9uIGFib3V0IHRoZSBkdXBsaWNhdGlv
biBJIHRob3VnaHQgdGhlIHF1ZXN0aW9uIHdhcyBvbiB0aGUgZS1tYWlsIGFkZHJlc3MgcHJvdmlk
ZWQsIEkgbWlzc2VkIHRoZSB0aXRsZSB3YXMgZHVwbGljYXRlZCBhcyB3ZWxsLiAgWWVzLCB0aGlz
IHNob3VsZCBiZSBzdHJ1Y2suICBJIGhhdmUgYXR0YWNoZWQgdGhlIHVwZGF0ZWQgdGVtcGxhdGUg
d2l0aG91dCB0aGUgZHVwbGljYXRlZCBzZWN0aW9uLg0KDQpUaGFua3MhDQpCcmlhbg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRnJhbmtsaW4gVHNlIFttYWlsdG86cGVhY2Vh
YmxlX3doYWxlQGhvdG1haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE5LCAyMDExIDEx
OjAyIEFNDQpUbzogQnJpYW4gQ2x1YmINCkNjOiBpZXRmLXR5cGVzQGlhbmEub3JnDQpTdWJqZWN0
OiBSZTogW2lldGYtdHlwZXNdIFJlcXVlc3QgZm9yIGZpbmFsIGFwcHJvdmFsIGZvciBPcGVuWFBT
IE1JTUUgdHlwZQ0KDQpEZWFyIEJyaWFuLA0KDQo+IFBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8g
Y29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoNCj4gRWNtYSBJbnRlcm5hdGlvbmFsIEhl
bHBkZXNrDQo+IFJ1ZSBkdSBSaG9uZTExNA0KPiBDSC0xMjA0IEdlbmV2YQ0KPiBTd2l0emVybGFu
ZA0KPiBoZWxwZGVza0BlY21hLWludGVybmF0aW9uYWwub3JnPG1haWx0bzpoZWxwZGVza0BlY21h
LWludGVybmF0aW9uYWwub3JnPg0KPiANCj4gUGVyc29uIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIg
aW5mb3JtYXRpb24gOg0KPiANCj4gMS4gTmFtZSA6IEVjbWEgSW50ZXJuYXRpb25hbCBIZWxwZGVz
aw0KPiAyLiBFbWFpbCA6IGhlbHBkZXNrQGVjbWEtaW50ZXJuYXRpb25hbC5vcmc8bWFpbHRvOmhl
bHBkZXNrQGVjbWEtaW50ZXJuYXRpb25hbC5vcmc+DQo+IA0KPiBJcyB0aGF0IGludGVuZGVkIHRv
IGJlIGR1cGxpY2F0ZWQ/DQo+IFtiY2x1YmJdICBZZXMsIHRoZSBkdXBsaWNhdGlvbiBpcyBpbnRl
bnRpb25hbC4NCg0KVGhlIGR1cGxpY2F0aW9uIHNlZW1zIG5vdCBuZWNlc3NhcnkuIFdoeSB3YXMg
aXQgaW50ZW5kZWQ/DQoNClJlZ2FyZHMsDQpGcmFua2xpbiBUc2UgDQo=

--_002_FE6603D65048F44AB8F8955AE89A09B9172FA8C9TK5EX14MBXW651w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=3070;
	creation-date="Tue, 19 Apr 2011 18:06:28 GMT";
	modification-date="Tue, 19 Apr 2011 18:07:02 GMT"
Content-Transfer-Encoding: base64

TmFtZSA6IEJyaWFuIENsdWJiDQoNCkVtYWlsIDogYmNsdWJiQG1pY3Jvc29mdC5jb20NCg0KTUlN
RSBtZWRpYSB0eXBlIG5hbWUgOiBhcHBsaWNhdGlvbg0KDQpNSU1FIHN1YnR5cGUgbmFtZSA6IFN0
YW5kYXJkcyBUcmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzIDogTi9BDQoNCg0K
T3B0aW9uYWwgcGFyYW1ldGVycyA6DQpOL0ENCg0KDQpFbmNvZGluZyBjb25zaWRlcmF0aW9ucyA6
IDgtYml0DQoNCg0KU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgOg0KT3BlblhQUyB1c2VzIFpJUCBj
b21wcmVzc2lvbiBhcyBzcGVjaWZpZWQgaW4gLlpJUCBGaWxlIEZvcm1hdCBTcGVjaWZpY2F0aW9u
IGZyb20gUEtXQVJFLCBJbmMuLCB2ZXJzaW9uIDYuMi4wICgyMDA0KS4gIFpJUCBjb21wcmVzc2Vk
IFhNTCByZXF1aXJlcyBwYXJzaW5nIHVudHJ1c3RlZCBYTUwgZGF0YSBhbmQgdW50cnVzdGVkIFpJ
UCBkYXRhLiAgVGhlIGNvbnN1bWVyIGlzIHJlc3BvbnNpYmxlIGZvciB2YWxpZGF0aW5nIHRoZSAu
emlwIGFyY2hpdmUsIHRoZSBYTUwgc3RydWN0dXJlLCBhbmQgdGhlIHJlc291cmNlIGNvbnRlbnQu
ICBQZXIgc3BlYywgdGhlcmUgc2hvdWxkIGJlIG5vIGFjdGl2ZSBjb250ZW50IHByb3ZpZGVkIGFz
IHBhcnQgb2YgdGhlIE9wZW5YUFMgZm9ybWF0LiAgVGhlIGNvbnN1bWVyIG11c3QgZW5zdXJlIHRo
YXQgbm8gbWFsaWNpb3VzIGFjdGl2ZSBjb250ZW50IGlzIGVycm9uZW91c2x5IHByb3ZpZGVkIGlu
IHRoZSBPcGVuWFBTIGRvY3VtZW50LiAgVmFsaWQgY29udGVudCBpcyBkZXNjcmliZWQgaW4gdGhl
IEVNQ0EtMzg4IHNwZWNpZmljYXRpb24gKGh0dHA6Ly93d3cuZWNtYS1pbnRlcm5hdGlvbmFsLm9y
Zy9wdWJsaWNhdGlvbnMvc3RhbmRhcmRzL0VjbWEtMzg4Lmh0bSkuICBFc3BlY2lhbGx5IHRha2Ug
bm90ZSBvZiBzZWN0aW9uIEUuMywgd2hpY2ggZGVzY3JpYmVzIHN0ZXBzIHRoYXQgY2FuIGJlIHRh
a2VuIHRvIHZhbGlkYXRlIHRoZSBjb250ZW50cyBvZiB0aGUgcGF5bG9hZC4NCg0KDQoNCg0KSW50
ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9ucyA6DQphcHBsaWNhdGlvbi9PcGVuWFBTIGRvY3Vt
ZW50cyBhcmUgc3BlY2lmaWVkIGJ5IHRoZSBYTUwgc2NoZW1hcw0KICAgc3RhbmRhcmRpemVkIGlu
IEVDTUEtMzg4Lg0KQXBwbGljYXRpb25zIGFuZCBkcml2ZXJzIGN1cnJlbnRseSBwcm9kdWNpbmcv
Y29uc3VtaW5nIE1pY3Jvc29mdCBYUFMgY29udGVudCBjYW5ub3QgZGlyZWN0bHkgcHJvZHVjZS9j
b25zdW1lIE9wZW5YUFMuICBDaGFuZ2VzIGFyZSByZXF1aXJlZCB0byBhZGRyZXNzIGRpZmZlcmVu
Y2VzIGluIHRoZSB0d28gc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgbmFtZXNwYWNlLCBwcmludCB0
aWNrZXQgdXNhZ2UsIHVzZSBvZiBKUEVHIFhSLCBldGMuDQoNCg0KUHVibGlzaGVkIHNwZWNpZmlj
YXRpb24gOg0KVGhlIHB1Ymxpc2hlZCBTdGFuZGFyZCBFQ01BLTM4OCBpcyBhdmFpbGFibGUgYXQ6
DQpodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5vcmcvcHVibGljYXRpb25zL3N0YW5kYXJk
cy9FY21hLTM4OC5odG0NCg0KDQpBcHBsaWNhdGlvbnMgd2hpY2ggdXNlIHRoaXMgbWVkaWEgOg0K
VGhlIGFwcGxpY2F0aW9uL09wZW5YUFMgTUlNRSB0eXBlIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5
IENTVEEgWE1MDQooRUNNQS0zODgpIGluc3RhbmNlIGRvY3VtZW50cy4gIE5vIHB1Ymxpc2hlZCBh
cHBsaWNhdGlvbnMgb3IgcHJpbnQgZHJpdmVycyBjdXJyZW50bHkgdXNlIE9wZW5YUFMuICBUaGUg
aW50ZW50IGlzIGZvciBhbnkgYXBwbGljYXRpb24gb3IgZHJpdmVyIHRoYXQgY2FuIGN1cnJlbnRs
eSBwcm9kdWNlL2NvbnN1bWUgTWljcm9zb2Z0IFhQUyB0byBhbHNvIGFkb3B0IE9wZW5YUFMuICBF
eGFtcGxlcyBvZiBzdWNoIGFwcGxpY2F0aW9ucyB3b3VsZCBpbmNsdWRlIGJ1dCBhcmUgbm90IGxp
bWl0ZWQgdG86ICBNaWNyb3NvZnQgWFBTIFZpZXdlciwgTWljcm9zb2Z0IFhQUyBEb2N1bWVudCBX
cml0ZXIsIE1pY3Jvc29mdCBJbnRlcm5ldCBFeHBsb3JlciA5Lg0KDQoNCg0KQWRkaXRpb25hbCBp
bmZvcm1hdGlvbiA6DQoNCjEuIE1hZ2ljIG51bWJlcihzKSA6IFpJUCBhcmNoaXZlIENSQy0zMjog
NTA0YiAwMzA0IHBlciBodHRwOi8vd3d3LnBrd2FyZS5jb20vZG9jdW1lbnRzL0FQUE5PVEUvQVBQ
Tk9URS02LjIuMC50eHQuICBOb3RlIHRoYXQgaXMgaXQgYSByZXF1aXJlbWVudCBvZiB0aGUgY29u
c3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSBaSVAgYXJjaGl2ZSBpcyBh
IHZhbGlkIE9wZW5YUFMgc3RydWN0dXJlLg0KMi4gRmlsZSBleHRlbnNpb24ocykgOiAub3hwcw0K
My4gTWFjaW50b3NoIHVuaWZvcm0gdHlwZSBpZGVudGlmaWVyIDogb3JnLmVjbWEub3hwcyBjb25m
b3JtcyB0byBjb20ucGt3YXJlLnppcC1hcmNoaXZlDQo0LiBPYmplY3QgSWRlbnRpZmllcnM6IE4v
QQ0KNS4gV2luZG93cyBjbGlwYm9hcmQgbmFtZTogICJPcGVuWFBTIg0KDQpUbyBlbnN1cmUgaW50
ZXJvcGVyYWJpbGl0eSwgdGhlIGNsaXBib2FyZCBmb3JtYXQgbXVzdCBiZSBhIGNvbXBsZXRlIE9w
ZW5YUFMgZmlsZSB3aXRoIC5veHBzIGV4dGVuc2lvbi4NCg0KUGVyc29uICYgZW1haWwgYWRkcmVz
cyB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOg0KRWNtYSBJbnRlcm5hdGlvbmFs
IEhlbHBkZXNrDQpSdWUgZHUgUmhvbmUxMTQNCkNILTEyMDQgR2VuZXZhDQpTd2l0emVybGFuZA0K
aGVscGRlc2tAZWNtYS1pbnRlcm5hdGlvbmFsLm9yZw0KDQoNCkludGVuZGVkIHVzYWdlIDogQ29t
bW9uDQpUaGlzIHR5cGUgd2lsbCBiZSB1c2VkIGZvciBhbGwgZG9jdW1lbnRzIGNvbmZvcm1pbmcg
dG8gdGhlIE9wZW4gWE1MDQogICBQYXBlciBTcGVjaWZjYXRpb24ncyAoRUNNQS0zODgpIE9wZW4g
WFBTIERvY3VtZW50IGZvcm1hdCwgcHVibGlzaGVkDQogICBieSBFQ01BLg0KDQoNCkF1dGhvci9D
aGFuZ2UgY29udHJvbGxlciA6IFRoZSBFQ01BLTM4OCBTdGFuZGFyZCBpcyBkZXZlbG9wZWQgYW5k
DQogICBtYWludGFpbmVkIGJ5IHRoZSBFY21hIFRDNDYgV29ya2luZyBHcm91cC4NCg==

--_002_FE6603D65048F44AB8F8955AE89A09B9172FA8C9TK5EX14MBXW651w_--


Return-Path: <derhoermi@gmx.net>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DF71E06D6 for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 10:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.372
X-Spam-Level: 
X-Spam-Status: No, score=-4.372 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nlr3ALd35p7R for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 10:33:08 -0700 (PDT)
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfc.amsl.com (Postfix) with ESMTP id 701C3E079E for <ietf-types@ietf.org>; Tue, 19 Apr 2011 10:32:56 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora8.dc.icann.org (8.13.8/8.13.8) with SMTP id p3JHWJXX029150 for <ietf-types@iana.org>; Tue, 19 Apr 2011 13:32:40 -0400
Received: (qmail invoked by alias); 19 Apr 2011 17:32:18 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp045) with SMTP; 19 Apr 2011 19:32:18 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+4xGU/6eq4bHbxBFn9PLL6uBtXBl7cYvbQR3B28z fO51txyEgPRSIi
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Brian Clubb <Brian.Clubb@microsoft.com>
Date: Tue, 19 Apr 2011 19:32:22 +0200
Message-ID: <7dhrq6paueospd5n3r3t1r1qmd9af5cotv@hive.bjoern.hoehrmann.de>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Tue, 19 Apr 2011 13:32:40 -0400 (EDT)
Cc: Pete Resnick <presnick@qualcomm.com>, "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Apr 2011 17:33:09 -0000

* Brian Clubb wrote:
><template>
>Name : Brian Clubb
>
>Email : bclubb@microsoft.com
>
>MIME media type name : application
>
>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.

>Required parameters : N/A
>
>Optional parameters :N/A
>
>Encoding considerations : 8-bit

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

>Person to contact for further information :
>
>1. Name : Ecma International Helpdesk
>2. Email : helpdesk@ecma-international.org

It is customary to write this as

  Ecma International Helpdesk <helpdesk@ecma-international.org>

(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: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: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CC97E082A for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 10:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMP5alJ-M-C2 for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 10:20:14 -0700 (PDT)
Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfc.amsl.com (Postfix) with ESMTP id 96245E0828 for <ietf-types@ietf.org>; Tue, 19 Apr 2011 10:20:12 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3JHJatL000484 for <ietf-types@iana.org>; Tue, 19 Apr 2011 10:19:56 -0700
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Apr 2011 10:19:36 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 19 Apr 2011 10:19:35 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Tue, 19 Apr 2011 10:19:19 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Pete Resnick <presnick@qualcomm.com>
Thread-Topic: [ietf-types] Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nAAuzKiAAAN+U7w
Date: Tue, 19 Apr 2011 17:19:18 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172FA7A6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DADBE0A.80309@qualcomm.com>
In-Reply-To: <4DADBE0A.80309@qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/mixed; boundary="_004_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_"
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Tue, 19 Apr 2011 10:19:56 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Apr 2011 17:20:23 -0000

--_004_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_
Content-Type: multipart/alternative;
	boundary="_000_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_"

--_000_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks, Pete!

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

Thanks!
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.  The consumer is responsible=
 for validating the .zip archive, the XML structure, and the resource conte=
nt.  Per spec, there should be no active content provided as part of the Op=
enXPS 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/publicatio=
ns/standards/Ecma-388.htm).  Especially take note of section E.3, which des=
cribes 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 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/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 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: 504b 0304 per http://www.pkware.co=
m/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of th=
e consumer to ensure that the contents of the ZIP archive is a valid OpenXP=
S 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.

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.

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

</template>


From: Pete Resnick [mailto:presnick@qualcomm.com]
Sent: Tuesday, April 19, 2011 9:54 AM
To: Brian Clubb
Cc: ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type

On 4/15/11 1:14 PM, Brian Clubb wrote:
Valid content is described in the ECMA-388 specification <http://www.ecma-i=
nternational.org/publications/standards/Ecma-388.htm><http://www.ecma-inter=
national.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.

[bclubb]  this revision is fine.

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 =A79.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 =A78.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
        =A78.1.2) as a relationships part

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

        a. As required by =A710.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?
[bclubb]  I had feedback from Alexey Melnikov that this section should be e=
xpanded 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 need=
s to validate the contents at some point.  This information is in the OpenX=
PS specification at the section listed (E.3).  I am happy to simply point t=
he reader to that section in the spec instead of specifying this in the tem=
plate 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 wit=
h 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-inte=
rnational.org/publications/standards/Ecma-388.htm>. Especially take note of=
 section E.3, which describes steps that can be taken to validate the conte=
nts of the payload."


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?
[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 issu=
es using application/OpenXPS if that is preferred for standardization reaso=
ns.

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

pr


--

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

Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

--_000_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks, Pete!<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I updated the template wi=
th the last set of edits (replaced long description in Security Considerati=
ons with pointer to spec, used application/OpenXPS for MIME
 type). &nbsp;I have included the revised template below and attached text =
file.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><br>
Thanks!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Brian<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;template&gt;<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Name : Brian Clubb<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Email : bclubb@microsoft.com<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">MIME media type name : application<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">MIME subtype name : Standards Tree &#82=
11; OpenXPS<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Required parameters : N/A<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Optional parameters :N/A<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Encoding considerations : 8-bit<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Security considerations :<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">OpenXPS uses ZIP compression as specifi=
ed in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004=
).&nbsp; ZIP compressed XML requires parsing untrusted XML data
 and untrusted ZIP data.&nbsp; The consumer is responsible for validating t=
he .zip archive, the XML structure, and the resource content.&nbsp; Per spe=
c, there should be no active content provided as part of the OpenXPS format=
.&nbsp; The consumer must ensure that no malicious
 active content is erroneously provided in the OpenXPS document.&nbsp; Vali=
d content is described in the EMCA-388 specification (http://www.ecma-inter=
national.org/publications/standards/Ecma-388.htm).&nbsp; Especially take no=
te of section E.3, which describes steps that
 can be taken to validate the contents of the payload.<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Interoperability considerations :<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">application/OpenXPS documents are speci=
fied by the XML schemas<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; standardized in ECMA-388.<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Applications and drivers currently prod=
ucing/consuming Microsoft XPS content cannot directly produce/consume OpenX=
PS.&nbsp; Changes are required to address differences in the
 two specifications, such as namespace, print ticket usage, use of JPEG XR,=
 etc.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Published specification :<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">The published Standard ECMA-388 is avai=
lable at:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">http://www.ecma-international.org/publi=
cations/standards/Ecma-388.htm<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Applications which use this media :<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">The application/OpenXPS MIME type can b=
e used to identify CSTA XML<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">(ECMA-388) instance documents.&nbsp; No=
 published applications or print drivers currently use OpenXPS.&nbsp; The i=
ntent is for any application or driver that can currently produce/consume
 Microsoft XPS to also adopt OpenXPS.&nbsp; Examples of such applications w=
ould include but are not limited to:&nbsp; Microsoft XPS Viewer, Microsoft =
XPS Document Writer, Microsoft Internet Explorer 9.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Additional information :<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">1. Magic number(s) : ZIP archive CRC-32=
: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.&=
nbsp; Note that is it a requirement of the consumer to ensure
 that the contents of the ZIP archive is a valid OpenXPS structure.<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">2. File extension(s) : .oxps<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">3. Macintosh uniform type identifier : =
org.ecma.oxps conforms to com.pkware.zip-archive<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">4. Object Identifiers: N/A<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">5. Windows clipboard name:&nbsp; &quot;=
OpenXPS&quot;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">To ensure interoperability, the clipboa=
rd format must be a complete OpenXPS file with .oxps extension.<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Person &amp; email address to contact f=
or further information:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Ecma International Helpdesk<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Rue du Rhone114<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">CH-1204 Geneva<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Switzerland<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">helpdesk@ecma-international.org<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Person to contact for further informati=
on :<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">1. Name : Ecma International Helpdesk<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">2. Email : helpdesk@ecma-international.=
org<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Intended usage : Common<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">This type will be used for all document=
s conforming to the Open XML<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; Paper Specifcation's (ECMA=
-388) Open XPS Document format, published<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; by ECMA.<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Author/Change controller : The ECMA-388=
 Standard is developed and<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; maintained by the Ecma TC4=
6 Working Group.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;/template&gt;<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Pete Resnick [mailto:presnick@qualcomm.com]
<br>
<b>Sent:</b> Tuesday, April 19, 2011 9:54 AM<br>
<b>To:</b> Brian Clubb<br>
<b>Cc:</b> ietf-types@iana.org<br>
<b>Subject:</b> Re: [ietf-types] Request for final approval for OpenXPS MIM=
E type<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">On 4/15/11 1:14 PM, Brian Clubb wrote: <o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">Valid content is described in the ECMA-388 specification
<a href=3D"http://www.ecma-international.org/publications/standards/Ecma-38=
8.htm">&lt;http://www.ecma-international.org/publications/standards/Ecma-38=
8.htm&gt;</a>. Especially take note of section E.3:<br>
<br>
&nbsp;&nbsp;&nbsp; OpenXPS Documents follow requirements set out in this St=
andard, as<br>
&nbsp;&nbsp;&nbsp; well as other normative references including the Open Pa=
ckaging<br>
&nbsp;&nbsp;&nbsp; Conventions. Implementations may use the following steps=
 to identify<br>
&nbsp;&nbsp;&nbsp; an unknown file or stream as an OpenXPS Document within =
an Open<br>
&nbsp;&nbsp;&nbsp; Packaging Conventions payload.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"color:red">[bclubb]&nbsp; this revision is fine.</s=
pan><br>
<br>
The formatting on the next bit was mashed up. Is the following correct?<br>
<br>
&nbsp;&nbsp;&nbsp; 1. Test that the file or stream is a ZIP file<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by =A79.2 of the =
Open Packaging Conventions<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. First four bytes correspond t=
o the local file header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signature defined in the .ZIP Fi=
le Format Specification from<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKWARE, Inc., version 6.2.0 (200=
4)<br>
<br>
&nbsp;&nbsp;&nbsp; 2. Test that a valid Package Relationships zip item exis=
ts<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by =A78.3.4 of th=
e Open Packaging Conventions<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type f=
or the package relationships zip<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; item is correctly defined in the=
 Content Types stream (see OPC<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =A78.1.2) as a relationships par=
t<br>
<br>
&nbsp;&nbsp;&nbsp; 3. Test that the Package Relationships Part contains a r=
elationship<br>
&nbsp;&nbsp;&nbsp; (see OPC =A78.3) whose Target attribute points to a vali=
d<br>
&nbsp;&nbsp;&nbsp; FixedDocumentSequence Part<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by =A710.2 of thi=
s Standard<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type f=
or the FixedDocumentSequence<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part is correctly defined in the=
 Content Types stream as a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FixedDocumentSequence part<br>
<br>
I'm not entirely clear on the need for this discussion in the template. Do =
folks implementing the media type need to know this?<br>
<span style=3D"color:red">[bclubb]&nbsp; I had feedback from Alexey Melniko=
v that this section should be expanded from my original draft.&nbsp; 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.&nbsp; This information is in the OpenXPS speci=
fication at the section listed (E.3).&nbsp; I am happy to simply point the =
reader to that section in the spec instead of specifying this in the templa=
te if that is acceptable.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><br>
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 wit=
h something like this:<br>
<br>
&quot;Valid content is described in the ECMA-388 specification <a href=3D"h=
ttp://www.ecma-international.org/publications/standards/Ecma-388.htm">
&lt;http://www.ecma-international.org/publications/standards/Ecma-388.htm&g=
t;</a>. Especially take note of section E.3, which describes steps that can=
 be taken to validate the contents of the payload.&quot;<br>
<br>
<br>
<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">Applications which use this media :
<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">The application/oxps MIME type can be used to identify CSTA XML...=
<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><br>
That's a typo, yes? It should be application/OpenXPS?<br>
<span style=3D"color:red">[bclubb]&nbsp; Either OpenXPS or oxps is acceptab=
le.&nbsp; The original non-standard format registered by Microsoft used app=
lication/xps.&nbsp; The extension on the standard format is .oxps and thus =
it was used here.&nbsp; However, I see no issues using
 application/OpenXPS if that is preferred for standardization reasons.</spa=
n><o:p></o:p></p>
<p class=3D"MsoNormal"><br>
The file type is &quot;.oxps&quot;, not the MIME type. The only thing in th=
is registration for a MIME type is &quot;application/openxps&quot;. Either =
you have to *only* use &quot;application/openxps&quot;, or you have to also=
 register &quot;application/oxps&quot; if you think both are going to be
 used. I don't really care which.<br>
<br>
pr<br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Pete Resnick <a href=3D"http://www.qualcomm.com/~presnick/">&lt;http:/=
/www.qualcomm.com/~presnick/&gt;</a><o:p></o:p></pre>
<pre>Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-110=
2<o:p></o:p></pre>
</div>
</body>
</html>

--_000_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_--

--_004_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_
Content-Type: text/plain; name="MIMEReg.txt"
Content-Description: MIMEReg.txt
Content-Disposition: attachment; filename="MIMEReg.txt"; size=3204;
	creation-date="Wed, 01 Dec 2010 17:22:01 GMT";
	modification-date="Tue, 19 Apr 2011 17:16:19 GMT"
Content-Transfer-Encoding: base64

TmFtZSA6IEJyaWFuIENsdWJiDQoNCkVtYWlsIDogYmNsdWJiQG1pY3Jvc29mdC5jb20NCg0KTUlN
RSBtZWRpYSB0eXBlIG5hbWUgOiBhcHBsaWNhdGlvbg0KDQpNSU1FIHN1YnR5cGUgbmFtZSA6IFN0
YW5kYXJkcyBUcmVlIJYgT3BlblhQUw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzIDogTi9BDQoNCg0K
T3B0aW9uYWwgcGFyYW1ldGVycyA6DQpOL0ENCg0KDQpFbmNvZGluZyBjb25zaWRlcmF0aW9ucyA6
IDgtYml0DQoNCg0KU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgOg0KT3BlblhQUyB1c2VzIFpJUCBj
b21wcmVzc2lvbiBhcyBzcGVjaWZpZWQgaW4gLlpJUCBGaWxlIEZvcm1hdCBTcGVjaWZpY2F0aW9u
IGZyb20gUEtXQVJFLCBJbmMuLCB2ZXJzaW9uIDYuMi4wICgyMDA0KS4gIFpJUCBjb21wcmVzc2Vk
IFhNTCByZXF1aXJlcyBwYXJzaW5nIHVudHJ1c3RlZCBYTUwgZGF0YSBhbmQgdW50cnVzdGVkIFpJ
UCBkYXRhLiAgVGhlIGNvbnN1bWVyIGlzIHJlc3BvbnNpYmxlIGZvciB2YWxpZGF0aW5nIHRoZSAu
emlwIGFyY2hpdmUsIHRoZSBYTUwgc3RydWN0dXJlLCBhbmQgdGhlIHJlc291cmNlIGNvbnRlbnQu
ICBQZXIgc3BlYywgdGhlcmUgc2hvdWxkIGJlIG5vIGFjdGl2ZSBjb250ZW50IHByb3ZpZGVkIGFz
IHBhcnQgb2YgdGhlIE9wZW5YUFMgZm9ybWF0LiAgVGhlIGNvbnN1bWVyIG11c3QgZW5zdXJlIHRo
YXQgbm8gbWFsaWNpb3VzIGFjdGl2ZSBjb250ZW50IGlzIGVycm9uZW91c2x5IHByb3ZpZGVkIGlu
IHRoZSBPcGVuWFBTIGRvY3VtZW50LiAgVmFsaWQgY29udGVudCBpcyBkZXNjcmliZWQgaW4gdGhl
IEVNQ0EtMzg4IHNwZWNpZmljYXRpb24gKGh0dHA6Ly93d3cuZWNtYS1pbnRlcm5hdGlvbmFsLm9y
Zy9wdWJsaWNhdGlvbnMvc3RhbmRhcmRzL0VjbWEtMzg4Lmh0bSkuICBFc3BlY2lhbGx5IHRha2Ug
bm90ZSBvZiBzZWN0aW9uIEUuMywgd2hpY2ggZGVzY3JpYmVzIHN0ZXBzIHRoYXQgY2FuIGJlIHRh
a2VuIHRvIHZhbGlkYXRlIHRoZSBjb250ZW50cyBvZiB0aGUgcGF5bG9hZC4NCg0KDQoNCg0KSW50
ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9ucyA6DQphcHBsaWNhdGlvbi9PcGVuWFBTIGRvY3Vt
ZW50cyBhcmUgc3BlY2lmaWVkIGJ5IHRoZSBYTUwgc2NoZW1hcw0KICAgc3RhbmRhcmRpemVkIGlu
IEVDTUEtMzg4Lg0KQXBwbGljYXRpb25zIGFuZCBkcml2ZXJzIGN1cnJlbnRseSBwcm9kdWNpbmcv
Y29uc3VtaW5nIE1pY3Jvc29mdCBYUFMgY29udGVudCBjYW5ub3QgZGlyZWN0bHkgcHJvZHVjZS9j
b25zdW1lIE9wZW5YUFMuICBDaGFuZ2VzIGFyZSByZXF1aXJlZCB0byBhZGRyZXNzIGRpZmZlcmVu
Y2VzIGluIHRoZSB0d28gc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgbmFtZXNwYWNlLCBwcmludCB0
aWNrZXQgdXNhZ2UsIHVzZSBvZiBKUEVHIFhSLCBldGMuDQoNCg0KUHVibGlzaGVkIHNwZWNpZmlj
YXRpb24gOg0KVGhlIHB1Ymxpc2hlZCBTdGFuZGFyZCBFQ01BLTM4OCBpcyBhdmFpbGFibGUgYXQ6
DQpodHRwOi8vd3d3LmVjbWEtaW50ZXJuYXRpb25hbC5vcmcvcHVibGljYXRpb25zL3N0YW5kYXJk
cy9FY21hLTM4OC5odG0NCg0KDQpBcHBsaWNhdGlvbnMgd2hpY2ggdXNlIHRoaXMgbWVkaWEgOg0K
VGhlIGFwcGxpY2F0aW9uL09wZW5YUFMgTUlNRSB0eXBlIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5
IENTVEEgWE1MDQooRUNNQS0zODgpIGluc3RhbmNlIGRvY3VtZW50cy4gIE5vIHB1Ymxpc2hlZCBh
cHBsaWNhdGlvbnMgb3IgcHJpbnQgZHJpdmVycyBjdXJyZW50bHkgdXNlIE9wZW5YUFMuICBUaGUg
aW50ZW50IGlzIGZvciBhbnkgYXBwbGljYXRpb24gb3IgZHJpdmVyIHRoYXQgY2FuIGN1cnJlbnRs
eSBwcm9kdWNlL2NvbnN1bWUgTWljcm9zb2Z0IFhQUyB0byBhbHNvIGFkb3B0IE9wZW5YUFMuICBF
eGFtcGxlcyBvZiBzdWNoIGFwcGxpY2F0aW9ucyB3b3VsZCBpbmNsdWRlIGJ1dCBhcmUgbm90IGxp
bWl0ZWQgdG86ICBNaWNyb3NvZnQgWFBTIFZpZXdlciwgTWljcm9zb2Z0IFhQUyBEb2N1bWVudCBX
cml0ZXIsIE1pY3Jvc29mdCBJbnRlcm5ldCBFeHBsb3JlciA5Lg0KDQoNCg0KQWRkaXRpb25hbCBp
bmZvcm1hdGlvbiA6DQoNCjEuIE1hZ2ljIG51bWJlcihzKSA6IFpJUCBhcmNoaXZlIENSQy0zMjog
NTA0YiAwMzA0IHBlciBodHRwOi8vd3d3LnBrd2FyZS5jb20vZG9jdW1lbnRzL0FQUE5PVEUvQVBQ
Tk9URS02LjIuMC50eHQuICBOb3RlIHRoYXQgaXMgaXQgYSByZXF1aXJlbWVudCBvZiB0aGUgY29u
c3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbnRlbnRzIG9mIHRoZSBaSVAgYXJjaGl2ZSBpcyBh
IHZhbGlkIE9wZW5YUFMgc3RydWN0dXJlLg0KMi4gRmlsZSBleHRlbnNpb24ocykgOiAub3hwcw0K
My4gTWFjaW50b3NoIHVuaWZvcm0gdHlwZSBpZGVudGlmaWVyIDogb3JnLmVjbWEub3hwcyBjb25m
b3JtcyB0byBjb20ucGt3YXJlLnppcC1hcmNoaXZlDQo0LiBPYmplY3QgSWRlbnRpZmllcnM6IE4v
QQ0KNS4gV2luZG93cyBjbGlwYm9hcmQgbmFtZTogICJPcGVuWFBTIg0KDQpUbyBlbnN1cmUgaW50
ZXJvcGVyYWJpbGl0eSwgdGhlIGNsaXBib2FyZCBmb3JtYXQgbXVzdCBiZSBhIGNvbXBsZXRlIE9w
ZW5YUFMgZmlsZSB3aXRoIC5veHBzIGV4dGVuc2lvbi4NCg0KUGVyc29uICYgZW1haWwgYWRkcmVz
cyB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOg0KRWNtYSBJbnRlcm5hdGlvbmFs
IEhlbHBkZXNrDQpSdWUgZHUgUmhvbmUxMTQNCkNILTEyMDQgR2VuZXZhDQpTd2l0emVybGFuZA0K
aGVscGRlc2tAZWNtYS1pbnRlcm5hdGlvbmFsLm9yZw0KDQoNCg0KUGVyc29uIHRvIGNvbnRhY3Qg
Zm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24gOg0KDQoxLiBOYW1lIDogRWNtYSBJbnRlcm5hdGlvbmFs
IEhlbHBkZXNrDQoyLiBFbWFpbCA6IGhlbHBkZXNrQGVjbWEtaW50ZXJuYXRpb25hbC5vcmcNCg0K
SW50ZW5kZWQgdXNhZ2UgOiBDb21tb24NClRoaXMgdHlwZSB3aWxsIGJlIHVzZWQgZm9yIGFsbCBk
b2N1bWVudHMgY29uZm9ybWluZyB0byB0aGUgT3BlbiBYTUwNCiAgIFBhcGVyIFNwZWNpZmNhdGlv
bidzIChFQ01BLTM4OCkgT3BlbiBYUFMgRG9jdW1lbnQgZm9ybWF0LCBwdWJsaXNoZWQNCiAgIGJ5
IEVDTUEuDQoNCg0KQXV0aG9yL0NoYW5nZSBjb250cm9sbGVyIDogVGhlIEVDTUEtMzg4IFN0YW5k
YXJkIGlzIGRldmVsb3BlZCBhbmQNCiAgIG1haW50YWluZWQgYnkgdGhlIEVjbWEgVEM0NiBXb3Jr
aW5nIEdyb3VwLg0K

--_004_FE6603D65048F44AB8F8955AE89A09B9172FA7A6TK5EX14MBXW651w_--


Return-Path: <presnick@qualcomm.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E599CE07FB for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 10:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.382
X-Spam-Level: 
X-Spam-Status: No, score=-104.382 tagged_above=-999 required=5 tests=[AWL=-1.784, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZkaqEpZkGLj for <ietf-types@ietfc.amsl.com>; Tue, 19 Apr 2011 10:11:18 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfc.amsl.com (Postfix) with ESMTP id B62DEE07B2 for <ietf-types@ietf.org>; Tue, 19 Apr 2011 10:11:16 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3JHAfOg008640 for <ietf-types@iana.org>; Tue, 19 Apr 2011 10:11:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1303233061; x=1334769061; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DADBE0A.80309@qualcomm.com>|Date:=20Tue, =2019=20Apr=202011=2011:53:30=20-0500|From:=20Pete=20Resn ick=20<presnick@qualcomm.com>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Brian=20Clubb=20<Brian.Clubb@m icrosoft.com>|CC:=20"ietf-types@iana.org"=20<ietf-types@i ana.org>|Subject:=20Re:=20[ietf-types]=20Request=20for=20 final=20approval=20for=20OpenXPS=20MIME=20type |References:=20<FE6603D65048F44AB8F8955AE89A09B9172EE107@ TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>=09 <4DA87DD4.7070105@qualcomm.com>=20<FE6603D65048F44AB8F895 5AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntde v.microsoft.com>|In-Reply-To:=20<FE6603D65048F44AB8F8955A E89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev. microsoft.com>|Content-Type:=20multipart/alternative=3B =0D=0A=09boundary=3D"------------050307070001090804090305 "|X-Originating-IP:=20[172.30.48.1]; bh=S4GwJZ9Pu25OjHFCXoC0tjsAsurIYXskWWLa1nYqDyI=; b=yHdaMaDodLwIhghwUxSQWrlMPTDoTTvIRhjKwV3Gyntm1UMgA7i1Zwda ctLRo84deyxVULqrCQiNNtYOLnVCHDSwziRaefm7W04qWNruDxfsH9t2o YRqgZba3Am4M4CUR6lmNN33Ov3IHOq54q+hi5+ApFqbC6mjWdSf2RXGJE Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,6321"; a="86687654"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 19 Apr 2011 09:53:46 -0700
X-IronPort-AV: E=Sophos;i="4.64,239,1301900400"; d="scan'208,217";a="67264315"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 19 Apr 2011 09:53:36 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 09:53:32 -0700
Message-ID: <4DADBE0A.80309@qualcomm.com>
Date: Tue, 19 Apr 2011 11:53:30 -0500
From: Pete Resnick <presnick@qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Brian Clubb <Brian.Clubb@microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>	<4DA87DD4.7070105@qualcomm.com> <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: multipart/alternative; boundary="------------050307070001090804090305"
X-Originating-IP: [172.30.48.1]
X-Greylist: Delayed for 00:16:54 by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Tue, 19 Apr 2011 10:11:01 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 Apr 2011 17:11:20 -0000

--------------050307070001090804090305
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

On 4/15/11 1:14 PM, Brian Clubb wrote:
>
> 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.
>
> [bclubb]  this revision is fine.
>
> 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?
> [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."

> 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?
> [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

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


--------------050307070001090804090305
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 4/15/11 1:14 PM, Brian Clubb wrote:
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <p class="MsoNormal"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;">Valid
content is described in the ECMA-388 specification <a
 moz-do-not-send="true"
 href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">
&lt;http://www.ecma-international.org/publications/standards/Ecma-388.htm&gt;</a>.
Especially take note of section E.3:<br>
  <br>
&nbsp;&nbsp;&nbsp; OpenXPS Documents follow requirements set out in this Standard, as<br>
&nbsp;&nbsp;&nbsp; well as other normative references including the Open Packaging<br>
&nbsp;&nbsp;&nbsp; Conventions. Implementations may use the following steps to identify<br>
&nbsp;&nbsp;&nbsp; an unknown file or stream as an OpenXPS Document within an Open<br>
&nbsp;&nbsp;&nbsp; Packaging Conventions payload.</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;; color: rgb(31, 73, 125);"><o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;; color: rgb(31, 73, 125);"><o:p>&nbsp;</o:p></span></p>
  <p class="MsoNormal"><span style="font-size: 12pt; color: red;">[bclubb]&nbsp;
this revision is fine.</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"><br>
  <br>
The formatting on the next bit was mashed up. Is the following correct?<br>
  <br>
&nbsp;&nbsp;&nbsp; 1. Test that the file or stream is a ZIP file<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by &sect;9.2 of the Open Packaging Conventions<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. First four bytes correspond to the local file header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signature defined in the .ZIP File Format Specification from<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKWARE, Inc., version 6.2.0 (2004)<br>
  <br>
&nbsp;&nbsp;&nbsp; 2. Test that a valid Package Relationships zip item exists<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by &sect;8.3.4 of the Open Packaging Conventions<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type for the package relationships zip<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; item is correctly defined in the Content Types stream (see OPC<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &sect;8.1.2) as a relationships part<br>
  <br>
&nbsp;&nbsp;&nbsp; 3. Test that the Package Relationships Part contains a relationship<br>
&nbsp;&nbsp;&nbsp; (see OPC &sect;8.3) whose Target attribute points to a valid<br>
&nbsp;&nbsp;&nbsp; FixedDocumentSequence Part<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by &sect;10.2 of this Standard<br>
  <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type for the FixedDocumentSequence<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part is correctly defined in the Content Types stream as a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FixedDocumentSequence part<br>
  <br>
I'm not entirely clear on the need for this discussion in the template.
Do folks implementing the media type need to know this?<br>
  </span><span style="font-size: 12pt; color: red;">[bclubb]&nbsp; I had
feedback from Alexey Melnikov that this section should be expanded from
my original draft.&nbsp; 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.&nbsp; This information is in the
OpenXPS specification at the section listed (E.3).&nbsp; 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.</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"><br>
  </span></p>
</blockquote>
<br>
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:<br>
<br>
<span style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;">"Valid
content is described in the ECMA-388 specification <a
 moz-do-not-send="true"
 href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">
&lt;http://www.ecma-international.org/publications/standards/Ecma-388.htm&gt;</a>.
Especially take note of section E.3, which describes steps that can be
taken to validate the contents of the payload."<br>
<br>
</span>
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <p class="MsoNormal"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;">Applications
which use this media :
  <o:p></o:p></span></p>
  <p class="MsoNormal">The application/oxps MIME type can be used to
identify CSTA XML...<o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"><br>
That's a typo, yes? It should be application/OpenXPS?<br>
  </span><span style="font-size: 12pt; color: red;">[bclubb]&nbsp; Either
OpenXPS or oxps is acceptable.&nbsp; The original non-standard format
registered by Microsoft used application/xps.&nbsp; The extension on the
standard format is .oxps and thus it was used here.&nbsp; However, I see no
issues using application/OpenXPS if that is preferred for
standardization reasons.</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"><br>
  </span></p>
</blockquote>
<br>
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.<br>
<br>
pr<br>
<pre class="moz-signature" cols="72">-- 
Pete Resnick <a class="moz-txt-link-rfc2396E" href="http://www.qualcomm.com/~presnick/">&lt;http://www.qualcomm.com/~presnick/&gt;</a>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102</pre>
</body>
</html>

--------------050307070001090804090305--


Return-Path: <Brian.Clubb@microsoft.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1266E090F for <ietf-types@ietfc.amsl.com>; Fri, 15 Apr 2011 11:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6OQR5I-Eu11 for <ietf-types@ietfc.amsl.com>; Fri, 15 Apr 2011 11:14:49 -0700 (PDT)
Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by ietfc.amsl.com (Postfix) with ESMTP id 6CC3AE06B0 for <ietf-types@ietf.org>; Fri, 15 Apr 2011 11:14:48 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3FIECNq016109 for <ietf-types@iana.org>; Fri, 15 Apr 2011 14:14:33 -0400
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Apr 2011 11:14:12 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 15 Apr 2011 11:14:11 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.117]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Fri, 15 Apr 2011 11:14:11 -0700
From: Brian Clubb <Brian.Clubb@microsoft.com>
To: Pete Resnick <presnick@qualcomm.com>
Thread-Topic: Request for final approval for OpenXPS MIME type
Thread-Index: Acvz6MVMOH5X0vObQxq5N71yv14P0QH4wAoAAA0a8nA=
Date: Fri, 15 Apr 2011 18:14:10 +0000
Message-ID: <FE6603D65048F44AB8F8955AE89A09B9172F88B2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4DA87DD4.7070105@qualcomm.com>
In-Reply-To: <4DA87DD4.7070105@qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/alternative; boundary="_000_FE6603D65048F44AB8F8955AE89A09B9172F88B2TK5EX14MBXW651w_"
MIME-Version: 1.0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Fri, 15 Apr 2011 14:14:33 -0400 (EDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 15 Apr 2011 18:14:54 -0000

--_000_FE6603D65048F44AB8F8955AE89A09B9172F88B2TK5EX14MBXW651w_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Pete,

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

Thanks!
Brian

From: Pete Resnick [mailto:presnick@qualcomm.com]
Sent: Friday, April 15, 2011 10:18 AM
To: Brian Clubb
Cc: ietf-types@iana.org
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 a=
nd addressed all issues in the template (see threads ending with these link=
s: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170.html; h=
ttp://www.ietf.org/mail-archive/web/ietf-types/current/msg01182.html).  The=
re 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 h=
ad 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 Alexe=
y. You have the misfortune of being the "transition" registration. Please b=
e 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 pars=
ing 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-i=
nternational.org/publications/standards/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.

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-i=
nternational.org/publications/standards/Ecma-388.htm><http://www.ecma-inter=
national.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.

[bclubb]  this revision is fine.

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 =A79.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 =A78.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
        =A78.1.2) as a relationships part

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

        a. As required by =A710.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?
[bclubb]  I had feedback from Alexey Melnikov that this section should be e=
xpanded 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 need=
s to validate the contents at some point.  This information is in the OpenX=
PS specification at the section listed (E.3).  I am happy to simply point t=
he reader to that section in the spec instead of specifying this in the tem=
plate if that is acceptable.

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?
[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 issu=
es using application/OpenXPS if that is preferred for standardization reaso=
ns.

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

Person to contact for further information :

1. Name : Ecma International Helpdesk
2. Email : helpdesk@ecma-international.org<mailto:helpdesk@ecma-internation=
al.org>

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

Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

--_000_FE6603D65048F44AB8F8955AE89A09B9172F88B2TK5EX14MBXW651w_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Pete,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><br>
Thanks for your response!&nbsp; I have answered the questions inline.&nbsp;=
 Please let me know if you have any other items you would like me to addres=
s.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><br>
Thanks!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Brian<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> Pete Resnick [mailto:presnick@qualcomm.com]
<br>
<b>Sent:</b> Friday, April 15, 2011 10:18 AM<br>
<b>To:</b> Brian Clubb<br>
<b>Cc:</b> ietf-types@iana.org<br>
<b>Subject:</b> Re: Request for final approval for OpenXPS MIME type<o:p></=
o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">On 4/5/11 6:34 PM, Brian Clubb wrote: <o:p></o:p></p=
>
<p class=3D"MsoNormal">I am requesting final approval of the MIME type regi=
stration for OpenXPS. &nbsp;I have received two threads with questions duri=
ng the open comment period and addressed all issues in the template (see th=
reads ending with these links:
<a href=3D"http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170=
.html">http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170.htm=
l</a>;
<a href=3D"http://www.ietf.org/mail-archive/web/ietf-types/current/msg01182=
.html">http://www.ietf.org/mail-archive/web/ietf-types/current/msg01182.htm=
l</a>).&nbsp; There have been no additional comments within the last two we=
eks.<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Please let me know if you have any additional concer=
ns with this request.&nbsp; I look forward to your approval on this matter.=
<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
Hi Brian,<br>
<br>
I was reading this over to get it on the next IESG agenda for approval. I h=
ad 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 Alexe=
y. You have the misfortune of being
 the &quot;transition&quot; registration. Please be patient with me.<br>
<br>
(I'm Cc'ing ietf-types just in case anyone there has any followup.)<br>
<br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal">Security considerations :<o:p></o:p></p>
<p class=3D"MsoNormal">OpenXPS uses ZIP compression as specified in .ZIP Fi=
le Format Specification from PKWARE, Inc., version 6.2.0 (2004).&nbsp; ZIP =
compressed XML requires parsing untrusted XML data and untrusted ZIP data.&=
nbsp; consumer is responsible for validating
 the .zip archive, the XML structure, and the resource content.<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
I assume there needs to be a &quot;The&quot; before &quot;consumer&quot;?<b=
r>
</span><span style=3D"font-size:12.0pt;color:red">[bclubb]&nbsp; Yes, you a=
re correct.&nbsp; Thanks for catching this.</span><span style=3D"font-size:=
12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;"><br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal">Valid content is described in the EMCA-388 specifica=
tion (<a href=3D"http://www.ecma-international.org/publications/standards/E=
cma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-=
388.htm</a>)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Also see section E.3 of ECMA-388 specification (<a h=
ref=3D"http://www.ecma-international.org/publications/standards/Ecma-388.ht=
m">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a=
>)<br>
<br>
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.<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
Is everything starting with &quot;OpenXPS Documents follow...&quot; a quote=
 from ECMA-388 E.3? If so, it needs to be set off somehow. Would this be a =
reasonable replacement?<br>
<br>
Valid content is described in the ECMA-388 specification <a href=3D"http://=
www.ecma-international.org/publications/standards/Ecma-388.htm">
&lt;http://www.ecma-international.org/publications/standards/Ecma-388.htm&g=
t;</a>. Especially take note of section E.3:<br>
<br>
&nbsp;&nbsp;&nbsp; OpenXPS Documents follow requirements set out in this St=
andard, as<br>
&nbsp;&nbsp;&nbsp; well as other normative references including the Open Pa=
ckaging<br>
&nbsp;&nbsp;&nbsp; Conventions. Implementations may use the following steps=
 to identify<br>
&nbsp;&nbsp;&nbsp; an unknown file or stream as an OpenXPS Document within =
an Open<br>
&nbsp;&nbsp;&nbsp; Packaging Conventions payload.</span><span style=3D"font=
-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;;colo=
r:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;color:red">[bclubb]&=
nbsp; this revision is fine.</span><span style=3D"font-size:12.0pt;font-fam=
ily:&quot;Times New Roman&quot;,&quot;serif&quot;"><br>
<br>
The formatting on the next bit was mashed up. Is the following correct?<br>
<br>
&nbsp;&nbsp;&nbsp; 1. Test that the file or stream is a ZIP file<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by =A79.2 of the =
Open Packaging Conventions<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. First four bytes correspond t=
o the local file header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signature defined in the .ZIP Fi=
le Format Specification from<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKWARE, Inc., version 6.2.0 (200=
4)<br>
<br>
&nbsp;&nbsp;&nbsp; 2. Test that a valid Package Relationships zip item exis=
ts<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by =A78.3.4 of th=
e Open Packaging Conventions<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type f=
or the package relationships zip<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; item is correctly defined in the=
 Content Types stream (see OPC<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =A78.1.2) as a relationships par=
t<br>
<br>
&nbsp;&nbsp;&nbsp; 3. Test that the Package Relationships Part contains a r=
elationship<br>
&nbsp;&nbsp;&nbsp; (see OPC =A78.3) whose Target attribute points to a vali=
d<br>
&nbsp;&nbsp;&nbsp; FixedDocumentSequence Part<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by =A710.2 of thi=
s Standard<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type f=
or the FixedDocumentSequence<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part is correctly defined in the=
 Content Types stream as a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FixedDocumentSequence part<br>
<br>
I'm not entirely clear on the need for this discussion in the template. Do =
folks implementing the media type need to know this?<br>
</span><span style=3D"font-size:12.0pt;color:red">[bclubb]&nbsp; I had feed=
back from Alexey Melnikov that this section should be expanded from my orig=
inal draft.&nbsp; 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.&nbsp; This informat=
ion is in the OpenXPS specification at the section listed (E.3).&nbsp; I am=
 happy to simply point the reader to that section in the spec instead of sp=
ecifying this in the template if that is acceptable.</span><span style=3D"f=
ont-size:12.0pt;font-family:&quot;Times New Roman&quot;,&quot;serif&quot;">=
<br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;">Applications which use this media :
<o:p></o:p></span></p>
<p class=3D"MsoNormal">The application/oxps MIME type can be used to identi=
fy CSTA XML...<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
That's a typo, yes? It should be application/OpenXPS?<br>
</span><span style=3D"font-size:12.0pt;color:red">[bclubb]&nbsp; Either Ope=
nXPS or oxps is acceptable.&nbsp; The original non-standard format register=
ed by Microsoft used application/xps.&nbsp; The extension on the standard f=
ormat is .oxps and thus it was used here.&nbsp; However,
 I see no issues using application/OpenXPS if that is preferred for standar=
dization reasons.</span><span style=3D"font-size:12.0pt;font-family:&quot;T=
imes New Roman&quot;,&quot;serif&quot;"><br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;">Person &amp; email address to contac=
t for further information:
<o:p></o:p></span></p>
<p class=3D"MsoNormal">Ecma International Helpdesk<o:p></o:p></p>
<p class=3D"MsoNormal">Rue du Rhone114<o:p></o:p></p>
<p class=3D"MsoNormal">CH-1204 Geneva<o:p></o:p></p>
<p class=3D"MsoNormal">Switzerland<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"mailto:helpdesk@ecma-international.org">h=
elpdesk@ecma-international.org</a><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Person to contact for further information :<o:p></o:=
p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">1. Name : Ecma International Helpdesk<o:p></o:p></p>
<p class=3D"MsoNormal">2. Email : <a href=3D"mailto:helpdesk@ecma-internati=
onal.org">
helpdesk@ecma-international.org</a><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
Is that intended to be duplicated?<br>
</span><span style=3D"font-size:12.0pt;color:red">[bclubb]&nbsp; Yes, the d=
uplication is intentional.</span><b><span style=3D"font-size:12.0pt;font-fa=
mily:&quot;Times New Roman&quot;,&quot;serif&quot;;color:#1F497D"><o:p></o:=
p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
Thanks for bringing me up to speed. We'll get it on the next agenda and get=
 it approved.<br>
<br>
pr<br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Pete Resnick <a href=3D"http://www.qualcomm.com/~presnick/">&lt;http:/=
/www.qualcomm.com/~presnick/&gt;</a><o:p></o:p></pre>
<pre>Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-110=
2<o:p></o:p></pre>
</div>
</body>
</html>

--_000_FE6603D65048F44AB8F8955AE89A09B9172F88B2TK5EX14MBXW651w_--


Return-Path: <presnick@qualcomm.com>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 384D8E0678 for <ietf-types@ietfc.amsl.com>; Fri, 15 Apr 2011 10:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.498
X-Spam-Level: 
X-Spam-Status: No, score=-104.498 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmWRbGYaVuqc for <ietf-types@ietfc.amsl.com>; Fri, 15 Apr 2011 10:40:30 -0700 (PDT)
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfc.amsl.com (Postfix) with ESMTP id 9E668E0784 for <ietf-types@ietf.org>; Fri, 15 Apr 2011 10:40:30 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p3FHds3I013086 for <ietf-types@iana.org>; Fri, 15 Apr 2011 13:40:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1302889214; x=1334425214; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DA87DD4.7070105@qualcomm.com>|Date:=20Fr i,=2015=20Apr=202011=2012:18:12=20-0500|From:=20Pete=20Re snick=20<presnick@qualcomm.com>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Brian=20Clubb=20<Brian.Clubb@m icrosoft.com>|CC:=20<ietf-types@iana.org>|Subject:=20Re: =20Request=20for=20final=20approval=20for=20OpenXPS=20MIM E=20type|References:=20<FE6603D65048F44AB8F8955AE89A09B91 72EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft .com>|In-Reply-To:=20<FE6603D65048F44AB8F8955AE89A09B9172 EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.c om>|Content-Type:=20multipart/alternative=3B=0D=0A=09boun dary=3D"------------060908020904040905050803" |X-Originating-IP:=20[172.30.48.1]; bh=CFWB3sV0Gdl2wnbnXq17OTE8f8zSg4sij/Uz/AfA4O4=; b=voEnWJv30UZl82PK6GDJD/C12KWjRQF33/t/BzvY7Fw4jDvY2S5ymbmA Yt/y15jA6ibaNyRr9qW+G81uJ2eqXYxD1JFb0oeCLtpUfQhpapaLjUsQu W4fD2NgP28foJvIyDRsazReTjWfuEKyvIbLreKtKgSrMynzG2dwQxOJen 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6317"; a="85862253"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 15 Apr 2011 10:19:08 -0700
X-IronPort-AV: E=Sophos;i="4.64,219,1301900400";  d="scan'208,217";a="135824041"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 15 Apr 2011 10:19:07 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 10:18:14 -0700
Message-ID: <4DA87DD4.7070105@qualcomm.com>
Date: Fri, 15 Apr 2011 12:18:12 -0500
From: Pete Resnick <presnick@qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Brian Clubb <Brian.Clubb@microsoft.com>
References: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: multipart/alternative; boundary="------------060908020904040905050803"
X-Originating-IP: [172.30.48.1]
X-Greylist: Delayed for 00:20:30 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Fri, 15 Apr 2011 13:40:15 -0400 (EDT)
Cc: ietf-types@iana.org
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 15 Apr 2011 17:40:35 -0000

--------------060908020904040905050803
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

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
>
> helpdesk@ecma-international.org
>
> Person to contact for further information :
>
> 1. Name : Ecma International Helpdesk
>
> 2. Email : helpdesk@ecma-international.org
>

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


--------------060908020904040905050803
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 4/5/11 6:34 PM, Brian Clubb wrote:
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <meta http-equiv="Content-Type"
 content="text/html; charset=ISO-8859-1">
  <meta name="Generator" content="Microsoft Word 14 (filtered medium)">
  <style><!--
/* Font Definitions */
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
  <div class="WordSection1">
  <p class="MsoNormal">I am requesting final approval of the MIME type
registration for OpenXPS. &nbsp;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:
  <a moz-do-not-send="true"
 href="http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170.html">http://www.ietf.org/mail-archive/web/ietf-types/current/msg01170.html</a>;
  <a moz-do-not-send="true"
 href="http://www.ietf.org/mail-archive/web/ietf-types/current/msg01182.html">http://www.ietf.org/mail-archive/web/ietf-types/current/msg01182.html</a>).&nbsp;
There have been no additional comments within the last two weeks.<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Please let me know if you have any additional
concerns with this request.&nbsp; I look forward to your approval on this
matter.<o:p></o:p></p>
  </div>
</blockquote>
<br>
Hi Brian,<br>
<br>
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.<br>
<br>
(I'm Cc'ing ietf-types just in case anyone there has any followup.)<br>
<br>
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <div class="WordSection1"><o:p></o:p><o:p></o:p>
  <p class="MsoNormal">Security considerations :<o:p></o:p></p>
  <p class="MsoNormal">OpenXPS uses ZIP compression as specified in
.ZIP File Format Specification from PKWARE, Inc., version 6.2.0
(2004).&nbsp; ZIP compressed XML requires parsing untrusted XML data and
untrusted ZIP data.&nbsp; consumer is responsible for validating the .zip
archive, the XML structure, and the resource content.</p>
  </div>
</blockquote>
<br>
I assume there needs to be a "The" before "consumer"?<br>
<br>
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <div class="WordSection1">
  <p class="MsoNormal">Valid content is described in the EMCA-388
specification
(<a class="moz-txt-link-freetext" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a>)<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Also see section E.3 of ECMA-388 specification
(<a class="moz-txt-link-freetext" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a>)<o:p><br>
  <br>
  </o:p>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.</p>
  </div>
</blockquote>
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
</blockquote>
<br>
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?<br>
<br>
Valid content is described in the ECMA-388 specification
<a class="moz-txt-link-rfc2396E" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">&lt;http://www.ecma-international.org/publications/standards/Ecma-388.htm&gt;</a>.
Especially take note of section E.3:<br>
<br>
&nbsp;&nbsp;&nbsp; OpenXPS Documents follow requirements set out in this Standard, as<br>
&nbsp;&nbsp;&nbsp; well as other normative references including the Open Packaging<br>
&nbsp;&nbsp;&nbsp; Conventions. Implementations may use the following steps to identify<br>
&nbsp;&nbsp;&nbsp; an unknown file or stream as an OpenXPS Document within an Open<br>
&nbsp;&nbsp;&nbsp; Packaging Conventions payload.<br>
<br>
The formatting on the next bit was mashed up. Is the following correct?<br>
<br>
&nbsp;&nbsp;&nbsp; 1. Test that the file or stream is a ZIP file<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by &sect;9.2 of the Open Packaging Conventions<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. First four bytes correspond to the local file header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signature defined in the .ZIP File Format Specification from<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKWARE, Inc., version 6.2.0 (2004)<br>
<br>
&nbsp;&nbsp;&nbsp; 2. Test that a valid Package Relationships zip item exists<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by &sect;8.3.4 of the Open Packaging Conventions<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type for the package relationships zip<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; item is correctly defined in the Content Types stream (see OPC<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &sect;8.1.2) as a relationships part<br>
<br>
&nbsp;&nbsp;&nbsp; 3. Test that the Package Relationships Part contains a relationship<br>
&nbsp;&nbsp;&nbsp; (see OPC &sect;8.3) whose Target attribute points to a valid<br>
&nbsp;&nbsp;&nbsp; FixedDocumentSequence Part<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. As required by &sect;10.2 of this Standard<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. Check that the content type for the FixedDocumentSequence<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part is correctly defined in the Content Types stream as a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FixedDocumentSequence part<br>
<br>
I'm not entirely clear on the need for this discussion in the template.
Do folks implementing the media type need to know this?<br>
<br>
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <div class="WordSection1">Applications which use this media :<o:p></o:p>
  <p class="MsoNormal">The application/oxps MIME type can be used to
identify CSTA XML<o:p></o:p>...</p>
  </div>
</blockquote>
<br>
That's a typo, yes? It should be application/OpenXPS?<br>
<br>
<blockquote
 cite="mid:FE6603D65048F44AB8F8955AE89A09B9172EE107@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com"
 type="cite">
  <div class="WordSection1">Person &amp; email address to contact for
further information:<o:p></o:p>
  <p class="MsoNormal">Ecma International Helpdesk<o:p></o:p></p>
  <p class="MsoNormal">Rue du Rhone114<o:p></o:p></p>
  <p class="MsoNormal">CH-1204 Geneva<o:p></o:p></p>
  <p class="MsoNormal">Switzerland<o:p></o:p></p>
  <p class="MsoNormal"><a class="moz-txt-link-abbreviated" href="mailto:helpdesk@ecma-international.org">helpdesk@ecma-international.org</a><o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Person to contact for further information :<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">1. Name : Ecma International Helpdesk<o:p></o:p></p>
  <p class="MsoNormal">2. Email : <a class="moz-txt-link-abbreviated" href="mailto:helpdesk@ecma-international.org">helpdesk@ecma-international.org</a><o:p></o:p></p>
  </div>
</blockquote>
<br>
Is that intended to be duplicated?<br>
<br>
Thanks for bringing me up to speed. We'll get it on the next agenda and
get it approved.<br>
<br>
pr<br>
<pre class="moz-signature" cols="72">-- 
Pete Resnick <a class="moz-txt-link-rfc2396E" href="http://www.qualcomm.com/~presnick/">&lt;http://www.qualcomm.com/~presnick/&gt;</a>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102</pre>
</body>
</html>

--------------060908020904040905050803--


Return-Path: <derhoermi@gmx.net>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C74FE0837 for <ietf-types@ietfc.amsl.com>; Tue, 12 Apr 2011 09:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.429
X-Spam-Level: 
X-Spam-Status: No, score=-4.429 tagged_above=-999 required=5 tests=[AWL=-1.830, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkvGmlXQwD14 for <ietf-types@ietfc.amsl.com>; Tue, 12 Apr 2011 09:43:29 -0700 (PDT)
Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by ietfc.amsl.com (Postfix) with ESMTP id 06E09E072E for <ietf-types@ietf.org>; Tue, 12 Apr 2011 09:43:26 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora2.lax.icann.org (8.13.8/8.13.8) with SMTP id p3CGh5Mj001235 for <ietf-types@iana.org>; Tue, 12 Apr 2011 09:43:25 -0700
Received: (qmail invoked by alias); 12 Apr 2011 16:43:02 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp025) with SMTP; 12 Apr 2011 18:43:02 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/dojc2bZTdYpluYtKZLShnmUWeNlMn0UU540EPtH e1KFtXrVBVDCvu
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Makoto Saito <ma.saito@nttv6.jp>
Date: Tue, 12 Apr 2011 18:43:06 +0200
Message-ID: <t1u8q6l7b2ju1v61qrl10u3ca1rss5tqvl@hive.bjoern.hoehrmann.de>
References: <4DA31E75.9060703@nttv6.jp> <lr96q61np2smiqllptcgr8r96vk1aoqstp@hive.bjoern.hoehrmann.de> <4DA4743E.6050809@nttv6.jp>
In-Reply-To: <4DA4743E.6050809@nttv6.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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Tue, 12 Apr 2011 09:43:26 -0700 (PDT)
Cc: ietf-types@iana.org, Masashi TOYAMA <toyama.masashi@lab.ntt.co.jp>, Dan Wing <dwing@cisco.com>
Subject: Re: [ietf-types] about media subtypes ike-esp and ike-esp-udpencap
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Apr 2011 16:43:30 -0000

* Makoto Saito wrote:
>Actually, we are not intending to revise RFC6193.
>In the RFC, we described ike-esp and ike-esp-udpencap as
>media subtypes: http://tools.ietf.org/html/rfc6193#section-10
>but they were registered as SDP attributes.

I do not think it is obvious from RFC 6193 that it includes a proposal
for a new internet media type (you don't have the proper template, you
don't reference BCP 13 / RFC 4288, no `application/ike-esp` string as
it would typically be rendered in MIME-like environments, I don't see
much of a definition how to construct `application/ike-esp` entities,
as in, what's the first byte, what's the second byte, and so on), and
RFC 4288 essentially requires that the registration template to be in
the standards document.

The easy way to resolve this is by re-publishing the document with the
necessary information included in the document. It may also be possible
to address this through errata, and it may also be possible that the
IESG is satisfied that the requirements for registration have been met
without changes to the document or errata, but that's not how things
are supposed to work as far as I am aware. If you do not want to
re-publish the document, I would recommend asking the IESG for guidance.
-- 
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: <ma.saito@nttv6.jp>
X-Original-To: ietf-types@ietfc.amsl.com
Delivered-To: ietf-types@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFAEBE06B9 for <ietf-types@ietfc.amsl.com>; Tue, 12 Apr 2011 08:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q4KVzMYyCWT for <ietf-types@ietfc.amsl.com>; Tue, 12 Apr 2011 08:48:40 -0700 (PDT)
Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by ietfc.amsl.com (Postfix) with ESMTP id 02FAFE07EA for <ietf-types@ietf.org>; Tue, 12 Apr 2011 08:48:39 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3CFmHCi030955 for <ietf-types@iana.org>; Tue, 12 Apr 2011 08:48:39 -0700
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 24696BDC57; Wed, 13 Apr 2011 00:48:14 +0900 (JST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 0892E7049B; Wed, 13 Apr 2011 00:48:14 +0900 (JST)
Message-ID: <4DA4743E.6050809@nttv6.jp>
Date: Wed, 13 Apr 2011 00:48:14 +0900
From: Makoto Saito <ma.saito@nttv6.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <4DA31E75.9060703@nttv6.jp> <lr96q61np2smiqllptcgr8r96vk1aoqstp@hive.bjoern.hoehrmann.de>
In-Reply-To: <lr96q61np2smiqllptcgr8r96vk1aoqstp@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [IPv6:2620:0:2d0:1::37]); Tue, 12 Apr 2011 08:48:39 -0700 (PDT)
Cc: ietf-types@iana.org, Masashi TOYAMA <toyama.masashi@lab.ntt.co.jp>, Dan Wing <dwing@cisco.com>
Subject: Re: [ietf-types] about media subtypes ike-esp and ike-esp-udpencap
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Apr 2011 15:48:41 -0000

Hello Bjoern,

Thank you for your reply to my question.
Actually, we are not intending to revise RFC6193.
In the RFC, we described ike-esp and ike-esp-udpencap as
media subtypes: http://tools.ietf.org/html/rfc6193#section-10
but they were registered as SDP attributes.

Before publication, we exchanged a few mails with Alexey Melnikov
about how we can register these identifiers as follows:

(2011/03/08 6:53), Alexey Melnikov wrote:
 > Makoto Saito wrote:
 >
 >> Dear Alexey,
 >
 > Dear Makoto,
 >
 >> Thank you very much for your comments.
 >> I modified the template as attached, following your advices
 >> (I also replaced RFC 4306 by RFC 5996 for IKEv2).
 >> Is it sufficiently ready for submission?
 >> If so, I'm going to send it to ietf-types@iana.org.
 >> Please let me know if there are any steps before that.
 >
 > [...]
 >
 >> Applications that use this media type:
 >>
 >> The ike-esp media type indicates IKE and IPsec ESP as a VPN session.
 >> An IKE control channel is established using SIP and SDP offer/answer
 >> model.
 >>
 > I think it would be clearer if you say that this media type represents a
 > sequence of IKE packets. (Did I get this right?)
 > And the same comment applies to the other registration.
 >
 > But otherwise this looks fine to me.
 >
 >

And he also commented as follows:

>>>   Authors:
>>>
>>>        Makoto Saito (ma.saito@nttv6.jp)
>>>        Dan Wing (dwing@cisco.com)
>>>        Masashi Toyama (toyama.masashi@lab.ntt.co.jp)
>>>
>>>   Change controller:
>>
>> Should the last field be IESG?
>
> Actually your draft is an Independent Submission through RFC Editor, so maybe that is not quite right.
> But if you are happy for IESG to be the Change Controller, that wouldn't be a bad thing.
>
> Alternatively, one of you needs to be a Change Controller.


So we recognized these identifiers would be registered as
media subtypes, and in fact IESG didn't have objections to it.

Could you give us any instructions to solve our concern?

Best regards,

Makoto


(2011/04/12 1:20), Bjoern Hoehrmann wrote:
> * Makoto Saito wrote:
>> I asked you the registration of two media subtypes, application/ike-esp
>> and application/ike-esp-udpencap (from RFC 6193) the other day,
>> and I'm wondering how the process is going.
>> The RFC was released correctly, but these two subtypes were incorrectly
>> registered as SDP attributes as follows:
>> http://www.iana.org/assignments/sdp-parameters
>>
>> Instead, I think ike-esp and ike-esp-udpencap should be registered in
>> http://www.iana.org/assignments/media-types/application/
>>
>> Is there anything I can do for fixing them?
>
> http://tools.ietf.org/html/rfc6193 would be the RFC in question. If you
> really want to register Internet media types (and perhaps unregister the
> SDP attributes) the simple way to do that would be making a new RFC that
> obsolete RFC 6193 with the desired changes. It would be helpful though
> if you could explain why you think these identifiers should be Internet
> media types (just to be clear, media types would make sense if you, say,
> keep "ike-esp" files on your hard drive; it's not clear to me that this
> is the case here).



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 F038F28C137 for <ietf-types@core3.amsl.com>; Mon, 11 Apr 2011 09:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.985
X-Spam-Level: 
X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=-0.386, 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 3tB1LupIint2 for <ietf-types@core3.amsl.com>; Mon, 11 Apr 2011 09:20:20 -0700 (PDT)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by core3.amsl.com (Postfix) with ESMTP id F103628C147 for <ietf-types@ietf.org>; Mon, 11 Apr 2011 09:20:19 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora5.dc.icann.org (8.13.8/8.13.8) with SMTP id p3BGJwHr029002 for <ietf-types@iana.org>; Mon, 11 Apr 2011 09:20:19 -0700
Received: (qmail invoked by alias); 11 Apr 2011 16:19:57 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp033) with SMTP; 11 Apr 2011 18:19:57 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19ThgYSsAVTdsk4pllkhE+2qCUwBdLi3B0mhFyEaW OjWxrzDDko4ZtM
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Makoto Saito <ma.saito@nttv6.jp>
Date: Mon, 11 Apr 2011 18:20:00 +0200
Message-ID: <lr96q61np2smiqllptcgr8r96vk1aoqstp@hive.bjoern.hoehrmann.de>
References: <4DA31E75.9060703@nttv6.jp>
In-Reply-To: <4DA31E75.9060703@nttv6.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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 11 Apr 2011 09:20:19 -0700 (PDT)
Cc: ietf-types@iana.org, Masashi TOYAMA <toyama.masashi@lab.ntt.co.jp>, Dan Wing <dwing@cisco.com>
Subject: Re: [ietf-types] about media subtypes ike-esp and ike-esp-udpencap
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: Mon, 11 Apr 2011 16:20:22 -0000

* Makoto Saito wrote:
>I asked you the registration of two media subtypes, application/ike-esp
>and application/ike-esp-udpencap (from RFC 6193) the other day,
>and I'm wondering how the process is going.
>The RFC was released correctly, but these two subtypes were incorrectly
>registered as SDP attributes as follows:
>http://www.iana.org/assignments/sdp-parameters
>
>Instead, I think ike-esp and ike-esp-udpencap should be registered in
>http://www.iana.org/assignments/media-types/application/
>
>Is there anything I can do for fixing them?

http://tools.ietf.org/html/rfc6193 would be the RFC in question. If you
really want to register Internet media types (and perhaps unregister the
SDP attributes) the simple way to do that would be making a new RFC that
obsolete RFC 6193 with the desired changes. It would be helpful though
if you could explain why you think these identifiers should be Internet
media types (just to be clear, media types would make sense if you, say,
keep "ike-esp" files on your hard drive; it's not clear to me that this
is the case here).
-- 
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: <ma.saito@nttv6.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 1A00F3A6B23 for <ietf-types@core3.amsl.com>; Mon, 11 Apr 2011 08:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 mOFjip3lH0aY for <ietf-types@core3.amsl.com>; Mon, 11 Apr 2011 08:58:08 -0700 (PDT)
Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by core3.amsl.com (Postfix) with ESMTP id EB5653A6A72 for <ietf-types@ietf.org>; Mon, 11 Apr 2011 08:58:07 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id p3BFvl2Z031245 for <ietf-types@iana.org>; Mon, 11 Apr 2011 08:58:07 -0700
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id BBECBBDC5A; Tue, 12 Apr 2011 00:29:56 +0900 (JST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id AB0B070506; Tue, 12 Apr 2011 00:29:56 +0900 (JST)
Message-ID: <4DA31E75.9060703@nttv6.jp>
Date: Tue, 12 Apr 2011 00:29:57 +0900
From: Makoto Saito <ma.saito@nttv6.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: ietf-types@iana.org
Content-Type: multipart/mixed; boundary="------------050503060901010401040002"
X-Greylist: Delayed for 00:27:44 by milter-greylist-4.0 (pechora2.lax.icann.org [IPv6:2620:0:2d0:1::37]); Mon, 11 Apr 2011 08:58:07 -0700 (PDT)
Cc: Masashi TOYAMA <toyama.masashi@lab.ntt.co.jp>, Dan Wing <dwing@cisco.com>
Subject: [ietf-types] about media subtypes ike-esp and ike-esp-udpencap
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: Mon, 11 Apr 2011 15:58:10 -0000

This is a multi-part message in MIME format.
--------------050503060901010401040002
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Dear Administrators,

I asked you the registration of two media subtypes, application/ike-esp
and application/ike-esp-udpencap (from RFC 6193) the other day,
and I'm wondering how the process is going.
The RFC was released correctly, but these two subtypes were incorrectly
registered as SDP attributes as follows:
http://www.iana.org/assignments/sdp-parameters

Instead, I think ike-esp and ike-esp-udpencap should be registered in
http://www.iana.org/assignments/media-types/application/

Is there anything I can do for fixing them?
Just in case, I attach the registration templates again.

I appreciate if you kindly take care of my concern.

Best regards,

Makoto

--------------050503060901010401040002
Content-Type: text/plain;
 name="mime subtype ike-esp registration.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="mime subtype ike-esp registration.txt"

ICAgVG86IGlldGYtdHlwZXNAaWFuYS5vcmcNCiAgIFN1YmplY3Q6IFJlZ2lzdHJhdGlvbiBv
ZiBtZWRpYSB0eXBlIGFwcGxpY2F0aW9uL2lrZS1lc3ANCg0KICAgVHlwZSBuYW1lOg0KDQog
ICAgICAgIGFwcGxpY2F0aW9uDQoNCiAgIFN1YnR5cGUgbmFtZToNCg0KICAgICAgICBTdGFu
ZGFyZHMgdHJlZSAtIGlrZS1lc3ANCg0KICAgUmVxdWlyZWQgcGFyYW1ldGVyczoNCg0KICAg
ICAgICBObyBwYXJhbWV0ZXJzDQoNCiAgIE9wdGlvbmFsIHBhcmFtZXRlcnM6DQoNCiAgICAg
ICAgTm8gcGFyYW1ldGVycw0KDQogICBFbmNvZGluZyBjb25zaWRlcmF0aW9uczoNCg0KICAg
ICAgICBiaW5hcnkgKHRoaXMgbWVkaWEgdHlwZSBtYXkgcmVxdWlyZSBlbmNvZGluZyBvbiB0
cmFuc3BvcnRzIG5vdCBjYXBhYmxlIG9mIGhhbmRsaW5nIGJpbmFyeSkNCg0KICAgU2VjdXJp
dHkgY29uc2lkZXJhdGlvbnM6DQoNCiAgICAgICAgVGhlIHNhbWUgc2VjdXJpdHkgY29uc2lk
ZXJhdGlvbnMgYXBwbHkgYXMgZm9yIHRoZSBJS0UgcHJvdG9jb2wsDQogICAgICAgIHdoaWNo
IGlzIHNwZWNpZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9j
b2wgVmVyc2lvbiAyIChJS0V2MikuDQoNCiAgIEludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJh
dGlvbnM6DQoNCiAgICAgICAgSW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgSUtFIGlzIHNwZWNp
ZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lv
biAyIChJS0V2MikuDQoNCiAgIFB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOg0KDQogICAgICAg
IFJGQzU5OTYgLUludGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCBWZXJzaW9uIDIgKElL
RXYyKQ0KICAgICAgICBkcmFmdC1zYWl0by1tbXVzaWMtc2RwLWlrZSAtTWVkaWEgRGVzY3Jp
cHRpb24gZm9yIElLRSBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQ
KQ0KDQogICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBlOg0KDQogICAg
ICAgIFRoZSBpa2UtZXNwIG1lZGlhIHR5cGUgaW5kaWNhdGVzIGEgc2VxdWVuY2Ugb2YgSUtF
IHBhY2tldHMgd2hpY2ggc2V0cyB1cCBhbiBJUHNlYyBFU1Agc2Vzc2lvbi4NCiAgICAgICAg
QW4gSUtFIGNvbnRyb2wgY2hhbm5lbCBpcyBpbml0aWF0ZWQgdXNpbmcgU0lQIGFuZCBTRFAg
b2ZmZXIvYW5zd2VyIG1vZGVsLg0KDQogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uOg0KDQog
ICAgIE1hZ2ljIG51bWJlcihzKToNCg0KICAgICAgICBUaGVyZSBpcyBubyBzaW5nbGUgc3Ry
aW5nIHRoYXQgaXMgYWx3YXlzIHByZXNlbnQuDQoNCiAgICAgRmlsZSBleHRlbnNpb24ocyk6
DQoNCiAgICAgICAgTm8gc3BlY2lmaWMgZmlsZSBleHRlbnNpb24gaXMgcmVjb21tZW5kZWQg
Zm9yIHRoaXMgdHlwZS4NCg0KICAgICBNYWNpbnRvc2ggZmlsZSB0eXBlIGNvZGUocyk6DQoN
CiAgICAgICAgTm8gc3BlY2lmaWMgTWFjaW50b3NoIGZpbGUgdHlwZSBjb2RlcyBhcmUgcmVj
b21tZW5kZWQNCiAgICAgICAgZm9yIHRoaXMgdHlwZS4NCg0KICAgICBPYmplY3QgSWRlbnRp
ZmllcihzKToNCg0KICAgICAgICBObyBzcGVjaWZpYyBvYmplY3QgaWRlbnRpZmllciBpcyBk
ZWZpbmVkLg0KDQogICBQZXJzb24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1
cnRoZXIgaW5mb3JtYXRpb246DQoNCiAgICAgTmFtZToNCg0KICAgICAgICBNYWtvdG8gU2Fp
dG8NCg0KICAgICBFLW1haWw6DQoNCiAgICAgICAgbWEuc2FpdG9AbnR0djYuanANCg0KICAg
SW50ZW5kZWQgdXNhZ2U6DQoNCiAgICAgICAgQ09NTU9ODQoNCiAgIFJlc3RyaWN0aW9ucyBv
biB1c2FnZToNCg0KICAgICAgICBObyByZXN0cmljdGlvbnMgYXBwbHkuDQoNCiAgIEF1dGhv
cnM6DQoNCiAgICAgICAgTWFrb3RvIFNhaXRvIChtYS5zYWl0b0BudHR2Ni5qcCkNCiAgICAg
ICAgRGFuIFdpbmcgKGR3aW5nQGNpc2NvLmNvbSkNCiAgICAgICAgTWFzYXNoaSBUb3lhbWEg
KHRveWFtYS5tYXNhc2hpQGxhYi5udHQuY28uanApDQoNCiAgIENoYW5nZSBjb250cm9sbGVy
Og0KDQogICAgICAgIElFU0cNCg==
--------------050503060901010401040002
Content-Type: text/plain;
 name="mime subtype ike-esp-udpencap registration.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="mime subtype ike-esp-udpencap registration.txt"

ICAgVG86IGlldGYtdHlwZXNAaWFuYS5vcmcNCiAgIFN1YmplY3Q6IFJlZ2lzdHJhdGlvbiBv
ZiBtZWRpYSB0eXBlIGFwcGxpY2F0aW9uL2lrZS1lc3AtdWRwZW5jYXANCg0KICAgVHlwZSBu
YW1lOg0KDQogICAgICAgIGFwcGxpY2F0aW9uDQoNCiAgIFN1YnR5cGUgbmFtZToNCg0KICAg
ICAgICBTdGFuZGFyZHMgdHJlZSAtIGlrZS1lc3AtdWRwZW5jYXANCg0KICAgUmVxdWlyZWQg
cGFyYW1ldGVyczoNCg0KICAgICAgICBObyBwYXJhbWV0ZXJzDQoNCiAgIE9wdGlvbmFsIHBh
cmFtZXRlcnM6DQoNCiAgICAgICAgTm8gcGFyYW1ldGVycw0KDQogICBFbmNvZGluZyBjb25z
aWRlcmF0aW9uczoNCg0KICAgICAgICBiaW5hcnkgKHRoaXMgbWVkaWEgdHlwZSBtYXkgcmVx
dWlyZSBlbmNvZGluZyBvbiB0cmFuc3BvcnRzIG5vdCBjYXBhYmxlIG9mIGhhbmRsaW5nIGJp
bmFyeSkNCg0KICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQoNCiAgICAgICAgVGhlIHNh
bWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXBwbHkgYXMgZm9yIHRoZSBJS0UgcHJvdG9j
b2wsDQogICAgICAgIHdoaWNoIGlzIHNwZWNpZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBL
ZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lvbiAyIChJS0V2MikuDQoNCiAgIEludGVyb3Bl
cmFiaWxpdHkgY29uc2lkZXJhdGlvbnM6DQoNCiAgICAgICAgSW50ZXJvcGVyYWJpbGl0eSBv
ZiB0aGUgSUtFIGlzIHNwZWNpZmllZCBpbiBSRkM1OTk2IC1JbnRlcm5ldCBLZXkgRXhjaGFu
Z2UgUHJvdG9jb2wgVmVyc2lvbiAyIChJS0V2MikuDQoNCiAgIFB1Ymxpc2hlZCBzcGVjaWZp
Y2F0aW9uOg0KDQogICAgICAgIFJGQzU5OTYgLUludGVybmV0IEtleSBFeGNoYW5nZSBQcm90
b2NvbCBWZXJzaW9uIDIgKElLRXYyKQ0KICAgICAgICBkcmFmdC1zYWl0by1tbXVzaWMtc2Rw
LWlrZSAtTWVkaWEgRGVzY3JpcHRpb24gZm9yIElLRSBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlw
dGlvbiBQcm90b2NvbCAoU0RQKQ0KDQogICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBt
ZWRpYSB0eXBlOg0KDQogICAgICAgIFRoZSBpa2UtZXNwLXVkcGVuY2FwIG1lZGlhIHR5cGUg
aW5kaWNhdGVzIGEgc2VxdWVuY2Ugb2YgSUtFIHBhY2tldHMgd2hpY2ggc3VwcG9ydHMgTkFU
LVRyYXZlcnNhbA0KICAgICAgICBhbmQgc2V0cyB1cCBhbiBJUHNlYyBFU1Agc2Vzc2lvbiBv
ciBhIFVEUCBlbmNhcHN1bGF0aW9uIG9mIElQc2VjIEVTUCBzZXNzaW9uLCB1c2luZyBwcm9j
ZWR1cmVzDQogICAgICAgIGRlc2NyaWJlZCBpbiBSRkMzOTQ3Lg0KICAgICAgICBBbiBJS0Ug
Y29udHJvbCBjaGFubmVsIGlzIGluaXRpYXRlZCB1c2luZyBTSVAgYW5kIFNEUCBvZmZlci9h
bnN3ZXIgbW9kZWwuDQoNCiAgIEFkZGl0aW9uYWwgaW5mb3JtYXRpb246DQoNCiAgICAgTWFn
aWMgbnVtYmVyKHMpOg0KDQogICAgICAgIFRoZXJlIGlzIG5vIHNpbmdsZSBzdHJpbmcgdGhh
dCBpcyBhbHdheXMgcHJlc2VudC4NCg0KICAgICBGaWxlIGV4dGVuc2lvbihzKToNCg0KICAg
ICAgICBObyBzcGVjaWZpYyBmaWxlIGV4dGVuc2lvbiBpcyByZWNvbW1lbmRlZCBmb3IgdGhp
cyB0eXBlLg0KDQogICAgIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZShzKToNCg0KICAgICAg
ICBObyBzcGVjaWZpYyBNYWNpbnRvc2ggZmlsZSB0eXBlIGNvZGVzIGFyZSByZWNvbW1lbmRl
ZA0KICAgICAgICBmb3IgdGhpcyB0eXBlLg0KDQogICAgIE9iamVjdCBJZGVudGlmaWVyKHMp
Og0KDQogICAgICAgIE5vIHNwZWNpZmljIG9iamVjdCBpZGVudGlmaWVyIGlzIGRlZmluZWQu
DQoNCiAgIFBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBp
bmZvcm1hdGlvbjoNCg0KICAgICBOYW1lOg0KDQogICAgICAgIE1ha290byBTYWl0bw0KDQog
ICAgIEUtbWFpbDoNCg0KICAgICAgICBtYS5zYWl0b0BudHR2Ni5qcA0KDQogICBJbnRlbmRl
ZCB1c2FnZToNCg0KICAgICAgICBDT01NT04NCg0KICAgUmVzdHJpY3Rpb25zIG9uIHVzYWdl
Og0KDQogICAgICAgIE5vIHJlc3RyaWN0aW9ucyBhcHBseS4NCg0KICAgQXV0aG9yczoNCg0K
ICAgICAgICBNYWtvdG8gU2FpdG8gKG1hLnNhaXRvQG50dHY2LmpwKQ0KICAgICAgICBEYW4g
V2luZyAoZHdpbmdAY2lzY28uY29tKQ0KICAgICAgICBNYXNhc2hpIFRveWFtYSAodG95YW1h
Lm1hc2FzaGlAbGFiLm50dC5jby5qcCkNCg0KICAgQ2hhbmdlIGNvbnRyb2xsZXI6DQoNCiAg
ICAgICAgSUVTRw0K
--------------050503060901010401040002--


Return-Path: <simon.perreault@viagenie.ca>
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 5CB3028C0F6 for <ietf-types@core3.amsl.com>; Fri,  8 Apr 2011 06:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.279
X-Spam-Level: 
X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001]
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 69UxRjFvQv00 for <ietf-types@core3.amsl.com>; Fri,  8 Apr 2011 06:10:21 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by core3.amsl.com (Postfix) with ESMTP id 08F5028C0F2 for <ietf-types@ietf.org>; Fri,  8 Apr 2011 06:10:20 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p38DBjuB000568 for <ietf-types@iana.org>; Fri, 8 Apr 2011 09:12:05 -0400
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7AE9720D2C; Fri,  8 Apr 2011 09:11:44 -0400 (EDT)
Message-ID: <4D9F098F.5030902@viagenie.ca>
Date: Fri, 08 Apr 2011 09:11:43 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <4D9DF3B0.50405@viagenie.ca> <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de> <4D9E1E1B.9060800@viagenie.ca> <rt8sp6l619j8dcb2qju8aspk9k6kdjel0u@hive.bjoern.hoehrmann.de>
In-Reply-To: <rt8sp6l619j8dcb2qju8aspk9k6kdjel0u@hive.bjoern.hoehrmann.de>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Fri, 08 Apr 2011 09:12:05 -0400 (EDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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: Fri, 08 Apr 2011 13:10:22 -0000

On 2011-04-07 16:55, Bjoern Hoehrmann wrote:
> for the benefit of other reviewers, it might be help-
> ful to have an updated template with the changes applied (but do not go
> out of your way producing it, these being mostly trivial changes).

Here you go:

   Type name:  application

   Subtype name:  vcard+xml

   Required parameters:  none

   Optional parameters:  charset as defined for application/xml in
      [RFC3023]; per [RFC3023], use of the charset parameter with the
      value "utf-8" is "STRONGLY RECOMMENDED"

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in [RFC3023]

   Security considerations:  This media type has all of the security
      considerations described in [RFC3023], plus those listed in
      Section 7 of [draft-ietf-vcarddav-vcardxml-09].

   Interoperability considerations:  This media type provides an
      alternative syntax to vCard data [draft-ietf-vcarddav-vcardrev-18]
      based on XML.

   Published specification:  [draft-ietf-vcarddav-vcardxml-09]

   Applications which use this media type:  Applications that currently
      make use of the text/vcard media type can use this as an
      alternative.  In general, applications that maintain or process
      contact information can use this media type.

   Additional information:

      Magic number(s):  none

      File extension(s):  XML data should use ".xml" as the file
         extension.

      Macintosh file type code(s):  none

   Person & email address to contact for further information:  Simon
      Perreault <simon.perreault@viagenie.ca>

   Intended usage:  COMMON

   Restrictions on usage:  none

   Author:  Simon Perreault

   Change controller:  IETF

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


Return-Path: <simon.perreault@viagenie.ca>
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 76D943A6925 for <ietf-types@core3.amsl.com>; Fri,  8 Apr 2011 06:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 7XlmV2SvstVG for <ietf-types@core3.amsl.com>; Fri,  8 Apr 2011 06:04:56 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 75A5B3A6920 for <ietf-types@ietf.org>; Fri,  8 Apr 2011 06:04:55 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p38D6ICc017728 for <ietf-types@iana.org>; Fri, 8 Apr 2011 06:06:39 -0700
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 287A820D2C; Fri,  8 Apr 2011 09:06:17 -0400 (EDT)
Message-ID: <4D9F0848.8070307@viagenie.ca>
Date: Fri, 08 Apr 2011 09:06:16 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Chris Lilley <chris@w3.org>
References: <4D9DF3B0.50405@viagenie.ca> <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de> <4D9E1E1B.9060800@viagenie.ca> <1866534630.20110408030443@w3.org>
In-Reply-To: <1866534630.20110408030443@w3.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:1::39]); Fri, 08 Apr 2011 06:06:39 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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: Fri, 08 Apr 2011 13:04:57 -0000

On 2011-04-07 21:04, Chris Lilley wrote:
> On Thursday, April 7, 2011, 10:27:07 PM, Simon wrote:
> SP> On 2011-04-07 16:12, Bjoern Hoehrmann wrote:
>>> If you do not specify an optional 'charset' parameter, it is
>>> ambiguous what the encoding of
>>> `application/vcard+xml;charset=...` is; if you only read the
>>> registration you are likely to ignore the parameter, while, if 
>>> you read RFC 3023 you expect the 'charset' parameter to specify
>>> the en- coding, which has interoperability and security
>>> implications.
> 
> SP> I will update this to read:
> 
> SP>    Optional parameters: charset as defined for application/xml
> in SP>       [RFC3023]; per [RFC3023], use of the charset parameter
> with the SP>       value "utf-8" is "STRONGLY RECOMMENDED"
> 
> That verbatim quote from RFC3023 will probably suffice to deal with
> Bjoern's criticism, but as I just pointed out in another message to
> this thread his criticism is outdated and unwarranted, and raises
> security issues (as he himself points out).

So it looks like an update to RFC3023 would be needed?

In the meantime I think I'll go with the current consensus (RFC3023).

Thanks!
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


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 D198A3A6A45 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 23:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 tLhwp1eI5Ygn for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 23:52:23 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by core3.amsl.com (Postfix) with ESMTP id 2CF173A69F8 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 23:52:21 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p386rjBa015279 for <ietf-types@iana.org>; Fri, 8 Apr 2011 02:54:06 -0400
Received: from brouwer.fritz.box (srbk-5d8073f9.pool.mediaWays.net [93.128.115.249]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0Lsauz-1PxGob383d-012Jl5; Fri, 08 Apr 2011 08:53:37 +0200
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: <4D9E2359.1060603@viagenie.ca>
Date: Fri, 8 Apr 2011 08:53:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <43E252F3-1CA9-42B3-B723-B6AE86283988@hoplahup.net>
References: <4D9DF3B0.50405@viagenie.ca> <C6DD4D23-5940-48F8-8FDB-7087067B95B0@hoplahup.net> <4D9E2054.7000004@viagenie.ca> <4D9E2359.1060603@viagenie.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:20EmYjGxihqPhrlBLYEX0x9+hZc5BRgu7ggEOjnCV8b +H56lfEkaQNTzfWg9cQcoRrZ/PlxMPO+wS789mV72ephFf+8BD w7lIIxN6wqD6Qpy0KYVsfwiLoOUiZOu5uY+WOOeNASc1m9xFmj Sao5u/RhRphRCaF+VjozhmpPXnv0DuSFivbOgSHW7kFeWChf4V RQnbHJ+7dNhbKxpzed/WqzkTS9G1LWOjVHX8de7xZE=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Fri, 08 Apr 2011 02:54:06 -0400 (EDT)
Cc: Pete Resnick <presnick@qualcomm.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, "ietf-types@iana.org" <ietf-types@iana.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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: Fri, 08 Apr 2011 06:52:23 -0000

Le 7 avr. 2011 =E0 22:49, Simon Perreault a =E9crit :

>>> See OpenXPS, SVG, or MathML recent registrations that you could =
follow for the how-to.
>>=20
>> May I pick "application/vcard+xml" as clipboard name?

I believe most Unix window-managers accept media types as clipboard =
names... I have no visible evidence yet.
I think not on Windows.
	http://msdn.microsoft.com/en-us/library/ms649013.aspx
On Mac, it should be a UTI.
	=
http://developer.apple.com/mac/library/documentation/FileManagement/Concep=
tual/understanding_utis/

> After reading a bit more on this, I have a few more questions...
> - Is this something that users will see?

they would see the *effect* of that only, that an application picks the =
right flavour (e.g. not the vcard's plain text).

>  - If so, why not simply add a "Descriptive Name" field to the media
> type registration? This doesn't seem specific to clipboards to me...

No, there's no intent to create a user language here.

> - Why does it need to be part of the media type registration? Why does =
it need to be registered at all?

So that applications that don't coordinate beforehand are still able to =
interoperate writing to and reading from the clipboard.

> Pointers to documentation would be very appreciated.

See above.

As for examples:
SVG:
  http://www.ietf.org/mail-archive/web/ietf-types/current/msg01147.html
  http://www.w3.org/TR/SVG/mimereg.html
MathML:
  http://www.w3.org/TR/MathML3/appendixb.html

paul=


Return-Path: <chris@w3.org>
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 3514C3A695A for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 18:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 6UkEkefS+KHa for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 18:34:43 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by core3.amsl.com (Postfix) with ESMTP id EB7173A68D2 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 18:34:42 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p381a7AY003079 for <ietf-types@iana.org>; Thu, 7 Apr 2011 21:36:27 -0400
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from <chris@w3.org>) id 1Q808f-0005rB-Ll; Thu, 07 Apr 2011 21:05:29 -0400
Date: Fri, 8 Apr 2011 03:02:28 +0200
From: Chris Lilley <chris@w3.org>
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <607055911.20110408030228@w3.org>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
In-Reply-To: <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de>
References: <4D9DF3B0.50405@viagenie.ca> <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Thu, 07 Apr 2011 21:36:27 -0400 (EDT)
Cc: Simon Perreault <simon.perreault@viagenie.ca>, "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <chris@w3.org>
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: Fri, 08 Apr 2011 01:34:44 -0000

On Thursday, April 7, 2011, 10:12:00 PM, Bjoern wrote:

BH> * Simon Perreault wrote:
>>   Type name:  application

>>   Subtype name:  vcard+xml

>>   Required parameters:  none

>>   Optional parameters:  none

BH> If you do not specify an optional 'charset' parameter, it is ambiguous
BH> what the encoding of `application/vcard+xml;charset=...` is; 

Or not; the XML specification amply covers how to determine the encoding of an XML document.

BH> if you only
BH> read the registration you are likely to ignore the parameter, 

The registration says there is no such parameter. Nor is it required for the application/* tree.

BH> while, if
BH> you read RFC 3023 you expect the 'charset' parameter to specify the en-
BH> coding, which has interoperability and security implications.

Considerations which don't arise if there is no such parameter, such as in this registration request.

Which is why the Technical Architecture group recommends against such use:
  "a receiving application can, with very high reliability, determine the encoding of an XML document by reading it, without reference to any external headers "

and

  "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction to use the charset is misplaced for application/xml and for non-text "+xml" types."

http://www.w3.org/2001/tag/2002/0129-mime#char-encoding


BH> If this omission of the parameter is not an oversight, I would expect a
BH> rationale for its omission as part of the review request and expect the
BH> interoperability and security issues that arise from this to be noted in
BH> the specification.

Perhaps you can point to which part of the Internet Media types registration process *requires* a charset parameter for the application/* tree and why adding one would be a good idea when, as you point out, adding a charset parameter and expecting it to overide the encoding declared in the XML instance has poor interoperability and raises security worries as well.

In other words, I strongly suspect that the 'omission' of this problematic parameter is not an oversight but a rational technical decision.

(Omitting comments with which I agree).

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups



Return-Path: <chris@w3.org>
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 C6C893A6996 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 18:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 G3SXdqU+3Cci for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 18:34:23 -0700 (PDT)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by core3.amsl.com (Postfix) with ESMTP id 915413A68D2 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 18:34:22 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id p381Zlvk031908 for <ietf-types@iana.org>; Thu, 7 Apr 2011 18:36:07 -0700
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from <chris@w3.org>) id 1Q80Aq-0005z8-5d; Thu, 07 Apr 2011 21:07:44 -0400
Date: Fri, 8 Apr 2011 03:04:43 +0200
From: Chris Lilley <chris@w3.org>
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <1866534630.20110408030443@w3.org>
To: Simon Perreault <simon.perreault@viagenie.ca>
In-Reply-To: <4D9E1E1B.9060800@viagenie.ca>
References: <4D9DF3B0.50405@viagenie.ca> <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de> <4D9E1E1B.9060800@viagenie.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Delayed for 00:30:12 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Thu, 07 Apr 2011 18:36:07 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <chris@w3.org>
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: Fri, 08 Apr 2011 01:34:23 -0000

On Thursday, April 7, 2011, 10:27:07 PM, Simon wrote:

SP> On 2011-04-07 16:12, Bjoern Hoehrmann wrote:
>>>   Optional parameters:  none

>> If you do not specify an optional 'charset' parameter, it is ambiguous
>> what the encoding of `application/vcard+xml;charset=...` is; if you only
>> read the registration you are likely to ignore the parameter, while, if
>> you read RFC 3023 you expect the 'charset' parameter to specify the en-
>> coding, which has interoperability and security implications.

SP> I will update this to read:

SP>    Optional parameters: charset as defined for application/xml in
SP>       [RFC3023]; per [RFC3023], use of the charset parameter with the
SP>       value "utf-8" is "STRONGLY RECOMMENDED"

That verbatim quote from RFC3023 will probably suffice to deal with Bjoern's criticism, but as I just pointed out in another message to this thread his criticism is outdated and unwarranted, and raises security issues (as he himself points out).



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups



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 468B23A6977 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 14:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.008
X-Spam-Level: 
X-Spam-Status: No, score=-3.008 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 M92P3RxXxGN3 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 14:01:33 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id 47CC33A6974 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 14:01:31 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora1.lax.icann.org (8.13.8/8.13.8) with SMTP id p37L2edH016679 for <ietf-types@iana.org>; Thu, 7 Apr 2011 14:03:01 -0700
Received: (qmail invoked by alias); 07 Apr 2011 21:02:39 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp071) with SMTP; 07 Apr 2011 23:02:39 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19BWGROWthB8PTG7lFo0v2G515EzzZuLfmI3MU4oh NqXbk0ZVbCCv1Y
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Simon Perreault <simon.perreault@viagenie.ca>
Date: Thu, 07 Apr 2011 23:02:40 +0200
Message-ID: <ke9sp6duv38kkochrtovipko6bkgegcrdu@hive.bjoern.hoehrmann.de>
References: <4D9DF3B0.50405@viagenie.ca> <C6DD4D23-5940-48F8-8FDB-7087067B95B0@hoplahup.net> <4D9E2054.7000004@viagenie.ca> <4D9E2359.1060603@viagenie.ca>
In-Reply-To: <4D9E2359.1060603@viagenie.ca>
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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 07 Apr 2011 14:03:01 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 21:01:34 -0000

* Simon Perreault wrote:
>On 2011-04-07 16:36, Simon Perreault wrote:
>> On 2011-04-07 16:14, Paul Libbrecht wrote:
>>> may I suggest to add clipboard flavor names?
>>> It would be useful I feel to allow applications to rely on predefined clipboard names.
>>>
>>> See OpenXPS, SVG, or MathML recent registrations that you could follow for the how-to.
>> 
>> May I pick "application/vcard+xml" as clipboard name?
>
>After reading a bit more on this, I have a few more questions...
>
>- Is this something that users will see?
>  - If so, why not simply add a "Descriptive Name" field to the media
>type registration? This doesn't seem specific to clipboards to me...
>
>- Why does it need to be part of the media type registration? Why does
>it need to be registered at all?
>
>Pointers to documentation would be very appreciated.

If you do not know, and nobody can show, that all implementations of the
"application/vcard+xml" format that also support some kind of clipboard
use "..." as the clipboard name, I do not think you should include any-
thing about clipboard names and let others sort that out. Formally, this
information is not needed. (And no, at least on Windows users would not
see what I think is meant by "clipboard name").
-- 
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: <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 7BFA53A6982 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.033
X-Spam-Level: 
X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[AWL=-0.434, 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 d9J4vwNHK7o0 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:54:12 -0700 (PDT)
Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by core3.amsl.com (Postfix) with ESMTP id 0D3D13A6974 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 13:54:11 -0700 (PDT)
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 p37KtZOW011358 for <ietf-types@iana.org>; Thu, 7 Apr 2011 13:55:55 -0700
Received: (qmail invoked by alias); 07 Apr 2011 20:55:33 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp044) with SMTP; 07 Apr 2011 22:55:33 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18FB3oOKNMFH9ik9uuRBAWz9cFpLZbHCKKfG9z+oc nBySi9tAUAwgCL
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Simon Perreault <simon.perreault@viagenie.ca>
Date: Thu, 07 Apr 2011 22:55:34 +0200
Message-ID: <rt8sp6l619j8dcb2qju8aspk9k6kdjel0u@hive.bjoern.hoehrmann.de>
References: <4D9DF3B0.50405@viagenie.ca> <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de> <4D9E1E1B.9060800@viagenie.ca>
In-Reply-To: <4D9E1E1B.9060800@viagenie.ca>
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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Thu, 07 Apr 2011 13:55:56 -0700 (PDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 20:54:13 -0000

* Simon Perreault wrote:
>On 2011-04-07 16:12, Bjoern Hoehrmann wrote:
>>>   Security considerations:  See Section 7 of [draft-ietf-vcarddav-
>>>      vcardrev-08].
>> 
>> This reference appears to be outdated. In -18 I don't see a reference to
>> RFC 3023 which is RECOMMENDED in RFC 3023.
>
>There's a typo, sorry about that. I meant [draft-ietf-vcarddav-vcardxml-08].

That would make the reference up to date, but there is still a missing
reference to RFC 3023 which notes

   These registrations SHOULD specify that the XML-based media type
   being registered has all of the security considerations described in
   RFC 3023 plus any additional considerations specific to that media
   type.

which does not seem to be met with either reference. If you update the
proposed registration with the changes you've mentioned, this largely
looks okay to me; for the benefit of other reviewers, it might be help-
ful to have an updated template with the changes applied (but do not go
out of your way producing it, these being mostly trivial changes).
-- 
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: <simon.perreault@viagenie.ca>
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 66CA13A68C3 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level: 
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 SLMOcvllJDoh for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:48:08 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id DEC2F3A6982 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 13:48:07 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p37KnVYi010167 for <ietf-types@iana.org>; Thu, 7 Apr 2011 13:49:51 -0700
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 79D8821EBE; Thu,  7 Apr 2011 16:49:30 -0400 (EDT)
Message-ID: <4D9E2359.1060603@viagenie.ca>
Date: Thu, 07 Apr 2011 16:49:29 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Paul Libbrecht <paul@hoplahup.net>
References: <4D9DF3B0.50405@viagenie.ca> <C6DD4D23-5940-48F8-8FDB-7087067B95B0@hoplahup.net> <4D9E2054.7000004@viagenie.ca>
In-Reply-To: <4D9E2054.7000004@viagenie.ca>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:1::39]); Thu, 07 Apr 2011 13:49:51 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, "ietf-types@iana.org" <ietf-types@iana.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 20:48:09 -0000

On 2011-04-07 16:36, Simon Perreault wrote:
> On 2011-04-07 16:14, Paul Libbrecht wrote:
>> may I suggest to add clipboard flavor names?
>> It would be useful I feel to allow applications to rely on predefined clipboard names.
>>
>> See OpenXPS, SVG, or MathML recent registrations that you could follow for the how-to.
> 
> May I pick "application/vcard+xml" as clipboard name?

After reading a bit more on this, I have a few more questions...

- Is this something that users will see?
  - If so, why not simply add a "Descriptive Name" field to the media
type registration? This doesn't seem specific to clipboards to me...

- Why does it need to be part of the media type registration? Why does
it need to be registered at all?

Pointers to documentation would be very appreciated.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


Return-Path: <simon.perreault@viagenie.ca>
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 28E183A6977 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level: 
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 YTVArpEZePUQ for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:35:15 -0700 (PDT)
Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 8B6A23A68C3 for <ietf-types@ietf.org>; Thu,  7 Apr 2011 13:35:14 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p37KacvD009716 for <ietf-types@iana.org>; Thu, 7 Apr 2011 13:36:58 -0700
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7887E21BDD; Thu,  7 Apr 2011 16:36:37 -0400 (EDT)
Message-ID: <4D9E2054.7000004@viagenie.ca>
Date: Thu, 07 Apr 2011 16:36:36 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Paul Libbrecht <paul@hoplahup.net>
References: <4D9DF3B0.50405@viagenie.ca> <C6DD4D23-5940-48F8-8FDB-7087067B95B0@hoplahup.net>
In-Reply-To: <C6DD4D23-5940-48F8-8FDB-7087067B95B0@hoplahup.net>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:1::39]); Thu, 07 Apr 2011 13:36:58 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, "ietf-types@iana.org" <ietf-types@iana.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 20:35:16 -0000

On 2011-04-07 16:14, Paul Libbrecht wrote:
> may I suggest to add clipboard flavor names?
> It would be useful I feel to allow applications to rely on predefined clipboard names.
> 
> See OpenXPS, SVG, or MathML recent registrations that you could follow for the how-to.

May I pick "application/vcard+xml" as clipboard name?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


Return-Path: <simon.perreault@viagenie.ca>
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 3176D3A697A for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 TRFFpkHsYHLN for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:25:46 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by core3.amsl.com (Postfix) with ESMTP id A51D53A690A for <ietf-types@ietf.org>; Thu,  7 Apr 2011 13:25:45 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p37KR9us023188 for <ietf-types@iana.org>; Thu, 7 Apr 2011 16:27:30 -0400
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 504C620E32; Thu,  7 Apr 2011 16:27:08 -0400 (EDT)
Message-ID: <4D9E1E1B.9060800@viagenie.ca>
Date: Thu, 07 Apr 2011 16:27:07 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <4D9DF3B0.50405@viagenie.ca> <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de>
In-Reply-To: <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Thu, 07 Apr 2011 16:27:30 -0400 (EDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 20:25:47 -0000

On 2011-04-07 16:12, Bjoern Hoehrmann wrote:
>>   Optional parameters:  none
> 
> If you do not specify an optional 'charset' parameter, it is ambiguous
> what the encoding of `application/vcard+xml;charset=...` is; if you only
> read the registration you are likely to ignore the parameter, while, if
> you read RFC 3023 you expect the 'charset' parameter to specify the en-
> coding, which has interoperability and security implications.

I will update this to read:

   Optional parameters: charset as defined for application/xml in
      [RFC3023]; per [RFC3023], use of the charset parameter with the
      value "utf-8" is "STRONGLY RECOMMENDED"

>>   Encoding considerations:  Same as for application/xml.
> 
> This should use the wording given in RFC 3023 section 7.1.

I will update this to read:

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in [RFC3023]

>>   Security considerations:  See Section 7 of [draft-ietf-vcarddav-
>>      vcardrev-08].
> 
> This reference appears to be outdated. In -18 I don't see a reference to
> RFC 3023 which is RECOMMENDED in RFC 3023.

There's a typo, sorry about that. I meant [draft-ietf-vcarddav-vcardxml-08].

> This should probably be [RFCXXXX] if the idea is to advance the document
> to RFC status but I would expect the RFC editor to take care of that.

Yes, that is my expectation also.

>>   Applications which use this media type:  Applications that currently
>>      make use of the text/vcard media type can use this as an
>>      alternative.
> 
> I think this should identify the kind of application in addition to the
> indirect reference, something like "applications that maintain or pro-
> cess contact information" or something like that.

I will update this to read:

   Applications which use this media type:  Applications that currently
      make use of the text/vcard media type can use this as an
      alternative. In general, applications that maintain or process
      contact information can use this media type.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


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 2D71E28C15D for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
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 nOImrPvx4saN for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:13:57 -0700 (PDT)
Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id D3A693A690A for <ietf-types@ietf.org>; Thu,  7 Apr 2011 13:13:57 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p37KF7XU002780 for <ietf-types@iana.org>; Thu, 7 Apr 2011 13:15:27 -0700
Received: from brouwer.fritz.box (srbk-4db7ff69.pool.mediaWays.net [77.183.255.105]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MF8TX-1Q9rIM1yt1-00GIFZ; Thu, 07 Apr 2011 22:15:01 +0200
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: <4D9DF3B0.50405@viagenie.ca>
Date: Thu, 7 Apr 2011 22:14:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6DD4D23-5940-48F8-8FDB-7087067B95B0@hoplahup.net>
References: <4D9DF3B0.50405@viagenie.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
X-Mailer: Apple Mail (2.1082)
X-Provags-ID: V02:K0:wg3CD0AOT+NeK9rb2nofEnnqWx0ne4wKXRtKXyusXuv RJC/IENIXX9qTH012A3DYWHp/DCvQxKNOnVUxklSQhPOwGBRM+ 4cCDTNBIkBznx2r3W0iXBXXhN8QTonX+S0sLI/ytBhYsaBXR+i WXSj9w0NEdDbiWRQ+G6lNur2JobUTpPM3cMBqzi7qrX4G1c8X1 qB57JvfswSDy/91v6t91oa9nI30bWXwuPG1ONQ64L0=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 07 Apr 2011 13:15:27 -0700 (PDT)
Cc: Pete Resnick <presnick@qualcomm.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, "ietf-types@iana.org" <ietf-types@iana.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 20:13:59 -0000

Simon,

may I suggest to add clipboard flavor names?
It would be useful I feel to allow applications to rely on predefined =
clipboard names.

See OpenXPS, SVG, or MathML recent registrations that you could follow =
for the how-to.

paul




Le 7 avr. 2011 =E0 19:26, Simon Perreault a =E9crit :

>   Type name:  application
>=20
>   Subtype name:  vcard+xml
>=20
>   Required parameters:  none
>=20
>   Optional parameters:  none
>=20
>   Encoding considerations:  Same as for application/xml.
>=20
>   Security considerations:  See Section 7 of [draft-ietf-vcarddav-
>      vcardrev-08].
>=20
>   Interoperability considerations:  This media type provides an
>      alternative syntax to vCard data =
[draft-ietf-vcarddav-vcardrev-08]
>      based on XML.
>=20
>   Published specification:  [draft-ietf-vcarddav-vcardrev-08]
>=20
>   Applications which use this media type:  Applications that currently
>      make use of the text/vcard media type can use this as an
>      alternative.
>=20
>   Additional information:
>=20
>      Magic number(s):  none
>=20
>      File extension(s):  .xvc
>=20
>      Macintosh file type code(s):  none
>=20
>   Person & email address to contact for further information:  Simon
>      Perreault <simon.perreault@viagenie.ca>
>=20
>   Intended usage:  COMMON
>=20
>   Restrictions on usage:  none
>=20
>   Author:  Simon Perreault
>=20
>   Change controller:  IETF
>=20
> Simon
> --=20
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types



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 68EBC28C0DB for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.782
X-Spam-Level: 
X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
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 AmuepjJSkFDK for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 13:10:54 -0700 (PDT)
Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by core3.amsl.com (Postfix) with ESMTP id 27DF63A690A for <ietf-types@ietf.org>; Thu,  7 Apr 2011 13:10:52 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora6.dc.icann.org (8.13.8/8.13.8) with SMTP id p37KC17t010900 for <ietf-types@iana.org>; Thu, 7 Apr 2011 16:12:22 -0400
Received: (qmail invoked by alias); 07 Apr 2011 20:12:00 -0000
Received: from dslb-094-223-184-203.pools.arcor-ip.net (EHLO HIVE) [94.223.184.203] by mail.gmx.net (mp028) with SMTP; 07 Apr 2011 22:12:00 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+eP5M8r6+em3+f9CneoxSN0k6o1aUmrhvI7/EghP 6TTVsQBTQs+mGl
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Simon Perreault <simon.perreault@viagenie.ca>
Date: Thu, 07 Apr 2011 22:12:00 +0200
Message-ID: <u46sp6doqavc3bb5bqcg19174lsroddru9@hive.bjoern.hoehrmann.de>
References: <4D9DF3B0.50405@viagenie.ca>
In-Reply-To: <4D9DF3B0.50405@viagenie.ca>
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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Thu, 07 Apr 2011 16:12:22 -0400 (EDT)
Cc: "ietf-types@iana.org" <ietf-types@iana.org>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 20:10:57 -0000

* Simon Perreault wrote:
>   Type name:  application
>
>   Subtype name:  vcard+xml
>
>   Required parameters:  none
>
>   Optional parameters:  none

If you do not specify an optional 'charset' parameter, it is ambiguous
what the encoding of `application/vcard+xml;charset=...` is; if you only
read the registration you are likely to ignore the parameter, while, if
you read RFC 3023 you expect the 'charset' parameter to specify the en-
coding, which has interoperability and security implications.

If this omission of the parameter is not an oversight, I would expect a
rationale for its omission as part of the review request and expect the
interoperability and security issues that arise from this to be noted in
the specification.

>   Encoding considerations:  Same as for application/xml.

This should use the wording given in RFC 3023 section 7.1.

>   Security considerations:  See Section 7 of [draft-ietf-vcarddav-
>      vcardrev-08].

This reference appears to be outdated. In -18 I don't see a reference to
RFC 3023 which is RECOMMENDED in RFC 3023.

>   Interoperability considerations:  This media type provides an
>      alternative syntax to vCard data [draft-ietf-vcarddav-vcardrev-08]
>      based on XML.
>
>   Published specification:  [draft-ietf-vcarddav-vcardrev-08]

This should probably be [RFCXXXX] if the idea is to advance the document
to RFC status but I would expect the RFC editor to take care of that.

>   Applications which use this media type:  Applications that currently
>      make use of the text/vcard media type can use this as an
>      alternative.

I think this should identify the kind of application in addition to the
indirect reference, something like "applications that maintain or pro-
cess contact information" or something like that.
-- 
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: <simon.perreault@viagenie.ca>
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 21B8C3A695C for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 10:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001]
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 CDK8dVPiUaO6 for <ietf-types@core3.amsl.com>; Thu,  7 Apr 2011 10:40:56 -0700 (PDT)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by core3.amsl.com (Postfix) with ESMTP id 8B0E63A68EA for <ietf-types@ietf.org>; Thu,  7 Apr 2011 10:40:54 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p37HgI5n015695 for <ietf-types@iana.org>; Thu, 7 Apr 2011 13:42:38 -0400
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9D15C20E32; Thu,  7 Apr 2011 13:26:08 -0400 (EDT)
Message-ID: <4D9DF3B0.50405@viagenie.ca>
Date: Thu, 07 Apr 2011 13:26:08 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: "ietf-types@iana.org" <ietf-types@iana.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Delayed for 00:16:07 by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Thu, 07 Apr 2011 13:42:38 -0400 (EDT)
X-Mailman-Approved-At: Thu, 07 Apr 2011 12:58:17 -0700
Cc: Pete Resnick <presnick@qualcomm.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: [ietf-types] Registration of media type application/vcard+xml
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, 07 Apr 2011 17:40:57 -0000

   Type name:  application

   Subtype name:  vcard+xml

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  Same as for application/xml.

   Security considerations:  See Section 7 of [draft-ietf-vcarddav-
      vcardrev-08].

   Interoperability considerations:  This media type provides an
      alternative syntax to vCard data [draft-ietf-vcarddav-vcardrev-08]
      based on XML.

   Published specification:  [draft-ietf-vcarddav-vcardrev-08]

   Applications which use this media type:  Applications that currently
      make use of the text/vcard media type can use this as an
      alternative.

   Additional information:

      Magic number(s):  none

      File extension(s):  .xvc

      Macintosh file type code(s):  none

   Person & email address to contact for further information:  Simon
      Perreault <simon.perreault@viagenie.ca>

   Intended usage:  COMMON

   Restrictions on usage:  none

   Author:  Simon Perreault

   Change controller:  IETF

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca