Return-Path: 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 13C0A3A6856 for ; Mon, 31 Jan 2011 12:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 epAki7XVvfg1 for ; Mon, 31 Jan 2011 12:59:05 -0800 (PST) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by core3.amsl.com (Postfix) with ESMTP id A919D3A6814 for ; Mon, 31 Jan 2011 12:59:05 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p0VL1hgj031172 for ; Mon, 31 Jan 2011 16:02:03 -0500 Received: from ip-2-204-35-50.web.vodafone.de (ip-2-204-35-50.web.vodafone.de [2.204.35.50]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LeQLR-1QXMqk0bPR-00pmKX; Mon, 31 Jan 2011 22:01:41 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: Date: Mon, 31 Jan 2011 21:57:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Clubb X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:wqhB5rHxB+N8TnGRRkPw4B/WW8ktgAXsDFYmOqIWvWa /AADpfo0Kpl+b7ePVk6iNg/trgDSBfDVYxrqzWZWLesBakmAuN 2KKpXQ0ZLTJ3VaaSPevK053Bk96wtwDBso9cxX1oxgxQ5AV8Fn OtGtgFNcgFtuJqiRC2KET9mUrF7RBQbjkCpJjCd4/BmTFL1BCe UGvQFdCzQXOQdmMysVh1Zvu91Q3SycOUF5Cnco8UZo= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Mon, 31 Jan 2011 16:02:03 -0500 (EST) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:59:06 -0000 Hello Brian,=20 Le 31 janv. 2011 =E0 19:33, Brian Clubb a =E9crit : > While the OpenXPS package contains XML, the document itself requires = the hierarchical tree structure of pages and resources to be functional. = It is intended that only a complete OpenXPS document would ever be = posted to the clipboard. =20 Sure. Only well formed data here (and well formedness is more than = XML's). > Posting a fragment of an OpenXPS file to the clipboard would not be a = useful scenario in the same way that I understand it would work in = MathML or SVG. The resource tree in OpenXPS is integral to its = functionality. But that is clear. It doesn't remove the usefulness of such a thing. As I said, PDF is the preferred flavor for vector graphics on MacOSX. And rest assured that copying from a page of a 200 pages book with Apple = Preview does not create a PDF with many pages when copying a rectangle. Earlier examples on the mac of such transfers include the PICT format = and the Adobe "AIFB" (?? I think ??) format which was taken huge time to = be produced when you had just copied something, say, in PhotoShop and = was switching away from it (in MaOS 7-9, I suppose the same must have = been done on Windows). > For example, copying the XML for a fixed page out of one file onto the = clipboard would not take into account the image and font resources which = are stored in other locations in the OpenXPS file. =20 That's the duty of the clipboard exporter. A normal composition = programme can do that but viewers may have difficulties "at first", this = is true. In the very same fashion copying html in a browser also inlines all the = styles (even coming from very far from this element) when going out to, = say, an email or word-processing application (in html or rtf). > Furthermore, re-integrating that page markup into the structure of = another OpenXPS file would be extraordinarily complex. If one were to = wish to copy pages from one OpenXPS file to another, they would need to = create a complete OpenXPS package containing just the required pages = plus the required resources from the original OpenXPS package then post = the new OpenXPS file to the clipboard. The consuming application would = then be able to access that file and its resources reliably and = logically insert the pages and resources into their OpenXPS document = package as needed. I'm sure this can be and has been already done. > If an application such as an XPS Viewer were to allow selecting and = copying of the text or image elements displayed on the screen, that data = would be placed on the clipboard as text or whatever image format the = application chooses to provide, right. And one day that format might be openXPS. > but posting the markup for the selection to the clipboard would not = provide the relevant resource data and hierarchy and would thus be = unusable as OpenXPS at that point. no markup only copy. > I believe, then, that it is correct to say that the clipboard format = would always be a complete OpenXPS file with .oxps extension. It is the = only format for the clipboard that would provide the required = interoperability between OpenXPS-consuming applications. I think this is correct. paul= Return-Path: 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 3FD1A3A6C4D for ; Mon, 31 Jan 2011 12:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 pC9jMcJ5HJNx for ; Mon, 31 Jan 2011 12:55:41 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id 4CD7F3A6AEB for ; Mon, 31 Jan 2011 12:55:41 -0800 (PST) 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 p0VKwKWT017862 for ; Mon, 31 Jan 2011 12:58:41 -0800 Received: from ip-2-204-35-50.web.vodafone.de (ip-2-204-35-50.web.vodafone.de [2.204.35.50]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M2YnR-1Q0RqU1BuH-00sO4p; Mon, 31 Jan 2011 21:58:19 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: Date: Mon, 31 Jan 2011 21:56:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Clubb X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:5C3WDTURHtrVV475SoF4ocQlH/5pNkPtOu9kwsxS767 bLgsVa5xlWnuJYFjWlPu+R9YI+sgoz3+o/r0UlFaow+EJpNV+6 +qFJ+esZ7CQVgzqSxJbkBNfYLMBRvnQYaAdhykOXjSgwzh4Egu qKXnICVJ9YB/eMRhUvzlGr2On4RXrVz5h78vRdI6BXQoY7v9En WCDtiBa0mn7W7eP24TSqYHpz2vF8HbyCf/PdyoP1xo= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Mon, 31 Jan 2011 12:58:41 -0800 (PST) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:55:43 -0000 Hello Brian,=20 Le 31 janv. 2011 =E0 19:33, Brian Clubb a =E9crit : > While the OpenXPS package contains XML, the document itself requires = the hierarchical tree structure of pages and resources to be functional. = It is intended that only a complete OpenXPS document would ever be = posted to the clipboard. =20 Sure. Only well formed data here (and well formedness is more than = XML's). > Posting a fragment of an OpenXPS file to the clipboard would not be a = useful scenario in the same way that I understand it would work in = MathML or SVG. The resource tree in OpenXPS is integral to its = functionality. But that is clear. It doesn't remove the usefulness of such a thing. As I said, PDF is the preferred flavor for vector graphics on MacOSX. And rest assured that copying from a page of a 200 pages book with Apple = Preview does not create a PDF with many pages when copying a rectangle. Earlier examples on the mac of such transfers include the PICT format = and the Adobe "AIFB" (?? I think ??) format which was taken huge time to = be produced when you had just copied something, say, in PhotoShop and = was switching away from it (in MaOS 7-9, I suppose the same must have = been done on Windows). > For example, copying the XML for a fixed page out of one file onto the = clipboard would not take into account the image and font resources which = are stored in other locations in the OpenXPS file. =20 That's the duty of the clipboard exporter. A normal composition = programme can do that but viewers may have difficulties "at first", this = is true. In the very same fashion copying html in a browser also inlines all the = styles (even coming from very far from this element) when going out to, = say, an email or word-processing application (in html or rtf). > Furthermore, re-integrating that page markup into the structure of = another OpenXPS file would be extraordinarily complex. If one were to = wish to copy pages from one OpenXPS file to another, they would need to = create a complete OpenXPS package containing just the required pages = plus the required resources from the original OpenXPS package then post = the new OpenXPS file to the clipboard. The consuming application would = then be able to access that file and its resources reliably and = logically insert the pages and resources into their OpenXPS document = package as needed. I'm sure this can be and has been already done. > If an application such as an XPS Viewer were to allow selecting and = copying of the text or image elements displayed on the screen, that data = would be placed on the clipboard as text or whatever image format the = application chooses to provide, right. And one day that format might be openXPS. > but posting the markup for the selection to the clipboard would not = provide the relevant resource data and hierarchy and would thus be = unusable as OpenXPS at that point. no markup only copy. > I believe, then, that it is correct to say that the clipboard format = would always be a complete OpenXPS file with .oxps extension. It is the = only format for the clipboard that would provide the required = interoperability between OpenXPS-consuming applications. I think this is correct. paul= Return-Path: 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 0DB003A6C49 for ; Mon, 31 Jan 2011 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.785 X-Spam-Level: X-Spam-Status: No, score=-9.785 tagged_above=-999 required=5 tests=[AWL=0.814, 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 ojYrnxH4Dvqc for ; Mon, 31 Jan 2011 10:30:36 -0800 (PST) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by core3.amsl.com (Postfix) with ESMTP id C67E53A6C3F for ; Mon, 31 Jan 2011 10:30:32 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id p0VIXQHi026338 for ; Mon, 31 Jan 2011 10:33:47 -0800 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Jan 2011 10:33:25 -0800 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.270.2; Mon, 31 Jan 2011 10:33:25 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.252]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 31 Jan 2011 10:33:24 -0800 From: Brian Clubb To: Paul Libbrecht Thread-Topic: [ietf-types] Request for review of standards tree registration request for OpenXPS Thread-Index: AQHLs2yK9k1J+5/sU06pLsUqQi6DMZPiZR4wgAH+tQCABxnIkA== Date: Mon, 31 Jan 2011 18:33:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 31 Jan 2011 10:33:47 -0800 (PST) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:30:39 -0000 Paul, While the OpenXPS package contains XML, the document itself requires the hi= erarchical tree structure of pages and resources to be functional. It is i= ntended that only a complete OpenXPS document would ever be posted to the c= lipboard. Posting a fragment of an OpenXPS file to the clipboard would not= be a useful scenario in the same way that I understand it would work in Ma= thML or SVG. The resource tree in OpenXPS is integral to its functionality= . For example, copying the XML for a fixed page out of one file onto the clip= board would not take into account the image and font resources which are st= ored in other locations in the OpenXPS file. Furthermore, re-integrating t= hat page markup into the structure of another OpenXPS file would be extraor= dinarily complex. If one were to wish to copy pages from one OpenXPS file = to another, they would need to create a complete OpenXPS package containing= just the required pages plus the required resources from the original Open= XPS package then post the new OpenXPS file to the clipboard. The consuming= application would then be able to access that file and its resources relia= bly and logically insert the pages and resources into their OpenXPS documen= t package as needed. If an application such as an XPS Viewer were to allow selecting and copying= of the text or image elements displayed on the screen, that data would be = placed on the clipboard as text or whatever image format the application ch= ooses to provide, but posting the markup for the selection to the clipboard= would not provide the relevant resource data and hierarchy and would thus = be unusable as OpenXPS at that point. I believe, then, that it is correct to say that the clipboard format would = always be a complete OpenXPS file with .oxps extension. It is the only for= mat for the clipboard that would provide the required interoperability betw= een OpenXPS-consuming applications. Thanks! Brian -----Original Message----- From: Paul Libbrecht [mailto:paul@hoplahup.net]=20 Sent: Wednesday, January 26, 2011 1:45 PM To: Brian Clubb Cc: ietf-types@iana.org Subject: Re: [ietf-types] Request for review of standards tree registration= request for OpenXPS Le 26 janv. 2011 =E0 00:33, Brian Clubb a =E9crit : > For your feedback on changing certain responses to lower-case, I will do = so in my final submission. I appreciate your attention to detail on this m= atter. good. > For the comment on encoding, per rfc4288 section 4.8, the possible respon= ses here are 7bit, 8bit, binary, and framed. This response appears to be c= orrect for ZIP archives and matches a previous registration for Microsoft's= version of XPS (http://www.iana.org/assignments/media-types/application/vn= d.ms-xpsdocument). If there is some other consideration here, I am happy t= o make a note of it elsewhere in the template as needed. I am too little of an expert here. > As to the clipboard request, I checked the clipboard values on both Windo= ws OS and Mac OS. For Windows, the clipboard contains the full file path t= o the copied .oxps file as a string. On a Mac OS (10.x), the filename plus= extension is provided on the clipboard as "text / items". Since these con= ventions may change over time based on the OS independent of any changes to= OpenXPS, I am not certain this would be useful as part of the template. I'm afraid you misunderstood my request. The objective was to specify within this registration names that would deno= te one of the alternate representations of a fragment copied to clipboard t= o be encoded in OpenXPS. This would allow fragments to be stored by one app= lication in the clipboard at the copy command and to be read from the clipb= oard at the paste command. Lack of specifying this in the past for MathML has lead to a multitude of n= ames, mostly killing interoperability, with the last suggest being... put t= he XML in the text flavor (which is clearly wrong for, say, a mail). (see the MathML and SVG registrations for examples) paul Return-Path: 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 000F73A685C for ; Wed, 26 Jan 2011 14:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 3uOUHo3T2iRh for ; Wed, 26 Jan 2011 14:36:25 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 177263A6851 for ; Wed, 26 Jan 2011 14:36:25 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX2ZSP67CW00IQQK@mauve.mrochek.com> for ietf-types@ietf.org; Wed, 26 Jan 2011 14:39:24 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWP1MZKQSW007FL5@mauve.mrochek.com>; Wed, 26 Jan 2011 14:39:21 -0800 (PST) Message-id: <01NX2ZSO24GS007FL5@mauve.mrochek.com> Date: Wed, 26 Jan 2011 14:30:38 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Jan 2011 08:40:00 -0500" <20110126133945.GB6980@w3.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4D3F7F88.9060204@webr3.org> <01NX2320XRJO007FL5@mauve.mrochek.com> <20110126133945.GB6980@w3.org> To: Eric Prud'hommeaux DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296078488; bh=O1B1BihVdPqxfdFhMpfrnnzEDQ1v2ZYMGmc6K+Zvx5E=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=ARywIyRGLEsVc8t6pCJt1nEJRQoDf0pRCz/cDBSJeWnfXIVsLfaleFLPLTP5ixSjG WAcGAfbqfklpvlMETHyaG53kN1yBPSkhXTL+TG6j3gigZ007h/W7gQjlQpKVtFFETf pRn3OJ40W04mAuSf1ehs2sa66//XEHiwywDasccc= Cc: Tim Berners-Lee , ietf-types Subject: Re: [ietf-types] Update on the pending registration of text/n3 X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 22:36:27 -0000 > > In any case, I will point out that the text tree has restrictions besides being > > "human readable" - specifically, there's a requirment that line breaks be > > represented by CRLF sequences that precludes the use of charsets like UTF-16. I > > don't know if this is an issue for this type or not, but if it is you're better > > off staying in the application tree. > N3 and Turtle are UTF-8 formats (most at present being within us-ascii); > would it suffice to add text like:? > As the text media tree requires line breaks to be expressed as 0x0d 0x0a, > all occurances of 0x0d not followed by 0x0a and all occurances of 0x0a > not preceeded by 0x0d are replaced by 0x0d 0x0a. > I've attached a sample registration with this text added. I'm not sure such text is required, but it can't hurt. > I also had the impression that the CRLF restriction doesn't reflect > current practice (trying "line1\nline2\n" in several mail clients and > browsers) and that it was on the HTTP WG's agenda to relax that constraint. > In this case, such text would seem unnecessary. It's one thing to use bare CRs and LFs in place of CRLFs. That will often work, although there are also cases where it won't. But if you try this with actual UTF-16 text, the odds are good that it will fail, and moreover it can fail in ways that end up completely corrupting the content. But this appears to be a nonissue given you're using utf-8. > > >The application for text/rdf+n3 with the IANA registry is > > >pending as of 2006-02 as IANA #5004. There was an agreement to change > > >it to text/n3 as the rdf+ idea met with significant criticism. > > > > In regards to the "pending" registration, it appears to have been submitted to > > IANA on 30-Jan-2006 (for text/rdf+n3). It was forwarded to me for review on > > 3-Mar-2006. I responded on 6-Mar-2006 saying that (a) Since this is a standards > > tree registration it needed to go to the IESG and (b) The fact that no security > > considerations were provided was unlikely to be acceptable to the IESG. I > Ned, do you think it would suffice for Nathan to use the Security > considerations from http://www.w3.org/2010/01/Turtle/#sec-mediaReg ? > It references IRI and URI considerations and has a paragraph about > phishing (which I'd like to be useful in other registrations). First, I'll again note that I'm not the approver here, the IESG is. So the best I can do is tell you what I'd be looking for if I were the approver. With that caveat, I'd say that those considerations are great but not sufficient. The things I look for this section to do are to: (1) State whether or not the media type contains active or executable content. If the media type does contain executable content explain what measures have been taken to insure that it can be executed safely, e.g. a sandbox, safe operation set, signed content, etc. (2) State whether or not the information contained in the media type needs privacy or integrity services. (3) If the answer to (2) is yes, elaborate on any privacy or integrity services the media type itself provides. Other considerations like the ones you cite are of course welcome. Ned P.S. Maybe I screwed up and missed it somehow, but I don't think you included a template in your response. Return-Path: 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 6C0083A68A0 for ; Wed, 26 Jan 2011 13:42:40 -0800 (PST) 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] 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 JzbWq2YEz9tW for ; Wed, 26 Jan 2011 13:42:39 -0800 (PST) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by core3.amsl.com (Postfix) with ESMTP id 4FC8F3A6893 for ; Wed, 26 Jan 2011 13:42:39 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p0QLj3rp031627 for ; Wed, 26 Jan 2011 16:45:24 -0500 Received: from brouwer.fritz.box (srbk-5d807855.pool.mediaWays.net [93.128.120.85]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MXkkl-1PfoqY0uZT-00Wbbl; Wed, 26 Jan 2011 22:45:01 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: Date: Wed, 26 Jan 2011 22:45:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Clubb X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:6vwHt9bqbS3eOpFeVRwBQdYkBqF+H0RJVvlYp2VV7rh rEygFTle7nzEbitryVOloW/zY4G3En0047vncTTNmrHpmnH4Qg aTZnekwB3i9cggHKLQQWjYeryQa12PufBsEY94hxq/RN0z8knF tEbwMpMYNoAlR+IVdzhi537Ef3+DtMNmORINR1k5C6UsvB/dBN uzlnK53mMZYz08lACWpIhVCbmZMxDQEqOaSI2+hQu0= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Wed, 26 Jan 2011 16:45:24 -0500 (EST) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:42:40 -0000 Le 26 janv. 2011 =E0 00:33, Brian Clubb a =E9crit : > For your feedback on changing certain responses to lower-case, I will = do so in my final submission. I appreciate your attention to detail on = this matter. good. > For the comment on encoding, per rfc4288 section 4.8, the possible = responses here are 7bit, 8bit, binary, and framed. This response = appears to be correct for ZIP archives and matches a previous = registration for Microsoft's version of XPS = (http://www.iana.org/assignments/media-types/application/vnd.ms-xpsdocumen= t). If there is some other consideration here, I am happy to make a = note of it elsewhere in the template as needed. I am too little of an expert here. > As to the clipboard request, I checked the clipboard values on both = Windows OS and Mac OS. For Windows, the clipboard contains the full = file path to the copied .oxps file as a string. On a Mac OS (10.x), the = filename plus extension is provided on the clipboard as "text / items". = Since these conventions may change over time based on the OS independent = of any changes to OpenXPS, I am not certain this would be useful as part = of the template. I'm afraid you misunderstood my request. The objective was to specify within this registration names that would = denote one of the alternate representations of a fragment copied to = clipboard to be encoded in OpenXPS. This would allow fragments to be = stored by one application in the clipboard at the copy command and to be = read from the clipboard at the paste command. Lack of specifying this in the past for MathML has lead to a multitude = of names, mostly killing interoperability, with the last suggest = being... put the XML in the text flavor (which is clearly wrong for, = say, a mail). (see the MathML and SVG registrations for examples) paul= Return-Path: 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 0DF633A693F for ; Tue, 25 Jan 2011 22:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, J_CHICKENPOX_45=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 YczeaCEmCceV for ; Tue, 25 Jan 2011 22:58:45 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 7D02A3A693B for ; Tue, 25 Jan 2011 22:58:45 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX2322ZIO000JHRV@mauve.mrochek.com> for ietf-types@ietf.org; Tue, 25 Jan 2011 23:01:40 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWP1MZKQSW007FL5@mauve.mrochek.com>; Tue, 25 Jan 2011 23:01:37 -0800 (PST) Message-id: <01NX2320XRJO007FL5@mauve.mrochek.com> Date: Tue, 25 Jan 2011 22:29:14 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Jan 2011 01:57:28 +0000" <4D3F7F88.9060204@webr3.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4D3F7F88.9060204@webr3.org> To: Nathan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296022226; bh=zZfBOaYJxYQwrq8c0Ham97f4AgJouNFz+zSEkaPMno8=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=j2flh8i79szpJ8BvQtkV3rH4JHeAZVYsp+SEIDyf9xm6QKjHxR8WG3iyEzBcDXjLT N/C7RNVqPI6+NWwfiEw7hrsHTjQL3TaZcuNLb0wZ2Plv5y1Q11NSeKL5c0+tphXvk1 JPxKe1uvSpoFgdYLSpYDrDT2mZLB5Z+tTqo2u4bA= Cc: Tim Berners-Lee , ietf-types Subject: Re: [ietf-types] Update on the pending registration of text/n3 X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 06:58:47 -0000 > I've been asked to find out about the registration of the 'text/n3' > media type, relating to Notation3 [1,2]. To quote from the annotated > design issue [2]: First and foremost, the lack of an explicit facet in the name means this is a standards tree registration (which certainly seems appropriate for this type). Standards tree registrations are supposed to be reviewed on this list, but approval of them is the province of the IESG. (See RFC 4288 section 5 for details.) So the appropriate thing to do is (1) Post the media type registration form to this list for review, (2) Deal with any review comments, and (3) Submit the registration to the IESG for final review and approval. > """The type application/n3 was applied for in 2002 and again in > 2006. The IETF-W3C liaison meeting established that the mime type > would be formally awarded when the N3 specification was in a > 'published' form. In the mean time, it should be used as part of the > point of N3 is to be human readable, and so the text tree is > indicated. I note that there appears to be a contradiction here - the type is named application/n3 but this then talks about it being text/n3. In any case, I will point out that the text tree has restrictions besides being "human readable" - specifically, there's a requirment that line breaks be represented by CRLF sequences that precludes the use of charsets like UTF-16. I don't know if this is an issue for this type or not, but if it is you're better off staying in the application tree. > The application for text/rdf+n3 with the IANA registry is > pending as of 2006-02 as IANA #5004. There was an agreement to change > it to text/n3 as the rdf+ idea met with significant criticism. In regards to the "pending" registration, it appears to have been submitted to IANA on 30-Jan-2006 (for text/rdf+n3). It was forwarded to me for review on 3-Mar-2006. I responded on 6-Mar-2006 saying that (a) Since this is a standards tree registration it needed to go to the IESG and (b) The fact that no security considerations were provided was unlikely to be acceptable to the IESG. I assume that IANA responded with my comments to the submitter at that time. I don't know if IANA then closed the request, but if they didn't they should have since IANA cannot register types in the standards tree. I note that tHere may also be an issue with the + - we reserve +suffixes as a indicator that the type is in a particular format, e.g. +xml. I don't know if n3 qualifies in this fashion. That said, there would be no problem from a process perspective using rdf-n3. Whether that's more appropriate than n3 is really the W3C's call to make. > While > registration is pending, applications should use the proposed type in > anticipation of registration, not an x- type.""" Always a good idea. > The specification is now 'solid', and has been for a considerable > time, further: OK. > - There are many implementations which have been made over the 10 years > - There is a significant amount of Notation3 data available on the web > and in use > - There is significant reluctance to further deploy Notation3 data > based PURELY on the lack of MIME registration. Then let's by all means get the registration done. > - There is still a lot of confusion as to what the content-type is (as > no media type is registered) > - There is no entry in the default Apache mime.types file, so serving > and negotiating these files is more difficult. > Consequently, can you give either myself or Tim Berners-Lee (cc-d) an > update on the pending application, or inform us as to the best course > of action in order to get the 'text/n3' media type registered in a > timely fashion. See above for my recomendations as to the next steps to take. > Best, > Nathan > [1] http://www.w3.org/TeamSubmission/n3/ > [2] http://www.w3.org/DesignIssues/Notation3 Return-Path: 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 55B6B3A6938 for ; Tue, 25 Jan 2011 22:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.948 X-Spam-Level: X-Spam-Status: No, score=-99.948 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 hm8LwMeFoJAs for ; Tue, 25 Jan 2011 22:23:26 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id E72C73A692E for ; Tue, 25 Jan 2011 22:23:25 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0Q6QINp020138 for ; Wed, 26 Jan 2011 15:26:18 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6537_3189_2f0abc26_2915_11e0_b6a8_001d096c5782; Wed, 26 Jan 2011 15:26:18 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36688) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 26 Jan 2011 15:26:17 +0900 Message-ID: <4D3FBE77.8060906@it.aoyama.ac.jp> Date: Wed, 26 Jan 2011 15:25:59 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: nathan@webr3.org References: <4D3F7F88.9060204@webr3.org> In-Reply-To: <4D3F7F88.9060204@webr3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Tim Berners-Lee , ietf-types Subject: Re: [ietf-types] Update on the pending registration of text/n3 X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 06:23:32 -0000 Hello Nathan, others, I suggest you have a look at http://www.w3.org/2002/06/registering-mediatype. It may be that not everything on that page can be applied directly, but I hope it still helps. Regards, Martin. On 2011/01/26 10:57, Nathan wrote: > Hi, > > I've been asked to find out about the registration of the 'text/n3' > media type, relating to Notation3 [1,2]. To quote from the annotated > design issue [2]: > > """The type application/n3 was applied for in 2002 and again in 2006. > The IETF-W3C liaison meeting established that the mime type would be > formally awarded when the N3 specification was in a 'published' form. In > the mean time, it should be used as part of the point of N3 is to be > human readable, and so the text tree is indicated. The application for > text/rdf+n3 with the IANA registry is pending as of 2006-02 as IANA > #5004. There was an agreement to change it to text/n3 as the rdf+ idea > met with significant criticism. While registration is pending, > applications should use the proposed type in anticipation of > registration, not an x- type.""" > > The specification is now 'solid', and has been for a considerable time, > further: > > - There are many implementations which have been made over the 10 years > - There is a significant amount of Notation3 data available on the web > and in use > - There is significant reluctance to further deploy Notation3 data based > PURELY on the lack of MIME registration. > - There is still a lot of confusion as to what the content-type is (as > no media type is registered) > - There is no entry in the default Apache mime.types file, so serving > and negotiating these files is more difficult. > > Consequently, can you give either myself or Tim Berners-Lee (cc-d) an > update on the pending application, or inform us as to the best course of > action in order to get the 'text/n3' media type registered in a timely > fashion. > > Best, > > Nathan > > [1] http://www.w3.org/TeamSubmission/n3/ > [2] http://www.w3.org/DesignIssues/Notation3 > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp Return-Path: 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 7BE4C3A6905 for ; Tue, 25 Jan 2011 17:54:52 -0800 (PST) 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_45=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 Bj+Tlo8jrvIH for ; Tue, 25 Jan 2011 17:54:51 -0800 (PST) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id A876F3A6900 for ; Tue, 25 Jan 2011 17:54:51 -0800 (PST) Received: (qmail 9737 invoked from network); 26 Jan 2011 01:57:50 -0000 Received: from unknown (217.42.204.134) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 26 Jan 2011 01:57:50 -0000 Message-ID: <4D3F7F88.9060204@webr3.org> Date: Wed, 26 Jan 2011 01:57:28 +0000 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ietf-types Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Berners-Lee Subject: [ietf-types] Update on the pending registration of text/n3 X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: nathan@webr3.org List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 01:54:52 -0000 Hi, I've been asked to find out about the registration of the 'text/n3' media type, relating to Notation3 [1,2]. To quote from the annotated design issue [2]: """The type application/n3 was applied for in 2002 and again in 2006. The IETF-W3C liaison meeting established that the mime type would be formally awarded when the N3 specification was in a 'published' form. In the mean time, it should be used as part of the point of N3 is to be human readable, and so the text tree is indicated. The application for text/rdf+n3 with the IANA registry is pending as of 2006-02 as IANA #5004. There was an agreement to change it to text/n3 as the rdf+ idea met with significant criticism. While registration is pending, applications should use the proposed type in anticipation of registration, not an x- type.""" The specification is now 'solid', and has been for a considerable time, further: - There are many implementations which have been made over the 10 years - There is a significant amount of Notation3 data available on the web and in use - There is significant reluctance to further deploy Notation3 data based PURELY on the lack of MIME registration. - There is still a lot of confusion as to what the content-type is (as no media type is registered) - There is no entry in the default Apache mime.types file, so serving and negotiating these files is more difficult. Consequently, can you give either myself or Tim Berners-Lee (cc-d) an update on the pending application, or inform us as to the best course of action in order to get the 'text/n3' media type registered in a timely fashion. Best, Nathan [1] http://www.w3.org/TeamSubmission/n3/ [2] http://www.w3.org/DesignIssues/Notation3 Return-Path: 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 797253A68E8 for ; Tue, 25 Jan 2011 15:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=-3.983, 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 2Ic0KunKRwh9 for ; Tue, 25 Jan 2011 15:30:56 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by core3.amsl.com (Postfix) with ESMTP id 015533A68D8 for ; Tue, 25 Jan 2011 15:30:55 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p0PNXJ5C008793 for ; Tue, 25 Jan 2011 15:33:39 -0800 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; Tue, 25 Jan 2011 15:33:12 -0800 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.255.3; Tue, 25 Jan 2011 15:33:11 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.252]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 25 Jan 2011 15:33:11 -0800 From: Brian Clubb To: Paul Libbrecht Thread-Topic: [ietf-types] Request for review of standards tree registration request for OpenXPS Thread-Index: AQHLs2yK9k1J+5/sU06pLsUqQi6DMZPiZR4w Date: Tue, 25 Jan 2011 23:33:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Tue, 25 Jan 2011 15:33:40 -0800 (PST) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 23:30:57 -0000 Paul, Thanks for your feedback on my submission template! For your feedback on changing certain responses to lower-case, I will do so= in my final submission. I appreciate your attention to detail on this mat= ter. For the comment on encoding, per rfc4288 section 4.8, the possible response= s here are 7bit, 8bit, binary, and framed. This response appears to be cor= rect for ZIP archives and matches a previous registration for Microsoft's v= ersion of XPS (http://www.iana.org/assignments/media-types/application/vnd.= ms-xpsdocument). If there is some other consideration here, I am happy to = make a note of it elsewhere in the template as needed. As to the clipboard request, I checked the clipboard values on both Windows= OS and Mac OS. For Windows, the clipboard contains the full file path to = the copied .oxps file as a string. On a Mac OS (10.x), the filename plus e= xtension is provided on the clipboard as "text / items". Since these conve= ntions may change over time based on the OS independent of any changes to O= penXPS, I am not certain this would be useful as part of the template. Thanks again for your feedback! I appreciate your time and efforts to revi= ew this! Brian=20 -----Original Message----- From: Paul Libbrecht [mailto:paul@hoplahup.net]=20 Sent: Thursday, January 13, 2011 1:54 PM To: Brian Clubb Cc: ietf-types@iana.org Subject: Re: [ietf-types] Request for review of standards tree registration= request for OpenXPS Brian, I have four little comments of a non expert: Le 12 janv. 2011 =E0 19:40, Brian Clubb a =E9crit : > [...]=20 > Name : Brian Clubb > MIME media type name : Application should be application lower-case > MIME subtype name : Standards Tree - OpenXPS should be openxps, lower case. > Required parameters : N/A > =20 > Optional parameters : > N/A > Encoding considerations : 8-bit Wouldn't zip appear here? [...] > Additional information :=20 > 1. Magic number(s) : ZIP archive CRC-32: 0xdebb20e3 per http://www.pkware= .com/documents/APPNOTE/APPNOTE-6.2.0.txt > 2. File extension(s) : .oxps > 3. Macintosh file type code : N/A > 4. Object Identifiers: N/A Could I request that clipboard names be also described? One for the Windows OS (a simple string). One for the Macintosh OS (a Universal Type Identifer). paul Return-Path: 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 50A963A6BE4 for ; Thu, 13 Jan 2011 13:52:06 -0800 (PST) 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 TrA6w80yOSiJ for ; Thu, 13 Jan 2011 13:52:05 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id CBA1D3A6BE3 for ; Thu, 13 Jan 2011 13:52:04 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p0DLs6ul018376 for ; Thu, 13 Jan 2011 13:54:27 -0800 Received: from brouwer.fritz.box (srbk-5d803552.pool.mediaWays.net [93.128.53.82]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MLR0k-1Pcx9V32Cg-000rvm; Thu, 13 Jan 2011 22:54:03 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Paul Libbrecht In-Reply-To: Date: Thu, 13 Jan 2011 22:54:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Clubb X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:HbmHSFEXQqBZUV7NuQgLEhZQSd8gHv1Mrl9IcatWN5G 4uwbLKDgmZ9S+fGtYI/H5m682TzXiOA0n7WFKZrotovQjaZXF2 djVNx3mo4Ome9XnXU6axERMEakAfgBWEkIshcbA8LqpwKukTG0 0wKdb38lQVh+wQP95WsdnK9T1fOkkWF63Q4iSsD6oerwFx871F SRralS/DLvfYua/N9RkEB9WFmqZ7vvB3IkOSMvBNtI= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [208.77.188.39]); Thu, 13 Jan 2011 13:54:27 -0800 (PST) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:52:06 -0000 Brian, I have four little comments of a non expert: Le 12 janv. 2011 =E0 19:40, Brian Clubb a =E9crit : > [...]=20 > Name : Brian Clubb > MIME media type name : Application should be application lower-case > MIME subtype name : Standards Tree =96 OpenXPS should be openxps, lower case. > Required parameters : N/A > =20 > Optional parameters : > N/A > Encoding considerations : 8-bit Wouldn't zip appear here? [...] > Additional information :=20 > 1. Magic number(s) : ZIP archive CRC-32: 0xdebb20e3 per = http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt > 2. File extension(s) : .oxps > 3. Macintosh file type code : N/A > 4. Object Identifiers: N/A Could I request that clipboard names be also described? One for the Windows OS (a simple string). One for the Macintosh OS (a Universal Type Identifer). paul= Return-Path: 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 8FCAD3A6B48 for ; Wed, 12 Jan 2011 10:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 v6-jmeDiaEIl for ; Wed, 12 Jan 2011 10:55:01 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by core3.amsl.com (Postfix) with ESMTP id 5BD3A3A6B07 for ; Wed, 12 Jan 2011 10:54:59 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p0CIuwe1008715 for ; Wed, 12 Jan 2011 10:57:18 -0800 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; Wed, 12 Jan 2011 10:40:18 -0800 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.255.3; Wed, 12 Jan 2011 10:40:18 -0800 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.141]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 12 Jan 2011 10:40:16 -0800 From: Brian Clubb To: "ietf-types@iana.org" Thread-Topic: Request for review of standards tree registration request for OpenXPS Thread-Index: AcuyiB+gKtQ7++B2Q1KvnCMNPqoWlA== Date: Wed, 12 Jan 2011 18:40:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FE6603D65048F44AB8F8955AE89A09B90A400DTK5EX14MBXW652win_" MIME-Version: 1.0 X-Greylist: Delayed for 00:15:51 by milter-greylist-4.0 (pechora4.lax.icann.org [208.77.188.39]); Wed, 12 Jan 2011 10:57:18 -0800 (PST) X-Mailman-Approved-At: Thu, 13 Jan 2011 11:30:38 -0800 Subject: [ietf-types] Request for review of standards tree registration request for OpenXPS X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:55:12 -0000 --_000_FE6603D65048F44AB8F8955AE89A09B90A400DTK5EX14MBXW652win_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To whom it may concern: Pursuant to RFC 4288 section 5.1, I am submitting the following registratio= n template describing the OpenXPS format for community review with the goal= of adding this registration to the standards tree. The two-week comment p= eriod will conclude on 27 January 2011. Thank you in advance for your review and consideration! Brian Clubb Chairman - Ecma TC46 (Ecma 388: Open XML Paper Specification) Microsoft Corporation bclubb@microsoft.com Name : Brian Clubb Email : bclubb@microsoft.com MIME media type name : Application MIME subtype name : Standards Tree - OpenXPS Required parameters : N/A Optional parameters : N/A Encoding considerations : 8-bit Security considerations : OpenXPS uses ZIP compression as specified in .ZIP File Format Specification= from PKWARE, Inc., version 6.2.0 (2004). ZIP compressed XML requires pars= ing untrusted XML data and untrusted ZIP data. consumer is responsible for= validating the .zip archive, the XML structure, and the resource content. = Per spec, there should be no active content provided as part of the OpenXP= S format. The consumer must ensure that no malicious active content is err= oneously provided in the OpenXPS document. Valid content is described in t= he EMCA-388 specification (http://www.ecma-international.org/publications/s= tandards/Ecma-388.htm) Also see section E.3 of ECMA-388 specification (http://www.ecma-internation= al.org/publications/standards/Ecma-388.htm): OpenXPS Documents follow requirements set out in this Standard, as well as = other normative references including the Open Packaging Conventions. Implem= entations may use the following steps to identify an unknown file or stream= as an OpenXPS Document within an Open Packaging Conventions payload. 1. 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 i= n the .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004= ) 2. Test that a valid Package Relationships zip item exists a. As required by =A78.3.4 of the Open Packaging Conventions b. Check that the content type for the package relationships zip item is co= rrectly defined in the Content Types stream (see OPC =A78.1.2) as a relatio= nships part 3. Test that the Package Relationships Part contains a relationship (see OP= C =A78.3) whose target attribute points to a valid FixedDocumentSequence Pa= rt a. As required by =A710.2 of this Standard b. Check that the content type for the FixedDocumentSequence part is correc= tly defined in the Content Types stream as a FixedDocumentSequence part Interoperability considerations : application/OpenXPS documents are specified by the XML schemas standardized= in ECMA-388. Applications and drivers currently producing/consuming Microsoft XPS conten= t cannot directly produce/consume OpenXPS. Changes are required to address= differences in the two specifications, such as namespace, print ticket usa= ge, use of JPEG XR, etc. Published specification : The published Standard ECMA-388 is available at: http://www.ecma-international.org/publications/standards/Ecma-388.htm Applications which use this media : The application/oxps MIME type can be used to identify CSTA XML (ECMA-388) = instance documents. No published applications or print drivers currently 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 : 1. Magic number(s) : ZIP archive CRC-32: 0xdebb20e3 per http://www.pkware.c= om/documents/APPNOTE/APPNOTE-6.2.0.txt 2. File extension(s) : .oxps 3. Macintosh file type code : N/A 4. Object Identifiers: N/A Person & email address to contact for further information: Ecma International Helpdesk Rue du Rhone114 CH-1204 Geneva Switzerland 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. --_000_FE6603D65048F44AB8F8955AE89A09B90A400DTK5EX14MBXW652win_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To whom it may c= oncern:

 

Pursuant to RFC 4288 section 5.1, I am submitting the following r= egistration template describing the OpenXPS format for community review wit= h the goal of adding this registration to the standards tree.=A0 The two-we= ek comment period will conclude on =A027 January 2011.

 

Thank you in advan= ce for your review and consideration!

 

Brian Clubb

Chairman – Ecma TC46 =A0(Ecma 388: Open XML Paper Specif= ication)

Microsoft Corporation

bclubb@microsoft.com

 

 

Name : Brian Clubb

=  

Email : bclubb@microsoft.com

 

MIME me= dia type name : Application

 <= /o:p>

MIME subtype name : Standards Tree – Op= enXPS

 

Required parameters : N/A

&= nbsp;

 

Optional parameters :

N/A<= /p>

 

&nbs= p;

Encoding considerations : 8-bit=

 

&nb= sp;

Security considerations :

<= p class=3DMsoNormal>OpenXPS uses ZIP compression as specified in .ZIP File = Format Specification from PKWARE, Inc., version 6.2.0 (2004).=A0 ZIP compre= ssed XML requires parsing untrusted XML data and untrusted ZIP data.=A0 con= sumer is responsible for validating the .zip archive, the XML structure, an= d the resource content.=A0 Per spec, there should be no active content prov= ided as part of the OpenXPS format.=A0 The consumer must ensure that no mal= icious active content is erroneously provided in the OpenXPS document.=A0 V= alid content is described in the EMCA-388 specification (http://www.ecma-in= ternational.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 Documen= ts follow requirements set out in this Standard, as well as other normative= references including the Open Packaging Conventions. Implementations may u= se the following steps to identify an unknown file or stream as an OpenXPS = Document within an Open Packaging Conventions payload.

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

a. As required by =A79.2 of the Open Packaging Conve= ntions=A0

b. First four bytes correspon= d to the local file header signature defined in the .ZIP File Format Specif= ication from PKWARE, Inc., version 6.2.0 (2004)=A0

2. Test that a valid Package Relationships zip item exists

a. As required by =A78.3.4 of the Open Pac= kaging Conventions

b. Check that the co= ntent type for the package relationships zip item is correctly defined in t= he Content Types stream (see OPC =A78.1.2) as a relationships part

3. Test that the Package Relationships Part con= tains a relationship (see OPC =A78.3) whose target attribute points to a va= lid FixedDocumentSequence Part

a. As re= quired by =A710.2 of this Standard

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

 

 

Interoperability considerations :

application/OpenXPS documents are specified= by the XML schemas standardized in ECMA-388.

Applications and drivers currently producing/consuming Microsoft XPS = content cannot directly produce/consume OpenXPS.=A0 Changes are required to= address differences in the two specifications, such as namespace, print ti= cket usage, use of JPEG XR, etc.


Published specification :

The published Standard ECMA-388 is available at:

http://www.ecma-international.org/publicati= ons/standards/Ecma-388.htm

 

 

Appl= ications which use this media :

The appl= ication/oxps MIME type can be used to identify CSTA XML (ECMA-388) instance= documents.=A0 No published applications or print drivers currently use Ope= nXPS.=A0 The intent is for any application or driver that can currently pro= duce/consume Microsoft XPS to also adopt OpenXPS.=A0 Examples of such appli= cations would include but are not limited to:=A0 Microsoft XPS Viewer, Micr= osoft XPS Document Writer, Microsoft Internet Explorer 9.

 

 

Additional information :

 

1. Magic number(s) := ZIP archive CRC-32: 0xdebb20e3 per http://www.pkware.com/documents/APPNOTE= /APPNOTE-6.2.0.txt

2. File extension(s) = : .oxps

3. Macintosh file type code : N/= A

4. Object Identifiers: N/A<= /p>

 

Person &a= mp; email address to contact for further information:

Ecma International Helpdesk

Rue du Rhone114

CH-1204 Geneva

Switzerland

= helpdesk@ecma-international.org

&nb= sp;

 

Person to contact for further information :

 

1. Name : Ecma International= Helpdesk

2. Email : helpdesk@ecma-inter= national.org

 

Intended usage : Common

T= his type will be used for all documents conforming to the Open XML

=A0=A0 Paper Specifcation's (ECMA-388) Open XPS = Document format, published

=A0=A0 by ECM= A.

 

 

Author/Change controller : T= he ECMA-388 Standard is developed and

= =A0=A0 maintained by the Ecma TC46 Working Group.

= --_000_FE6603D65048F44AB8F8955AE89A09B90A400DTK5EX14MBXW652win_--