Return-Path: 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 CB85F21F8560 for ; Tue, 25 Oct 2011 08:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.845 X-Spam-Level: X-Spam-Status: No, score=-102.845 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAOXSnYGA+wk for ; Tue, 25 Oct 2011 08:11:18 -0700 (PDT) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 0D24321F8562 for ; Tue, 25 Oct 2011 08:11:17 -0700 (PDT) Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id p9PFAuGZ015382 for ; Tue, 25 Oct 2011 15:11:16 GMT Received: by wwg7 with SMTP id 7so664195wwg.16 for ; Tue, 25 Oct 2011 08:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=S3p6shVkrjH8XJ8QrnPdysA9dcyDyxELdTbbUf/CFfE=; b=HROj6MOwS68ooTxQefkT3NKVndW+2tA580fBhS3FCnLXlMjgxDneku2/6vHXmb7kpX 3I7UnggPw953Jz6QAsiweplgaaGWN+wyryScq7Dvtxk32cdBzu6BuP9IW/+kaPHJeofG JmTWwbgmj3ailxvtFpXBmPGGO8x2EYvwLex3M= Received: by 10.216.88.72 with SMTP id z50mr5149079wee.81.1319555456090; Tue, 25 Oct 2011 08:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 25 Oct 2011 08:10:16 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Tue, 25 Oct 2011 17:10:16 +0200 Message-ID: To: Paul Libbrecht Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Tue, 25 Oct 2011 15:11:16 +0000 (UTC) Cc: IANA MIME types Subject: Re: [ietf-types] Registration of media type application/opensearchdescription+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:11:19 -0000 On 25 October 2011 08:54, Paul Libbrecht wrote: > I hope someone will review the formal aspects of the > procedure. RFC 4288 guarantees an IETF Last Call for this beast if it ever gets this far. I've tried to submit an updated "not for RFC" Internet Draft, but that's still stuck in a manual submission queue. RFC 4288 also guarantees (or rather demands) a complete copy of the registration template in whatever passes as specification, RFC or otherwise: Content and/or URL might change during the review here. The OpenSearch folks suggested to replace OSDD by OSD, and to add ".osdx" as the conventional file extension: Microsoft uses ".osdx". I'm not interested to "invent" wild + wonderful features, I'm only interested to get this beast registered "as is". > My usual suggestion is: what about clipboards? Dunno, is there any problem with XML and clipboards? > OpenSearch Description Documents sound to be a natural > candidate to be exchanged in clipboards (be copied-and > -pasted, be drag-and-dropped, ...). Do I mistake? All I ever wish to do with OSDs is (1) edit some details, or wrt the security considerations inspect their source, (2) adopt an OSD when the auto-detect link rel="search" worked as it should, (3) click on an AddSearchProvider() EcmaScript link for cases where link rel="search" is no option. Where do clipboards enter this picture for you, and is it relevant for the IANA media type registration? > - Macintosh Uniform Type Identifier: > org.opensearch.description conforms to public.xml Sadly I've no idea how Mac Uniform type identifiers work, and the info published in RFC 4288 convinced me that it's not something to worry about. If you have any "official" public source that this is a well-known Mac id. I add it, otherwise I prefer to stick to what I could defend in an IETF Last Call. > My guts feelings about the "responsibility" part of the > registration is that it lacks a tiny bit of formality: > - isn't the WhatWG HTML a "place" for drafting a format > that will hopefully end up be a W3C standard? AddSearchProvider() is documented in WhatWG HTML. Both the HTML5 draft and WhatWG HTML have a reference to the OpenSearch 1.1 spec. The rel="search" link relation is registered for about a year. Oh yes, there is this tiny bit of "happiana" and RFC 4288 standards tree, but "let's see what happens" (before giving up on this registration). > - a google-group as the contact is really volatile. Well, it's how the OpenSearch community works, they have a MediaWiki installation with talk pages, and a mailing list hosted by Google groups. For at least five years, I can't tell how it was when this work was still hosted by A9.com. AFAIK Amazon still donates the domain, and they certainly donated the OpenSearch XML name space URI some years ago. > Is there no way to put a legally registered entity > instead? I think even a9.com would be better. I'm trying to register a well-known media type used in all major browsers and on many web pages, but I cannot claim that I try this on behalf of A9. The OpenSearch.org folks know that I want this media type to be registered since I-D.ellermann-opensearch-00 (2008), and so far nobody had objections. Sadly there were no volunteers to create an RFC, and the proposal to create a DTD for a future RFC died in a resounding silence. > - Similarly http://www.opensearch.org/ is rather a > volatile change controller. This actually is the "change controller" for some years, but IANAL and certainly not speaking for A9. -Frank Return-Path: 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 E66E121F8B03 for ; Mon, 24 Oct 2011 23:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40HRsRLvM5NC for ; Mon, 24 Oct 2011 23:55:09 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 266DC21F8B07 for ; Mon, 24 Oct 2011 23:55:09 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p9P6slxR017811 for ; Tue, 25 Oct 2011 06:55:08 GMT Received: from [192.168.178.27] (p5DDECA24.dip0.t-ipconnect.de [93.222.202.36]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MNyEJ-1ROtV02MzD-0070iK; Tue, 25 Oct 2011 08:54:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: Date: Tue, 25 Oct 2011 08:54:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Frank Ellermann X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:iSKmebddXHnWFYxd0G2+BPzS0zD0iqc/MQNYSNUlP7M VSDkfR+KFIUP5ngHCz46C2CtADLwlt+0q4llvZmvMS0+qSwWo1 r0KodPzO8uSsJI5VqV8doU4DNlx3Kd7Xbl34EBJPH0GgDn7b2Y 8zfPINt9fH49CCUGc8oBhlR/z1nCUbo2cTAlss3BEbxV0GmiQe E8WN/m+EsPiMNB9z3lLjk+j31/x3AIQa8QGnw/Ddjgf2ZDjHft WpAbvyDx2Kt5cHXdKHwYocqfSHkQP0Me1Y90ZuGDqN+w8EF8uM SVEX33RmbVWWvw/RTQuxBqhUgCXU+FB5S1Ayl/j84IEelFYOgn q9lcXtuW/BnSdPs6PaPYFwpmQP1Ra60Z0y2KYiRJNpSyf7q1vZ TD+WnVctOpWeA== X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Tue, 25 Oct 2011 06:55:08 +0000 (UTC) Cc: IANA MIME types Subject: Re: [ietf-types] Registration of media type application/opensearchdescription+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 06:55:10 -0000 Frank, My comments are that of a dilletante in the field.=20 I hope someone will review the formal aspects of the procedure. This is an interesting registration and it seems to be in good shape. My usual suggestion is: what about clipboards?=20 OpenSearch Description Documents sound to be a natural candidate to be = exchanged in clipboards (be copied-and-pasted, be drag-and-dropped, = ...). Do I mistake? Hence I would like to suggest you add two lines in the additional = information section such as the following: - Windows Clipboard Flavor Name: "OpenSearch Description Document" - Macintosh Uniform Type Identifier: org.opensearch.description conforms = to public.xml My guts feelings about the "responsibility" part of the registration is = that it lacks a tiny bit of formality: - isn't the WhatWG HTML a "place" for drafting a format that will = hopefully end up be a W3C standard? I would prefer a W3C document to be = referred to. - a google-group as the contact is really volatile. Is there no way to = put a legally registered entity instead? I think even a9.com would be = better.=20 - Similarly http://www.opensearch.org/ is rather a volatile change = controller. Provided a domain is more or less what its whois entry is, = it means A9.com is the controller (the registered company in the US). = Rather say that. paul Le 20 oct. 2011 =E0 13:03, Frank Ellermann a =E9crit : > Type name: application >=20 > Subtype name: opensearchdescription+xml >=20 > Required parameters: > There are no required parameters. >=20 > Optional parameters: > charset (defaults to "UTF-8") >=20 > Encoding considerations: > Identical to those of "application/xml" as described > in RFC 3023; especially "UTF-8" (RFC 3629) and its > proper subset "US-ASCII" are supposed to work. > For non-ASCII documents served as "text/xml" the > "charset" parameter is required; this might be > relevant when authors are unable to configure the > server hosting their OSDD (OpenSearch Description > Document). >=20 > Security considerations: > All general security and privacy considerations for > sending queries to servers specified in an URL are > applicable. >=20 > Where clients support the optional update feature in > OSDDs it affects the privacy of users. >=20 > The Ecmascript API AddSearchProvider() typically > enforces a "same origin" policy for the OSDD; the = URL > element within the OSDD can designate a third party > as search provider. >=20 > An OSDD can claim to be a search description for X, > but actually do something else. >=20 > Interoperability considerations: > OSDDs use the > XML name space, optionally in conjunction with other > XML name spaces for extensions or application = specific > purposes. >=20 > Published specification: > = >=20 > Applications that use this media type: > Various Web browsers, search engines, and software > libraries support OSDDs. The "search" link relation > is used on many Web pages with this media type. >=20 > The Ecmascript API AddSearchProvider() documented = for > WhatWG HTML uses this media type. >=20 > Additional information: > OSDDs have no "magic numbers" as defined in RFC = 4288. > There are no special "common file name extensions" = for > OSDDs, OSDDs are XML documents. If specific = extensions > are desired ".a9.xml" (or similar) might do the = trick. >=20 > Person & email address to contact for further information: > > >=20 > Intended usage: COMMON >=20 > Restrictions on usage: > None >=20 > Author: DeWitt Clinton >=20 > Change controller: > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: 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 6C3AD21F8CF1 for ; Mon, 24 Oct 2011 18:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmKghj8N600N for ; Mon, 24 Oct 2011 18:01:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6EA821F8B68 for ; Mon, 24 Oct 2011 18:01:52 -0700 (PDT) Received: by gyh20 with SMTP id 20so7643950gyh.31 for ; Mon, 24 Oct 2011 18:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.28.4 with SMTP id x4mr52561119pbg.56.1319504512048; Mon, 24 Oct 2011 18:01:52 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.142.156.11 with HTTP; Mon, 24 Oct 2011 18:01:51 -0700 (PDT) In-Reply-To: <1319499281.2711.10.camel@neutron> References: <1319490143.23040.8.camel@neutron> <1319499281.2711.10.camel@neutron> Date: Mon, 24 Oct 2011 21:01:51 -0400 X-Google-Sender-Auth: lFCcapPDX4sigelhLbn6fJ8KWVQ Message-ID: From: mike amundsen To: "Paul C. Bryan" Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:01:53 -0000 responses inline.... On Mon, Oct 24, 2011 at 19:34, Paul C. Bryan wrote: > Hi Mike: > > Thanks for the review and comments. My responses, inline... > > On Mon, 2011-10-24 at 19:19 -0400, mike amundsen wrote: >> Paul: >> >> checking the I-D document itself: >> >> Sec #4 Operations: >> "It is an error condition if an operation object contains more than >> one operation member." >> >> I am not clear on what this is telling me: >> - the same JSON Pointer expression cannot appear more than once in a document >> - something else? > > What I'm trying to say (evidently not very well yet!) is that you can't > have a operation object with "add" and "remove" at the same time. Only > one operation member per operation object. ok, so this is probably just a "vocabulary" detail. "operation", "operation object", "operation member" maybe a glossary or just some simple oneline definitions up front can help clear that up. > >> possibly consider adding an example of a document that should be >> rejected as it is malformed. > > Will do, thanks. cool. > >> Sec #5 Error Handling >> "In the event of an error condition, evaluation of the JSON Patch >> document terminates and modification of the target document fails to >> complete." >> >> Does this mean the server should treat the document as an >> "all-or-nothing" case? when an error occurs is the document left in a >> "partial state" or left at the "initial state" before the request? is >> this something you want to detail in the spec? if yes, you might want >> to use RFC 2119 words here (MAY, SHOULD, MUST, etc.) . > > HTTP PATCH is clear on the semantics, namely, "If the entire patch > document cannot be successfully applied, then the server MUST NOT apply > any of the changes." I've left this out of my spec, but I think there's > no good reason not to be clearer by saying application of a sequence of > patches SHOULD be atomic. Implementations are free to be even stricter > with a MUST of their own, as HTTP PATCH is. Thoughts? yep, the PATCH semantics are clear on that and it's a good idea to stick with them. I'd proly reference those semantics in the I-D then. either in the error handling section or possibly in another area of the I-D. > >> It looks like your operations account for an error condition at the >> individual "node" level: >> "It is an error condition if the value to be replaced does not exist.", etc. > > Indeed. > >> Are there error conditions that might occur at the "document" level >> (or some other node above the target? >> >> You do not indicate any use of 4xx codes here (i.e. mapping 4xx codes >> to common error conditions in processing the patch); is this something >> you want to include here or leave that up to the server to decide? > > Since JSON Patch is not specific to HTTP, I'm content to defer to HTTP > PATCH and HTTP specifications, which amply document how to handle > situations such as when one attempts to apply an HTTP PATCH against a > resource that does not exist. ok, i can see that. however, you've outline some error conditions in your document. do you have any plans to indicate servers [MUST|SHOULD|MAY] return the details of the errors encountered ("member to be added in the object already exists", "the specified index is greater than the number of elements in the existing array", etc.) and if yes, any suggestions on what the response would look like? I'm not sure this is needed (maybe you want to leave all that to implementors), but wanted to ask about it here. Mike > > Thanks again! > > Paul > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types > Return-Path: 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 A671111E81EC for ; Mon, 24 Oct 2011 16:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5FbK30im9sI for ; Mon, 24 Oct 2011 16:35:16 -0700 (PDT) Received: from eu1sys200aog106.obsmtp.com (eu1sys200aog106.obsmtp.com [207.126.144.121]) by ietfa.amsl.com (Postfix) with SMTP id 741A111E80A4 for ; Mon, 24 Oct 2011 16:35:14 -0700 (PDT) Received: from mail-gy0-f175.google.com ([209.85.160.175]) (using TLSv1) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP; Mon, 24 Oct 2011 23:35:15 UTC Received: by gyc15 with SMTP id 15so7813796gyc.34 for ; Mon, 24 Oct 2011 16:34:43 -0700 (PDT) Received: by 10.68.10.3 with SMTP id e3mr51247669pbb.59.1319499283151; Mon, 24 Oct 2011 16:34:43 -0700 (PDT) Received: from [192.168.1.8] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id jm5sm2232207pbc.1.2011.10.24.16.34.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 16:34:42 -0700 (PDT) Message-ID: <1319499281.2711.10.camel@neutron> From: "Paul C. Bryan" To: ietf-types@ietf.org Date: Mon, 24 Oct 2011 16:34:41 -0700 In-Reply-To: References: <1319490143.23040.8.camel@neutron> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3-2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:35:16 -0000 Hi Mike: Thanks for the review and comments. My responses, inline... On Mon, 2011-10-24 at 19:19 -0400, mike amundsen wrote: > Paul: > > checking the I-D document itself: > > Sec #4 Operations: > "It is an error condition if an operation object contains more than > one operation member." > > I am not clear on what this is telling me: > - the same JSON Pointer expression cannot appear more than once in a document > - something else? What I'm trying to say (evidently not very well yet!) is that you can't have a operation object with "add" and "remove" at the same time. Only one operation member per operation object. > possibly consider adding an example of a document that should be > rejected as it is malformed. Will do, thanks. > Sec #5 Error Handling > "In the event of an error condition, evaluation of the JSON Patch > document terminates and modification of the target document fails to > complete." > > Does this mean the server should treat the document as an > "all-or-nothing" case? when an error occurs is the document left in a > "partial state" or left at the "initial state" before the request? is > this something you want to detail in the spec? if yes, you might want > to use RFC 2119 words here (MAY, SHOULD, MUST, etc.) . HTTP PATCH is clear on the semantics, namely, "If the entire patch document cannot be successfully applied, then the server MUST NOT apply any of the changes." I've left this out of my spec, but I think there's no good reason not to be clearer by saying application of a sequence of patches SHOULD be atomic. Implementations are free to be even stricter with a MUST of their own, as HTTP PATCH is. Thoughts? > It looks like your operations account for an error condition at the > individual "node" level: > "It is an error condition if the value to be replaced does not exist.", etc. Indeed. > Are there error conditions that might occur at the "document" level > (or some other node above the target? > > You do not indicate any use of 4xx codes here (i.e. mapping 4xx codes > to common error conditions in processing the patch); is this something > you want to include here or leave that up to the server to decide? Since JSON Patch is not specific to HTTP, I'm content to defer to HTTP PATCH and HTTP specifications, which amply document how to handle situations such as when one attempts to apply an HTTP PATCH against a resource that does not exist. Thanks again! Paul Return-Path: 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 B1F7B11E8156 for ; Mon, 24 Oct 2011 16:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5eR8zLF50ov for ; Mon, 24 Oct 2011 16:19:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9AC611E813E for ; Mon, 24 Oct 2011 16:19:09 -0700 (PDT) Received: by iabn5 with SMTP id n5so9701812iab.31 for ; Mon, 24 Oct 2011 16:19:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.169 with SMTP id q9mr34491726pbc.107.1319498348775; Mon, 24 Oct 2011 16:19:08 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.142.156.11 with HTTP; Mon, 24 Oct 2011 16:19:08 -0700 (PDT) In-Reply-To: <1319490143.23040.8.camel@neutron> References: <1319490143.23040.8.camel@neutron> Date: Mon, 24 Oct 2011 19:19:08 -0400 X-Google-Sender-Auth: jtL0XmkhY6zWJCdF30lulFgu_oE Message-ID: From: mike amundsen To: "Paul C. Bryan" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:19:10 -0000 Paul: checking the I-D document itself: Sec #4 Operations: "It is an error condition if an operation object contains more than one operation member." I am not clear on what this is telling me: - the same JSON Pointer expression cannot appear more than once in a docume= nt - something else? possibly consider adding an example of a document that should be rejected as it is malformed. Sec #5 Error Handling "In the event of an error condition, evaluation of the JSON Patch document terminates and modification of the target document fails to complete." Does this mean the server should treat the document as an "all-or-nothing" case? when an error occurs is the document left in a "partial state" or left at the "initial state" before the request? is this something you want to detail in the spec? if yes, you might want to use RFC 2119 words here (MAY, SHOULD, MUST, etc.) . It looks like your operations account for an error condition at the individual "node" level: "It is an error condition if the value to be replaced does not exist.", etc= . Are there error conditions that might occur at the "document" level (or some other node above the target? You do not indicate any use of 4xx codes here (i.e. mapping 4xx codes to common error conditions in processing the patch); is this something you want to include here or leave that up to the server to decide? mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Mon, Oct 24, 2011 at 17:02, Paul C. Bryan wro= te: > I'm preparing for possibly taking an informational Internet-Draft [1] > toward a proposed standard. I'm requesting review and feedback on the > "application/json-patch" media type. To wit: > > ----- > > The Internet media type for a JSON Patch document is application/ > json-patch. > > Type name: =A0application > > Subtype name: =A0json-patch > > Required parameters: =A0none > > Optional parameters: =A0 none > > Encoding considerations: > =A0 Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32. > > Security considerations: > =A0 See Security Considerations in section 8. > > Interoperability considerations: =A0N/A > > Published specification: > =A0 draft-pbryan-json-patch-02 > > Applications that use this media type: > =A0 HTTP clients and servers. > > Additional information: > > =A0 Magic number(s): =A0N/A > > =A0 File extension(s): =A0.json-patch > > =A0 Macintosh file type code(s): =A0TEXT > > Person & email address to contact for further information: > =A0 Paul C. Bryan > > Intended usage: =A0COMMON > > Restrictions on usage: =A0none > > Author: =A0Paul C. Bryan > > Change controller: =A0Paul C. Bryan > > ----- > > Thank you for your consideration. > > Paul C. Bryan > paul.bryan@forgerock.com > > [1] http://www.ietf.org/id/draft-pbryan-json-patch-02.txt > > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types > Return-Path: 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 471A111E8178 for ; Mon, 24 Oct 2011 14:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldL0WXF3X42F for ; Mon, 24 Oct 2011 14:29:59 -0700 (PDT) Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) by ietfa.amsl.com (Postfix) with SMTP id 041F011E816B for ; Mon, 24 Oct 2011 14:29:58 -0700 (PDT) Received: from mail-iy0-f177.google.com ([209.85.210.177]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP; Mon, 24 Oct 2011 21:29:59 UTC Received: by mail-iy0-f177.google.com with SMTP id z35so9562408iag.8 for ; Mon, 24 Oct 2011 14:29:57 -0700 (PDT) Received: by 10.68.15.232 with SMTP id a8mr42044384pbd.129.1319491797747; Mon, 24 Oct 2011 14:29:57 -0700 (PDT) Received: from [192.168.1.8] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id 3sm1399208pbx.14.2011.10.24.14.29.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 14:29:56 -0700 (PDT) Message-ID: <1319491795.23040.14.camel@neutron> From: "Paul C. Bryan" To: ietf-types@ietf.org Date: Mon, 24 Oct 2011 14:29:55 -0700 In-Reply-To: <1319491461.23040.13.camel@neutron> References: <1319490143.23040.8.camel@neutron> <1319491461.23040.13.camel@neutron> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3-2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:30:00 -0000 On Mon, 2011-10-24 at 14:24 -0700, Paul C. Bryan wrote: > application/schema And application/patch, even. Return-Path: 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 0434F11E8115 for ; Mon, 24 Oct 2011 14:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uYtaHR84qLm for ; Mon, 24 Oct 2011 14:24:29 -0700 (PDT) Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) by ietfa.amsl.com (Postfix) with SMTP id AAA3811E8114 for ; Mon, 24 Oct 2011 14:24:28 -0700 (PDT) Received: from mail-gx0-f171.google.com ([209.85.161.171]) (using TLSv1) by eu1sys200aob115.postini.com ([207.126.147.11]) with SMTP; Mon, 24 Oct 2011 21:24:28 UTC Received: by mail-gx0-f171.google.com with SMTP id v5so8726992ggn.16 for ; Mon, 24 Oct 2011 14:24:23 -0700 (PDT) Received: by 10.68.30.36 with SMTP id p4mr19823836pbh.86.1319491463659; Mon, 24 Oct 2011 14:24:23 -0700 (PDT) Received: from [192.168.1.8] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id jm5sm1447431pbc.1.2011.10.24.14.24.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 14:24:22 -0700 (PDT) Message-ID: <1319491461.23040.13.camel@neutron> From: "Paul C. Bryan" To: ietf-types@ietf.org Date: Mon, 24 Oct 2011 14:24:21 -0700 In-Reply-To: References: <1319490143.23040.8.camel@neutron> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3-2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:24:30 -0000 On Mon, 2011-10-24 at 23:11 +0200, Bjoern Hoehrmann wrote: > * Paul C. Bryan wrote: > >The Internet media type for a JSON Patch document is application/ > >json-patch. > > What is your reasoning behind not using the "+json" convention? In a previous draft, it was "application/patch+json", but I was advised that: a) application/schema was possibly too basic a base type, and b) there is no formalization around +json extension yet. > >Type name: application > > > >Subtype name: json-patch > > > >Required parameters: none > > > >Optional parameters: none > > > >Encoding considerations: > > Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32. > > Either say something like "Same as for application/json." or "binary". > It would seem to me that RFC 4627 is mistaken in using "8bit" as that > is "The content of the media type consists solely of CRLF-delimited > 8bit text." but JSON does not require CRLF. Okay, thanks. > >Applications that use this media type: > > HTTP clients and servers. > > Well. Revision control systems for instance might use it. True. Is there a way to just indicate general purpose usage instead of trying to enumerate all the specific types of applications I could imagine making use of this? > >Change controller: Paul C. Bryan > > This would have to be some standards organization like "The IETF." Okay. Thanks for the review. Paul Return-Path: 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 80C4411E80AE for ; Mon, 24 Oct 2011 14:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M9TCIWrwBSM for ; Mon, 24 Oct 2011 14:11:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3CD4711E80B6 for ; Mon, 24 Oct 2011 14:11:57 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 21:11:54 -0000 Received: from dslb-094-223-152-226.pools.arcor-ip.net (EHLO HIVE) [94.223.152.226] by mail.gmx.net (mp006) with SMTP; 24 Oct 2011 23:11:54 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+W4eRHwZCW2XDk4cTiJ/eyC8vG6TKGP/+bsUfitQ Y5stTAGJMprNAq From: Bjoern Hoehrmann To: "Paul C. Bryan" Date: Mon, 24 Oct 2011 23:11:59 +0200 Message-ID: References: <1319490143.23040.8.camel@neutron> In-Reply-To: <1319490143.23040.8.camel@neutron> 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 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:11:59 -0000 * Paul C. Bryan wrote: >The Internet media type for a JSON Patch document is application/ >json-patch. What is your reasoning behind not using the "+json" convention? >Type name: application > >Subtype name: json-patch > >Required parameters: none > >Optional parameters: none > >Encoding considerations: > Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32. Either say something like "Same as for application/json." or "binary". It would seem to me that RFC 4627 is mistaken in using "8bit" as that is "The content of the media type consists solely of CRLF-delimited 8bit text." but JSON does not require CRLF. >Applications that use this media type: > HTTP clients and servers. Well. Revision control systems for instance might use it. >Change controller: Paul C. Bryan This would have to be some standards organization like "The IETF." -- 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: 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 99EA311E807F for ; Mon, 24 Oct 2011 14:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69f3pp6RJFCw for ; Mon, 24 Oct 2011 14:02:51 -0700 (PDT) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) by ietfa.amsl.com (Postfix) with SMTP id 7230C21F8AD1 for ; Mon, 24 Oct 2011 14:02:50 -0700 (PDT) Received: from mail-yx0-f178.google.com ([209.85.213.178]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP; Mon, 24 Oct 2011 21:02:50 UTC Received: by yxs7 with SMTP id 7so2376204yxs.37 for ; Mon, 24 Oct 2011 14:02:26 -0700 (PDT) Received: by 10.68.15.201 with SMTP id z9mr51158209pbc.36.1319490145811; Mon, 24 Oct 2011 14:02:25 -0700 (PDT) Received: from [192.168.1.8] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id d9sm1218662pbb.13.2011.10.24.14.02.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 14:02:25 -0700 (PDT) Message-ID: <1319490143.23040.8.camel@neutron> From: "Paul C. Bryan" To: ietf-types@ietf.org Date: Mon, 24 Oct 2011 14:02:23 -0700 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3-2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: [ietf-types] Request for review: application/json-patch X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:02:51 -0000 I'm preparing for possibly taking an informational Internet-Draft [1] toward a proposed standard. I'm requesting review and feedback on the "application/json-patch" media type. To wit: ----- The Internet media type for a JSON Patch document is application/ json-patch. Type name: application Subtype name: json-patch Required parameters: none Optional parameters: none Encoding considerations: Per JSON [RFC4627]: 8bit if UTF-8; binary if UTF-16 or UTF-32. Security considerations: See Security Considerations in section 8. Interoperability considerations: N/A Published specification: draft-pbryan-json-patch-02 Applications that use this media type: HTTP clients and servers. Additional information: Magic number(s): N/A File extension(s): .json-patch Macintosh file type code(s): TEXT Person & email address to contact for further information: Paul C. Bryan Intended usage: COMMON Restrictions on usage: none Author: Paul C. Bryan Change controller: Paul C. Bryan ----- Thank you for your consideration. Paul C. Bryan paul.bryan@forgerock.com [1] http://www.ietf.org/id/draft-pbryan-json-patch-02.txt Return-Path: 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 A2C4421F8B12 for ; Thu, 20 Oct 2011 04:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.587 X-Spam-Level: X-Spam-Status: No, score=-101.587 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC4MFKzOD5w0 for ; Thu, 20 Oct 2011 04:04:40 -0700 (PDT) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 03F0921F8B16 for ; Thu, 20 Oct 2011 04:04:40 -0700 (PDT) Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p9KB4Igf012090 for ; Thu, 20 Oct 2011 11:04:39 GMT Received: by wwg7 with SMTP id 7so2777731wwg.16 for ; Thu, 20 Oct 2011 04:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=R2e+N9guVzXFPJyx+zK1DwI4ycBLF7WKAnhRP/Tdkv4=; b=swoGd86eE9Hvk552D8ywlQp2WicqIki+jDe7eVQWr0IghIYCmusz1BDvVWoMMoGEgu 6pS+ty1whYudHwv4Tg/+0zyyOxXBzIeJpIm8XvMcwtceoRtafuSzle5j6YqEmmDe51jz ywoaOOWBDjf/jdrqlyZhhc3+Rob4b4wJZIUHQ= Received: by 10.227.170.68 with SMTP id c4mr3913570wbz.62.1319108658181; Thu, 20 Oct 2011 04:04:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Thu, 20 Oct 2011 04:03:38 -0700 (PDT) From: Frank Ellermann Date: Thu, 20 Oct 2011 13:03:38 +0200 Message-ID: To: IANA MIME types Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Thu, 20 Oct 2011 11:04:39 +0000 (UTC) Subject: [ietf-types] Registration of media type application/opensearchdescription+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 11:04:44 -0000 Type name: application Subtype name: opensearchdescription+xml Required parameters: There are no required parameters. Optional parameters: charset (defaults to "UTF-8") Encoding considerations: Identical to those of "application/xml" as described in RFC 3023; especially "UTF-8" (RFC 3629) and its proper subset "US-ASCII" are supposed to work. For non-ASCII documents served as "text/xml" the "charset" parameter is required; this might be relevant when authors are unable to configure the server hosting their OSDD (OpenSearch Description Document). Security considerations: All general security and privacy considerations for sending queries to servers specified in an URL are applicable. Where clients support the optional update feature in OSDDs it affects the privacy of users. The Ecmascript API AddSearchProvider() typically enforces a "same origin" policy for the OSDD; the URL element within the OSDD can designate a third party as search provider. An OSDD can claim to be a search description for X, but actually do something else. Interoperability considerations: OSDDs use the XML name space, optionally in conjunction with other XML name spaces for extensions or application specific purposes. Published specification: Applications that use this media type: Various Web browsers, search engines, and software libraries support OSDDs. The "search" link relation is used on many Web pages with this media type. The Ecmascript API AddSearchProvider() documented for WhatWG HTML uses this media type. Additional information: OSDDs have no "magic numbers" as defined in RFC 4288. There are no special "common file name extensions" for OSDDs, OSDDs are XML documents. If specific extensions are desired ".a9.xml" (or similar) might do the trick. Person & email address to contact for further information: Intended usage: COMMON Restrictions on usage: None Author: DeWitt Clinton Change controller: Return-Path: 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 646AA21F8B59 for ; Fri, 7 Oct 2011 12:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEf7Fz9xHDZC for ; Fri, 7 Oct 2011 12:37:53 -0700 (PDT) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id B002B21F8B2F for ; Fri, 7 Oct 2011 12:37:52 -0700 (PDT) Received: from mx03.apa.at (mx03.apa.at [194.232.133.233]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p97JekMY001348 for ; Fri, 7 Oct 2011 19:41:06 GMT Received: from mx171.apa.at (mx171.apa.at [194.232.133.219]) by mx03.apa.at (Postfix) with ESMTP id 3DC6EF12AC for ; Fri, 7 Oct 2011 21:40:44 +0200 (CEST) X-AuditID: c2e885db-b7b16ae0000068c0-ef-4e8f55bb38af Received: from smtp.apanet.at (mx03.apa.at [194.232.133.233]) by mx171.apa.at (APA-IT Spamfilter) with SMTP id 7A.7D.26816.BB55F8E4; Fri, 7 Oct 2011 21:40:43 +0200 (CEST) Received: from vapamx99.apa.at (vapamx99.apa.at [194.232.133.150]) by mx03.apa.at (Postfix) with ESMTP id A56F8F12AC for ; Fri, 7 Oct 2011 21:40:43 +0200 (CEST) Received: from NITFIX7 (unknown [83.64.11.70]) by vapamx99.apa.at (APANET) with ESMTPA id 9683423DC2 for ; Fri, 7 Oct 2011 21:41:46 +0200 (CEST) From: "Michael Steidl \(IPTC\)" To: References: <002601cc8270$e0937550$a1ba5ff0$@org> <68C6BB99-1A01-43CF-BE7A-7A70EF24DF2A@nordsc.com> In-Reply-To: <68C6BB99-1A01-43CF-BE7A-7A70EF24DF2A@nordsc.com> Date: Fri, 7 Oct 2011 21:40:39 +0200 Organization: IPTC Message-ID: <006501cc8528$fed4d990$fc7e8cb0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyCph2ehZSwf1BcTDSYokt3D4n9DACgg8VA Content-Language: de-at X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsVy6EXrS909of1+Bqs/c1msu3aKyYHRo0c+ gDGKyyYlNSezLLVI3y6BK6N11nPWgufKFVP3P2dvYLwn08XIySEhYCKxavtUNghbTOLCvfVA NheHkMBaRolnC38wQzi7GCUOTvwEViUksIpR4szZSBCbDaj7xtFdQHEODhEBSYklqwwhSpIl GhYeYwGxOQXsJFYcucgIYgsLpEjsOfIVLM4ioCLx+MRdJhCbX0BI4n3PA7A4r4ChxPEfO6Fs QYmTM5+A2cwC2hK9D1sZYexlC18zg6yVEFCXePRXF+ICI4lp04sgKsQlTt5azzqBUXgWkkGz kAyahWTQLCQtCxhZVjHy5FYYmhvqJRYk6iWWbGKEBPLtHYx3j2seYhTgYFTi4WXq6fMTYk0s K67MPcQowcGsJMLr8AYoxJuSWFmVWpQfX1Sak1p8iJGJg1OqgTGzm+VzW3Fh7YQ+3dPaNZZP O38VHJ452U9j3rtZkY4cJX8+vAmIOtiUuqhtpuFs36/cp7dr5KxraTjfpz6naHZ5Vnp1ZOO6 rT178/QWqNodMivfLbPrmfWh8O7Ka7l7VCvETpoUmxz/mB5uKLGxc2JQY9vKCwmr7wR8aeNl /57dWa7Udjl2khJLcUaioRZzUXEiAHO0URdCAgAA X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Fri, 07 Oct 2011 19:41:07 +0000 (UTC) Subject: Re: [ietf-types] Updated registration of media type application/vnd.iptc.g2.newsmessage+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 19:37:54 -0000 Hi Jan The IPTC has already registered 4 MIME Types for our suite of news = exchange formats (vnd.iptc.g2.conceptitem+xml, = vnd.iptc.g2.knowledgeitem+xml, vnd.iptc.g2.newsitem+xml, = vnd.iptc.g2.packageitem+xml), all without a specific file extension. The = main reason is that such XML instances are usually not delivered by = access to a file but by a API to a RESTful web service. So why should we = start defining specific extension for additional MIME types with no = urgent practical need for it. Michael > -----Original Message----- > From: Jan Algermissen [mailto:jan.algermissen@nordsc.com] > Sent: Tuesday, October 04, 2011 4:58 PM > To: Michael Steidl (IPTC) > Cc: ietf-types@iana.org > Subject: Re: [ietf-types] Updated registration of media type > application/vnd.iptc.g2.newsmessage+xml >=20 > Hi, >=20 > as per Mark Baker's comment, I'd suggest, too to use a specific file > extension, such as newsml >=20 > Jan >=20 >=20 > On Oct 4, 2011, at 10:37 AM, Michael Steidl (IPTC) wrote: >=20 > > Updated after responses to first draft in mid September. > > > > To: > > ietf-types@iana.org > > > > Subject: > > Registration of media type application/vnd.iptc.g2.newsmessage+xml > > > > Media Type Name: application > > > > Subtype name: vnd.iptc.g2.newsmessage+xml > > > > Required parameters: none > > > > Optional parameters: charset > > Same as charset parameter of application/xml as specified in > > RFC 3023 [RFC3023] > > > > Encoding considerations:Same as encoding considerations > > of application/xml as specified in RFC 3023, section 3.2 > > > > Security considerations: In regards to general XML Security issues, > > identical to those of "application/xml" as described in RFC3023, > > section 10. Beyond these general XML Security issues, the media > > type does not contain active or executable content. The information > > contained in the media type does not require privacy or integrity > > services, however the media type does support the use of the XML > > syntax and processing rules for creating and representing digital > > signatures as described by RFC3275. > > > > Interoperability considerations: > > > > Published specification: > > > > NewsML-G2 version 2.9 specifications and implementation guidelines > > > > http://www.iptc.org/std/NewsML-G2/ > > > > Applications which use this media type: content management systems, > news exchange systems > > > > Additional information: > > > > Magic number(s): none > > > > File extension(s): .xml > > > > Macintosh File Type Code(s): Identical to those of > > "application/xml" as described in RFC3023, "TEXT" > > > > Windows Clipboard Flavor Name: "IPTC NewsMessage XML" > > > > Macintosh Uniform Type Identifier: org.iptc.newsmessage conforms to > public.xml > > > > Object Identifier(s) or OID(s): > > It must be possible to positively identify an Item as it moves > > through the news workflow, and is transferred from place to place > > and from system to system. An Item therefore gets a globally > > unique identifier (guid), which is a persistent, universally unique > > identifier, and a version which is incremented when the content of > > the Item is updated. The first version is numbered 1: if the version > > is not explicitly set, this value must be assumed by the recipient = of > > the Item. The guid is required to be in the form of a IRI. Any IRI > > capable of acting as a globally unique identifier is accepted; the > > IPTC provides a standard for this purpose in the form of an IETF RFC > > [RFC-3085]. > > > > Intended usage: > > > > A News Message is a wrapper of one or more IPTC G2 items for > > distribution and transmission purposes. It provides transmission- > specific > > properties in a header which is shared by all included IPTC G2 = items. > > > > Other Information/General Comment: none > > > > Person to contact for further information: > > Michael Steidl > > > > Author/Change controller: > > Michael Steidl > > > > > > > > > > Michael Steidl > > Managing Director of the IPTC [mdirector@iptc.org] > > International Press Telecommunications Council > > Web: www.iptc.org - on Twitter @IPTC > > Business office address: > > 20 Garrick Street, London WC2E 9BT, United Kingdom > > Registered in England, company no 101096 > > > > _______________________________________________ > > ietf-types mailing list > > ietf-types@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: 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 B8D3D21F8A64 for ; Tue, 4 Oct 2011 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.936 X-Spam-Level: X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-2.956, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW7O6RGE5IlP for ; Tue, 4 Oct 2011 07:55:23 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3021F8A56 for ; Tue, 4 Oct 2011 07:55:21 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p94Evl6l009847 for ; Tue, 4 Oct 2011 10:58:10 -0400 Received: from [10.90.131.108] ([213.238.45.2]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MUlX2-1ResE92nBU-00YO1Q; Tue, 04 Oct 2011 16:57:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <002601cc8270$e0937550$a1ba5ff0$@org> Date: Tue, 4 Oct 2011 16:57:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68C6BB99-1A01-43CF-BE7A-7A70EF24DF2A@nordsc.com> References: <002601cc8270$e0937550$a1ba5ff0$@org> To: Michael Steidl (IPTC) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:E+7RZ3G2TQ832vkjTbS5a4gVzWZh5j1/g/8mbx6DlKM Sn6dmjeHLaNa51Cines4TVuXrnttKEflJnqrLTaYo8Aqvq9o68 tg3seOqs/58WbiGTKBb5AcHmbyw6YHfRToy7mFT/u5KN1/0Vzd A5svYVE2I73udzBDUM5yeWCV9MaWqwEg2okgIGDdbhx6qLMMBF UoMwpZDO0EpDT5H+qhtSWXC/toXAEDCVoc/zcVVG3nFGZTuyUd R9EklBTTPFQvyu2xoN/O7jmThLgmzIu3GlM3WSRxBsFUpEtFDj E8GR6sHjjeZ0tQzHEt6bAdqJ+qoyTqP841S9Z96eY8XYXvVbdc Klo28EWnlInMnjlyUA5n7b5vSn2sxQTs88ePGsgsq8F3dHUoRu v3KHZkvcTdHSw== 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, 04 Oct 2011 10:58:10 -0400 (EDT) X-Mailman-Approved-At: Tue, 04 Oct 2011 08:27:01 -0700 Cc: ietf-types@iana.org Subject: Re: [ietf-types] Updated registration of media type application/vnd.iptc.g2.newsmessage+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 14:55:24 -0000 Hi, as per Mark Baker's comment, I'd suggest, too to use a specific file = extension, such as newsml Jan On Oct 4, 2011, at 10:37 AM, Michael Steidl (IPTC) wrote: > Updated after responses to first draft in mid September. > =20 > To: > ietf-types@iana.org > =20 > Subject: > Registration of media type application/vnd.iptc.g2.newsmessage+xml > =20 > Media Type Name: application > =20 > Subtype name: vnd.iptc.g2.newsmessage+xml > =20 > Required parameters: none > =20 > Optional parameters: charset > Same as charset parameter of application/xml as specified in > RFC 3023 [RFC3023] > =20 > Encoding considerations:Same as encoding considerations > of application/xml as specified in RFC 3023, section 3.2 > =20 > Security considerations: In regards to general XML Security issues, > identical to those of "application/xml" as described in RFC3023, > section 10. Beyond these general XML Security issues, the media > type does not contain active or executable content. The information > contained in the media type does not require privacy or integrity > services, however the media type does support the use of the XML > syntax and processing rules for creating and representing digital > signatures as described by RFC3275. > =20 > Interoperability considerations: > =20 > Published specification: > =20 > NewsML-G2 version 2.9 specifications and implementation guidelines > =20 > http://www.iptc.org/std/NewsML-G2/ > =20 > Applications which use this media type: content management systems, = news exchange systems > =20 > Additional information: > =20 > Magic number(s): none > =20 > File extension(s): .xml > =20 > Macintosh File Type Code(s): Identical to those of > "application/xml" as described in RFC3023, "TEXT" > =20 > Windows Clipboard Flavor Name: "IPTC NewsMessage XML" > =20 > Macintosh Uniform Type Identifier: org.iptc.newsmessage conforms to = public.xml > =20 > Object Identifier(s) or OID(s): > It must be possible to positively identify an Item as it moves > through the news workflow, and is transferred from place to place > and from system to system. An Item therefore gets a globally > unique identifier (guid), which is a persistent, universally unique > identifier, and a version which is incremented when the content of > the Item is updated. The first version is numbered 1: if the version > is not explicitly set, this value must be assumed by the recipient of > the Item. The guid is required to be in the form of a IRI. Any IRI > capable of acting as a globally unique identifier is accepted; the > IPTC provides a standard for this purpose in the form of an IETF RFC > [RFC-3085]. > =20 > Intended usage: > =20 > A News Message is a wrapper of one or more IPTC G2 items for > distribution and transmission purposes. It provides = transmission-specific > properties in a header which is shared by all included IPTC G2 items. > =20 > Other Information/General Comment: none > =20 > Person to contact for further information: > Michael Steidl > =20 > Author/Change controller: > Michael Steidl > =20 > =20 > =20 > =20 > Michael Steidl > Managing Director of the IPTC [mdirector@iptc.org] > International Press Telecommunications Council=20 > Web: www.iptc.org - on Twitter @IPTC > Business office address: > 20 Garrick Street, London WC2E 9BT, United Kingdom > Registered in England, company no 101096 > =20 > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: 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 96F5521F8C6D for ; Tue, 4 Oct 2011 01:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8eDZjt+dOmO for ; Tue, 4 Oct 2011 01:53:02 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by ietfa.amsl.com (Postfix) with ESMTP id CAAA421F8A7D for ; Tue, 4 Oct 2011 01:53:02 -0700 (PDT) Received: from mx03.apa.at (mx03.apa.at [194.232.133.233]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id p948tjdQ012699 for ; Tue, 4 Oct 2011 01:56:05 -0700 Received: from mx17.apa.at (mx17.apa.at [194.232.133.221]) by mx03.apa.at (Postfix) with ESMTP id 89561F1597 for ; Tue, 4 Oct 2011 10:37:43 +0200 (CEST) X-AuditID: c2e885dd-b7b76ae000007bb2-28-4e8ac5d73fee Received: from smtp.apanet.at (mx03.apa.at [194.232.133.233]) by mx17.apa.at (APA-IT Spamfilter) with SMTP id F4.33.31666.7D5CA8E4; Tue, 4 Oct 2011 10:37:43 +0200 (CEST) Received: from vapamx99.apa.at (vapamx99.apa.at [194.232.133.150]) by mx03.apa.at (Postfix) with ESMTP id 32202F1597 for ; Tue, 4 Oct 2011 10:37:43 +0200 (CEST) Received: from NITFIX7 (unknown [83.64.11.70]) by vapamx99.apa.at (APANET) with ESMTPA id 5794F23DC2 for ; Tue, 4 Oct 2011 10:38:42 +0200 (CEST) From: "Michael Steidl \(IPTC\)" To: Date: Tue, 4 Oct 2011 10:37:40 +0200 Organization: IPTC Message-ID: <002601cc8270$e0937550$a1ba5ff0$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CC8281.A41C4550" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyCcOB/gPYYhN0/Q4mKNmBKTd2uYQ== Content-Language: de-at X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsVy6EXrS93rR7v8DB5Ok7dYd+0UkwOjR498 AGMUl01Kak5mWWqRvl0CV8bXo21sBev2MVZ0XT7J3sB4eg1jFyMnh4SAicTCzX1QtpjEhXvr 2boYuTiEBNYwSnx5tZAdJCEksItRYvdmLYjEKkaJqWeWsYEk2IC6bxzdBWRzcIgISEosWWUI EhYWCJY4drIJbCiLgIrE5ue/wcr5BYQk3vc8YAEp5xUwlLj8WRUkzCsgKHFy5hMWEJtZIFri 3p0frCAlEgLqEo/+6kIM15No2lENUSEucfLWetYJjAKzkDTPQtI8C0kZhK0t8fTmUxYYe9nC 18yzgKYyC2hJLJ7liSy8gJF9FSN3boWhuV5iQaJeYskmRkgY393BuPyo5iFGAQ5GJR7eos+d fkKsiWXFlbmHGCU4mJVEeF+5dvkJ8aYkVlalFuXHF5XmpBYfYmTi4JRqYAx++nCf3eqLaxZd 7eJ/vd33BfsC3fpmBl2HwMwzfr+FmDf3vL81K2Rt2nLF3S761+du/FRsUBV+38drVv2q0wmZ Zry6kzeFWqw8YnWz6OKpLYEBHP3X254+LNkuvDOp4sTTuSucqsJ+vss8t73w3FLpG/MbtO74 eVS+Lap9PkVE3u1VNfeayC1KLMUZiYZazEXFiQA3MNMhQQIAAA== X-Greylist: Delayed for 00:17:59 by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Tue, 04 Oct 2011 01:56:06 -0700 (PDT) Subject: [ietf-types] Updated registration of media type application/vnd.iptc.g2.newsmessage+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 08:53:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01CC8281.A41C4550 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Updated after responses to first draft in mid September. =20 To: ietf-types@iana.org=20 =20 Subject: Registration of media type application/vnd.iptc.g2.newsmessage+xml =20 Media Type Name: application =20 Subtype name: vnd.iptc.g2.newsmessage+xml =20 Required parameters: none =20 Optional parameters: charset Same as charset parameter of application/xml as specified in=20 RFC 3023 [RFC3023] =20 Encoding considerations:Same as encoding considerations of application/xml as specified in RFC 3023, section 3.2 =20 Security considerations: In regards to general XML Security issues, identical to those of "application/xml" as described in RFC3023, section 10. Beyond these general XML Security issues, the media type does not contain active or executable content. The information contained in the media type does not require privacy or integrity services, however the media type does support the use of the XML syntax and processing rules for creating and representing digital signatures as described by RFC3275. =20 Interoperability considerations: =20 Published specification: =20 NewsML-G2 version 2.9 specifications and implementation guidelines =20 http://www.iptc.org/std/NewsML-G2/ =20 Applications which use this media type: content management systems, news = exchange systems =20 Additional information: =20 Magic number(s): none =20 File extension(s): .xml =20 Macintosh File Type Code(s): Identical to those of "application/xml" as described in RFC3023, "TEXT" =20 Windows Clipboard Flavor Name: "IPTC NewsMessage XML" =20 Macintosh Uniform Type Identifier: org.iptc.newsmessage conforms to = public.xml =20 Object Identifier(s) or OID(s): It must be possible to positively identify an Item as it moves through the news workflow, and is transferred from place to place and from system to system. An Item therefore gets a globally unique identifier (guid), which is a persistent, universally unique identifier, and a version which is incremented when the content of the Item is updated. The first version is numbered 1: if the version is not explicitly set, this value must be assumed by the recipient of the Item. The guid is required to be in the form of a IRI. Any IRI capable of acting as a globally unique identifier is accepted; the IPTC provides a standard for this purpose in the form of an IETF RFC [RFC-3085]. =20 Intended usage: =20 A News Message is a wrapper of one or more IPTC G2 items for=20 distribution and transmission purposes. It provides = transmission-specific=20 properties in a header which is shared by all included IPTC G2 items. =20 Other Information/General Comment: none =20 Person to contact for further information: Michael Steidl =20 Author/Change controller: Michael Steidl =20 =20 =20 =20 Michael Steidl Managing Director of the IPTC [mdirector@iptc.org] International Press Telecommunications Council=20 Web: www.iptc.org - on Twitter = @IPTC Business office address:=20 20 Garrick Street, London WC2E 9BT, United Kingdom Registered in England, company no 101096 =20 ------=_NextPart_000_0027_01CC8281.A41C4550 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

U= pdated after responses to first draft in mid = September.

<= o:p> 

T= o:

i= etf-types@iana.org

<= o:p> 

S= ubject:

R= egistration of media type = application/vnd.iptc.g2.newsmessage+xml

<= o:p> 

M= edia Type Name: application

<= o:p> 

S= ubtype name: vnd.iptc.g2.newsmessage+xml

<= o:p> 

R= equired parameters: none

<= o:p> 

O= ptional parameters: charset

S= ame as charset parameter of application/xml as specified in =

R= FC 3023 [RFC3023]

<= o:p> 

E= ncoding considerations:Same as encoding = considerations

o= f application/xml as specified in RFC 3023, section = 3.2

<= o:p> 

S= ecurity considerations: In regards to general XML Security = issues,

i= dentical to those of "application/xml" as described in = RFC3023,

s= ection 10. Beyond these general XML Security issues, the = media

t= ype does not contain active or executable content. The = information

c= ontained in the media type does not require privacy or = integrity

s= ervices, however the media type does support the use of the = XML

s= yntax and processing rules for creating and representing = digital

s= ignatures as described by RFC3275.

<= o:p> 

I= nteroperability considerations:

<= o:p> 

P= ublished specification:

<= o:p> 

N= ewsML-G2 version 2.9 specifications and implementation = guidelines

<= o:p> 

h= ttp://www.iptc.org/std/NewsML-G2/

<= o:p> 

A= pplications which use this media type: content management systems, news = exchange systems

<= o:p> 

A= dditional information:

<= o:p> 

M= agic number(s): none

<= o:p> 

F= ile extension(s): .xml

<= o:p> 

M= acintosh File Type Code(s): Identical to those = of

&= quot;application/xml" as described in RFC3023, = "TEXT"

<= o:p> 

W= indows Clipboard Flavor Name: "IPTC NewsMessage = XML"

<= o:p> 

M= acintosh Uniform Type Identifier: org.iptc.newsmessage conforms to = public.xml

<= o:p> 

O= bject Identifier(s) or OID(s):

I= t must be possible to positively identify an Item as it = moves

t= hrough the news workflow, and is transferred from place to = place

a= nd from system to system. An Item therefore gets a = globally

u= nique identifier (guid), which is a persistent, universally = unique

i= dentifier, and a version which is incremented when the content = of

t= he Item is updated. The first version is numbered 1: if the = version

i= s not explicitly set, this value must be assumed by the recipient = of

t= he Item. The guid is required to be in the form of a IRI. Any = IRI

c= apable of acting as a globally unique identifier is accepted; = the

I= PTC provides a standard for this purpose in the form of an IETF = RFC

[= RFC-3085].

<= o:p> 

I= ntended usage:

<= o:p> 

A= News Message is a wrapper of one or more IPTC G2 items for =

d= istribution and transmission purposes. It provides transmission-specific =

p= roperties in a header which is shared by all included IPTC G2 = items.

<= o:p> 

O= ther Information/General Comment: none

<= o:p> 

P= erson to contact for further information:

M= ichael Steidl <mdirector@iptc.org>

<= o:p> 

A= uthor/Change controller:

M= ichael Steidl <mdirector@iptc.org>

<= o:p> 

<= o:p> 

 

 

Michael Steidl

Managing Director of the IPTC = [mdirector@iptc.org]

International Press Telecommunications Council
Web: www.iptc.org - on Twitter @IPTC

Business office address:

20 Garrick Street, London WC2E 9BT, United = Kingdom

Registered in England, company no 101096

 

------=_NextPart_000_0027_01CC8281.A41C4550--