From paulej@packetizer.com Thu Feb 7 14:11:45 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826E221F8447 for ; Thu, 7 Feb 2013 14:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcsyGJOLDnG1 for ; Thu, 7 Feb 2013 14:11:44 -0800 (PST) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id AAF7421F8436 for ; Thu, 7 Feb 2013 14:11:44 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id r17MBOaQ000765 for ; Thu, 7 Feb 2013 22:11:44 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r17Ls2mi016897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 16:54:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360274043; bh=b7xbI2SSS/E0QE0qwCFMgtztUlPHJE3S3B//IoObpyY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=MiqEvDz/BYdxOB0df/AyzMSZSqF7S94chQOQMC0Qa8xK6uu1oUF/X15HdY+4Ovvat OozECzo/O1pvgh+zGoi8RALOQhZJ3O5vGkdOjn4cWHcdSqWRkE4fPArJVpHAoh8ToP IrMz7k7CiSGaZu68duUCGBGhChsywYXtOXNKFoBU= From: "Paul E. Jones" To: Date: Thu, 7 Feb 2013 16:54:11 -0500 Message-ID: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4FfHmd22VIzEXXTX+0vfeMXSyCnA== Content-Language: en-us X-Greylist: Delayed for 00:17:18 by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Thu, 07 Feb 2013 22:11:44 +0000 (UTC) X-Mailman-Approved-At: Fri, 08 Feb 2013 09:24:17 -0800 Cc: webfinger@ietf.org, Barry Leiba Subject: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 22:11:45 -0000 Folks, Barry Leiba indicated that we should register the a media type for the resource representation defined in http://tools.ietf.org/html/draft-ietf-appsawg-webfinger called the JSON Resource Descriptor (JRD). I am sending this for your review and comments back as we are working to finalize the draft. I have not completed a template for application types before and I see there are a few new things in the template, so please do let me know if there is anything that needs clarification or should be changed. Thanks, Paul ================================================ Type name: application Subtype name: jrd+json Required parameters: N/A Optional parameters: N/A "charset" - Indicates the character set used to encode the JSON Resource Descriptor. If absent, UTF-8 is assumed. Encoding considerations: 8bit Security considerations: The JSON Resource Descriptor (JRD) is a JavaScript Object Notation (JSON) object. It is a text format that must be parsed by entities that wish to utilize the format. Depending on the language and mechanism used to parse a JSON object, it is possible for an attacker to inject behavior into a running program. Therefore, care must be taken to properly parse a received JRD to ensure that only a valid JSON object is present and that no JavaScript code is injected or executed unexpectedly. Interoperability considerations: This media type is a JavaScript Object Notation (JSON) object and can be consumed by any software application that can consume JSON objects. Published specification: RFC QQQ Applications that use this media type: WebFinger Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): jrd+json Macintosh file type code(s): N/A Person & email address to contact for further information: Paul E. Jones Intended usage: COMMON Restrictions on usage: N/A Author: Paul E. Jones Change controller: Paul E. Jones Provisional registration? (standards tree only): N/A From derhoermi@gmx.net Fri Feb 8 09:46:36 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2892321F8B18 for ; Fri, 8 Feb 2013 09:46:36 -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_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGDYkg1e38fr for ; Fri, 8 Feb 2013 09:46:36 -0800 (PST) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id DFCFA21F8AEA for ; Fri, 8 Feb 2013 09:46:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18HkFmZ006719 for ; Fri, 8 Feb 2013 17:46:35 GMT Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ld2ys-1UlyCZ3aPQ-00iFFj for ; Fri, 08 Feb 2013 18:46:11 +0100 Received: (qmail invoked by alias); 08 Feb 2013 17:46:11 -0000 Received: from p57A1EAD5.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [87.161.234.213] by mail.gmx.net (mp030) with SMTP; 08 Feb 2013 18:46:11 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19fJehjXslfVYevSL+k4T9AtB8vS0RhUH2UyNhggy vvr170OeGCR+Rj From: Bjoern Hoehrmann To: "Paul E. Jones" Date: Fri, 08 Feb 2013 18:46:11 +0100 Message-ID: References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> In-Reply-To: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 08 Feb 2013 17:46:35 +0000 (UTC) Cc: webfinger@ietf.org, Barry Leiba , media-types@iana.org Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:46:36 -0000 * Paul E. Jones wrote: >http://tools.ietf.org/html/draft-ietf-appsawg-webfinger >================================================ > >Type name: application > >Subtype name: jrd+json > >Required parameters: N/A > >Optional parameters: N/A > "charset" - Indicates the character set used to encode the JSON Resource > Descriptor. If absent, UTF-8 is assumed. This should say something like "Same as for application/json" or there should be a reason given for why it's different. >Encoding considerations: 8bit This should probably say something like "See RFC 6839, section 3.1.". >Published specification: RFC QQQ (The convention is to use "RFC XXXX".) >Applications that use this media type: WebFinger (That's very brief, I would prefer a proper sentence.) >Fragment identifier considerations: N/A As above, given RFC 6839 it's not clear what this means. >Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): jrd+json Are you sure about having a `+` in file extensions? >Author: Paul E. Jones > >Change controller: Paul E. Jones I haven't checked RFC 4288's successor, but I assume this should more likely be "The IETF." or "The IESG". -- 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/ From chris.newman@oracle.com Fri Feb 8 10:53:55 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6586221F8B7D for ; Fri, 8 Feb 2013 10:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWj8x+cwWS8w for ; Fri, 8 Feb 2013 10:53:54 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id A39DE21F8B0A for ; Fri, 8 Feb 2013 10:53:54 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id r18IrXmb011988 for ; Fri, 8 Feb 2013 18:53:54 GMT Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r18IrTxW028581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2013 18:53:29 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r18IrStU004127; Fri, 8 Feb 2013 18:53:28 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.148.206.239] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.16(7.0.5.28.0) 64bit (built Dec 16 2012)) with ESMTPA id <0MHX00F4P0H14200@gotmail.us.oracle.com>; Fri, 08 Feb 2013 10:53:27 -0800 (PST) Date: Fri, 08 Feb 2013 10:53:24 -0800 From: Chris Newman To: "Paul E. Jones" , media-types@iana.org Message-id: <64CAA751B008551D9D7EDC5B@[192.168.15.107]> In-reply-to: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Fri, 08 Feb 2013 18:53:54 +0000 (UTC) Cc: webfinger@ietf.org, Barry Leiba Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:53:55 -0000 The introduction of the "charset" parameter that is not present in the application/json media type makes this incompatible with application/json (since it implicitly allows use of character sets that are not permitted with application/json). As a result, this registration is not compatible with the "+json" suffix. I recommend either removing the charset parameter or changing the name to omit the "+json" suffix. I note the former choice will result in a media type that is simpler to implement. - Chris --On February 7, 2013 16:54:11 -0500 "Paul E. Jones" wrote: > Folks, > > Barry Leiba indicated that we should register the a media type for the > resource representation defined in > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger called the JSON > Resource Descriptor (JRD). > > I am sending this for your review and comments back as we are working to > finalize the draft. > > I have not completed a template for application types before and I see > there are a few new things in the template, so please do let me know if > there is anything that needs clarification or should be changed. > > Thanks, > Paul > > ================================================ > > Type name: application > > Subtype name: jrd+json > > Required parameters: N/A > > Optional parameters: N/A > "charset" - Indicates the character set used to encode the JSON Resource > Descriptor. If absent, UTF-8 is assumed. > > Encoding considerations: 8bit > > Security considerations: > The JSON Resource Descriptor (JRD) is a JavaScript Object Notation > (JSON) object. It is a text format that must be parsed by entities > that wish to utilize the format. Depending on the language and > mechanism used to parse a JSON object, it is possible for an attacker > to inject behavior into a running > program. Therefore, care must be taken to properly parse a received JRD > to > ensure that only a valid JSON object is present and that no JavaScript > code is > injected or executed unexpectedly. > > Interoperability considerations: > This media type is a JavaScript Object Notation (JSON) object and can be > consumed by any software application that can consume JSON objects. > > Published specification: RFC QQQ > > Applications that use this media type: WebFinger > > Fragment identifier considerations: N/A > > Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): jrd+json > Macintosh file type code(s): N/A > > Person & email address to contact for further information: > Paul E. Jones > > Intended usage: COMMON > > Restrictions on usage: N/A > > Author: Paul E. Jones > > Change controller: Paul E. Jones > > Provisional registration? (standards tree only): N/A > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From paulej@packetizer.com Fri Feb 8 11:14:54 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADBB21F8BD5 for ; Fri, 8 Feb 2013 11:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMLZ13SkHndj for ; Fri, 8 Feb 2013 11:14:53 -0800 (PST) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC821F8BD1 for ; Fri, 8 Feb 2013 11:14:53 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18JEWvh029932 for ; Fri, 8 Feb 2013 19:14:53 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JEQgM016509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:14:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360350867; bh=qtlKo+DiVoaG0bsMFjCwuMPpWp/mU9GYxjNSaU+C3hc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Th34klNz5i/2M7Qp9fuVmjRckuaFfWR1dWJOLO6nemtHfxYmRLPu196CWiiAdnIcW KTMxWn4QZn60xRlQuarG+DzXlVmmkgGXIrliYIGTdP/xVfnQrlZDCDC0aqrEB24JhG +huAWCXVJxflijnbTRqtAmVHCIChC+cWVjRaRzew= From: "Paul E. Jones" To: "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 14:14:32 -0500 Message-ID: <015201ce0630$86fe9070$94fbb150$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9mSgN5yA= Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [192.0.33.72]); Fri, 08 Feb 2013 19:14:53 +0000 (UTC) X-Mailman-Approved-At: Fri, 08 Feb 2013 11:16:31 -0800 Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:14:54 -0000 Bj=F6rn, Thanks for the quick review. I have a couple of questions. > >Optional parameters: N/A > > "charset" - Indicates the character set used to encode the JSON > >Resource > > Descriptor. If absent, UTF-8 is assumed. >=20 > This should say something like "Same as for application/json" or there > should be a reason given for why it's different. Unfortunately, application/json just says "n/a". I changed my text to = say the same, but a question I have is "should we specify 'charset'"? = Without the character set being explicitly specified in the Content-Type header = in the HTTP response, it's not clear to me that we could guarantee proper interpretation. Perhaps it is possible because the only valid encodings = are UTF-8, -16, and -32? =20 > >Fragment identifier considerations: N/A >=20 > As above, given RFC 6839 it's not clear what this means. I have no clue what to put here, honestly. Can you suggest text or = point me to text I can borrow? I'm not aware of a spec that defines how to use = the fragment syntax to dereference part of a JSON object, though some = attempts have been made to define that. Is there something we should use? We certainly can define that within this document, as that is a whole = problem unto itself. =20 > > File extension(s): jrd+json >=20 > Are you sure about having a `+` in file extensions? I have absolutely no preference, though this extension would make it = easier for some using the Apache web server. We could just call it "jrd". I'm = OK with flipping a coin on this one. I have modified the template per your advice, though we might need to = adjust it further based on the answers to the above. I put the updated = template below. Thanks! Paul ------------------------ Type name: application Subtype name: jrd+json Required parameters: N/A Optional parameters: N/A Encoding considerations: See RFC 6839, section 3.1. Security considerations: The JSON Resource Descriptor (JRD) is a JavaScript Object Notation = (JSON) object. It is a text format that must be parsed by entities that wish = to utilize the format. Depending on the language and mechanism used to = parse a JSON object, it is possible for an attacker to inject behavior into = a running program. Therefore, care must be taken to properly parse a received JRD to ensure that only a valid JSON object is present and = that no JavaScript or other code is injected or executed unexpectedly. Interoperability considerations: This media type is a JavaScript Object Notation (JSON) object and can = be consumed by any software application that can consume JSON objects. Published specification: RFC XXXX Applications that use this media type: The JSON Resource Descriptor (JRD) is used by the WebFinger protocol (RFC XXXX) to enable the exchange of information between a client and a WebFinger resource over HTTPS. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): jrd+json Macintosh file type code(s): N/A Person & email address to contact for further information: Paul E. Jones Intended usage: COMMON Restrictions on usage: N/A Author: Paul E. Jones Change controller: IESG has change control over this registration. Provisional registration? (standards tree only): N/A From paulej@packetizer.com Fri Feb 8 11:17:20 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB2921F8BE2 for ; Fri, 8 Feb 2013 11:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ero+S6F4RFTy for ; Fri, 8 Feb 2013 11:17:19 -0800 (PST) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 81DE421F8BE9 for ; Fri, 8 Feb 2013 11:17:19 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id r18JGwtI023959 for ; Fri, 8 Feb 2013 19:17:18 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JGsWW016640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:16:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360351015; bh=t02bhEN7VDU4FoMPio5G3xE1FdzkrNCfMD3KBThd5rg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VrQJHHWE9GH0UhKmNzMxxWFbiBlWJC/N/dlHhPri7eGMGBBIIX7TBcQBJhmfwRiob 5j17R6iRgZ0roNEQQk21f5IZBoZMVdTjjzJuvPslDkg7p2n7Iiq/h+VWPhDUMAGorP lCKwJXMGOn0tmbFMXm103acVyibhRIpIufjeIr8Q= From: "Paul E. Jones" To: "'Chris Newman'" , References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@[192.168.15.107]> In-Reply-To: <64CAA751B008551D9D7EDC5B@[192.168.15.107]> Date: Fri, 8 Feb 2013 14:17:00 -0500 Message-ID: <015401ce0630$deed3ed0$9cc7bc70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAMsAnbRmRvm2OA= Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Fri, 08 Feb 2013 19:17:19 +0000 (UTC) Cc: webfinger@ietf.org, 'Barry Leiba' Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:17:20 -0000 OK. I changed it to N/A in the update (to match application/json). Still feels wrong somehow... but, I'll not belabor the point. Paul > -----Original Message----- > From: Chris Newman [mailto:chris.newman@oracle.com] > Sent: Friday, February 08, 2013 1:53 PM > To: Paul E. Jones; media-types@iana.org > Cc: webfinger@ietf.org; Barry Leiba > Subject: Re: [media-types] Media type application/jrd+json > > The introduction of the "charset" parameter that is not present in the > application/json media type makes this incompatible with > application/json (since it implicitly allows use of character sets that > are not permitted with application/json). As a result, this registration > is not compatible with the "+json" suffix. > > I recommend either removing the charset parameter or changing the name > to omit the "+json" suffix. I note the former choice will result in a > media type that is simpler to implement. > > - Chris > > --On February 7, 2013 16:54:11 -0500 "Paul E. Jones" > wrote: > > Folks, > > > > Barry Leiba indicated that we should register the a media type for the > > resource representation defined in > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger called the > > JSON Resource Descriptor (JRD). > > > > I am sending this for your review and comments back as we are working > > to finalize the draft. > > > > I have not completed a template for application types before and I see > > there are a few new things in the template, so please do let me know > > if there is anything that needs clarification or should be changed. > > > > Thanks, > > Paul > > > > ================================================ > > > > Type name: application > > > > Subtype name: jrd+json > > > > Required parameters: N/A > > > > Optional parameters: N/A > > "charset" - Indicates the character set used to encode the JSON > Resource > > Descriptor. If absent, UTF-8 is assumed. > > > > Encoding considerations: 8bit > > > > Security considerations: > > The JSON Resource Descriptor (JRD) is a JavaScript Object Notation > > (JSON) object. It is a text format that must be parsed by entities > > that wish to utilize the format. Depending on the language and > > mechanism used to parse a JSON object, it is possible for an > attacker > > to inject behavior into a running > > program. Therefore, care must be taken to properly parse a received > > JRD to > > ensure that only a valid JSON object is present and that no > > JavaScript code is > > injected or executed unexpectedly. > > > > Interoperability considerations: > > This media type is a JavaScript Object Notation (JSON) object and > can be > > consumed by any software application that can consume JSON objects. > > > > Published specification: RFC QQQ > > > > Applications that use this media type: WebFinger > > > > Fragment identifier considerations: N/A > > > > Additional information: > > Deprecated alias names for this type: N/A > > Magic number(s): N/A > > File extension(s): jrd+json > > Macintosh file type code(s): N/A > > > > Person & email address to contact for further information: > > Paul E. Jones > > > > Intended usage: COMMON > > > > Restrictions on usage: N/A > > > > Author: Paul E. Jones > > > > Change controller: Paul E. Jones > > > > Provisional registration? (standards tree only): N/A > > > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > > > > From paulej@packetizer.com Fri Feb 8 11:22:19 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151D721F8BB0 for ; Fri, 8 Feb 2013 11:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG5xq0gpxuPz for ; Fri, 8 Feb 2013 11:22:18 -0800 (PST) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 3451C21F8B62 for ; Fri, 8 Feb 2013 11:22:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18JLvcB016991 for ; Fri, 8 Feb 2013 19:22:17 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JLqWs016901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:21:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360351312; bh=nencWw1Cn9J2ixaNzjN9Bb+OhLKfpxIsWMqHGPx1c2o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qpi3QISKznsCAB0zrp8FNC3X9RmSptLZk8l+qLG5hO+x3zdlb++GQfH/50CFgoGaw OOpw1KMcxtVHKa6KWPY9fg4To21Q/j6gBt4Pd2nK8/JFJJ/h1svziIyTTy9IcHAvtt Ci8dY/t4+Nz+oGLmAK65DYBCGIe4b0SmWVj74Zus= From: "Paul E. Jones" To: "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 14:21:57 -0500 Message-ID: <015601ce0631$90470260$b0d50720$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9ApkIMX2ZE0wtoA== Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Fri, 08 Feb 2013 19:22:18 +0000 (UTC) Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:22:19 -0000 I wrote: > Unfortunately, application/json just says "n/a". I changed my text to > say the same, but a question I have is "should we specify 'charset'"? > Without the character set being explicitly specified in the Content-Type > header in the HTTP response, it's not clear to me that we could > guarantee proper interpretation. Perhaps it is possible because the > only valid encodings are UTF-8, -16, and -32? Scratch that one... Section 3 of RFC 4627 specifies how to guarantee proper interpretation. Paul From paulej@packetizer.com Fri Feb 8 11:26:27 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895D021F8BED for ; Fri, 8 Feb 2013 11:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwx5i3n6fFUa for ; Fri, 8 Feb 2013 11:26:27 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id EF1AC21F8BDB for ; Fri, 8 Feb 2013 11:26:26 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18JQ68o008558 for ; Fri, 8 Feb 2013 19:26:26 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JQ2kr017136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:26:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360351562; bh=8S9gT+1eCmXbeLpXUds2Oa653PiQ310XSUpClC8SNio=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qGGyFuMVUP8hppa/6yxn49qiaQQhkG7NwJMVIbUfSwrxmFc6EArfS929hiYI0PzV/ vgwiPo6HvWegQI8mA2j4zBSb8LNMS9MCNNU4K7U/PmveBu+Dtf6DQHYnz+yiVwT19N OhgWkpwKcKns3QsC70FwJljq995TVarfEzoXQnjA= From: "Paul E. Jones" To: "'Barry Leiba'" , "'Chris Newman'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> In-Reply-To: Date: Fri, 8 Feb 2013 14:26:08 -0500 Message-ID: <015b01ce0632$257ddca0$707995e0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaADexDJ4AlyhwCOZG2258A== Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 08 Feb 2013 19:26:26 +0000 (UTC) Cc: webfinger@ietf.org, media-types@iana.org Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:26:27 -0000 Barry, > NEW > Optional parameters: None Per RFC 6838, I must put "N/A", not "none". > In particular, because RFC 4627 already defines the character encoding > for JSON, no "charset" parameter is permitted. Do we want to say that the parameter is not permitted or just say that it is not necessary? My web server might make an attempt to add a charset parameter in the Content-Type if I don't explicitly insert one. I've not tested that, but I have seen odd behavior like that before, so I get in the habit of being explicit about it. Paul From derhoermi@gmx.net Fri Feb 8 13:52:31 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2D521F8758 for ; Fri, 8 Feb 2013 13:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no0UgRhrZZvI for ; Fri, 8 Feb 2013 13:52:28 -0800 (PST) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id BE20621F8C38 for ; Fri, 8 Feb 2013 13:52:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18Lq3VR008881 for ; Fri, 8 Feb 2013 21:52:23 GMT Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LhQh4-1UhcDC0p7o-00mfWY for ; Fri, 08 Feb 2013 22:52:02 +0100 Received: (qmail invoked by alias); 08 Feb 2013 21:52:01 -0000 Received: from pD9539135.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.145.53] by mail.gmx.net (mp027) with SMTP; 08 Feb 2013 22:52:01 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/+GZthFI7+obADivJyn/XZPIXFmaHtcqNE7Ox11z 5QHHg5Tz8nIlO1 From: Bjoern Hoehrmann To: "Paul E. Jones" Date: Fri, 08 Feb 2013 22:52:02 +0100 Message-ID: References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> In-Reply-To: <015201ce0630$86fe9070$94fbb150$@packetizer.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 08 Feb 2013 21:52:24 +0000 (UTC) Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 21:52:31 -0000 * Paul E. Jones wrote: >> >Fragment identifier considerations: N/A >> >> As above, given RFC 6839 it's not clear what this means. > >I have no clue what to put here, honestly. Can you suggest text or point me >to text I can borrow? I'm not aware of a spec that defines how to use the >fragment syntax to dereference part of a JSON object, though some attempts >have been made to define that. Is there something we should use? We >certainly can define that within this document, as that is a whole problem >unto itself. You could say something like "Same as for application/json" or "As per RFC 6839" or say fragment identifier semantics are not defined for now because the WebFinger community is still discussing this and it is un- clear whether following the general +json conventions is suitable for this type, as far as I am concerned. You just can't say nothing while RFC 6839 says you SHOULD do something specific. >> > File extension(s): jrd+json >> >> Are you sure about having a `+` in file extensions? > >I have absolutely no preference, though this extension would make it easier >for some using the Apache web server. We could just call it "jrd". I'm OK >with flipping a coin on this one. A possible problem is that file extensions often end up in regular ex- pressions of some form, or in query strings in URLs, where the `+` may be interpreted in a surprising manner, but I do not really care either. >I have modified the template per your advice, though we might need to adjust >it further based on the answers to the above. I put the updated template >below. Looks better, thanks. -- 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/ From barryleiba@gmail.com Fri Feb 8 14:00:03 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94121F8BEB for ; Fri, 8 Feb 2013 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wqTm8Up0ftG for ; Fri, 8 Feb 2013 14:00:02 -0800 (PST) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E28E21F8BF8 for ; Fri, 8 Feb 2013 14:00:02 -0800 (PST) Received: from mail-la0-x231.google.com (la-in-x0231.1e100.net [IPv6:2a00:1450:4010:c03::231]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18Lxfb2007107 for ; Fri, 8 Feb 2013 22:00:02 GMT Received: by mail-la0-f49.google.com with SMTP id fs13so4257918lab.36 for ; Fri, 08 Feb 2013 13:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MQewtSS7DdMSA8d+orotOXU+nzBueBFBEvoK1sdiutM=; b=O3isIUKJONlJoyd1P/bdP940d4nMNkzQndKIjueeYRMYS57C232sVpfshN5KXo4J1k i+EbyNq4xXfjwNYDrh1TaOEu2BMKQEVyI3h8fB+UZDP5Z40mC+zgQQUH9sFOwsUZ9Uzw nmgsqRgkXUJxEKI3DvNBfyCJZzcI4np5SdoaeQd8W/3sDLWpQfBMoNmsWDyNEzRhNMgc q6FNKbDRG9ixguemY5b2vTXZe/tjr2G603MPf9KVU8e+qOpuJV1X3s65qAP2FwzVINv4 hsarAJywad44V3krbrGm9OGBPjXAVdpiXnCxSAEGfbNyQE0mILoluNfcu6PgvkKYmYo5 mXNQ== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr6200059lab.49.1360360780679; Fri, 08 Feb 2013 13:59:40 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 8 Feb 2013 13:59:40 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Feb 2013 16:59:40 -0500 X-Google-Sender-Auth: VvFSh3UOqwzigmmP1HUMa3QexcA Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [IPv6:2620:0:2d0:201::1:72]); Fri, 08 Feb 2013 22:00:02 +0000 (UTC) Cc: "Paul E. Jones" , Bjoern Hoehrmann , "media-types@iana.org" , "webfinger@ietf.org" Subject: Re: [media-types] [webfinger] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 22:00:03 -0000 > If a file extension is going to be defined for the media type, I believe = that it should be "jrd". =D0=94=D0=B0. Barry From paulej@packetizer.com Fri Feb 8 14:00:28 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EBD21F8C04 for ; Fri, 8 Feb 2013 14:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REAHkLmLUEHc for ; Fri, 8 Feb 2013 14:00:24 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 808C021F8BF6 for ; Fri, 8 Feb 2013 14:00:24 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18M033l016920 for ; Fri, 8 Feb 2013 22:00:24 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18LxwXd024401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 16:59:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360360799; bh=3VZd7sSA1gcEnZ3/q+JsCFDlif9XjLDePVdXeITuYrA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ONbD3jiuCt2TypTeEu5HFJVA+yEIZOIc1QxC2ant1NBR9wCLjbW/R8eUOwySmU6j6 mWvwQl6KsdSWAwhHSnrdX2Rt104TaMbcXosjPKzxy+WZpSHG8ZXV9H+aX8/6ianC79 +FtzAF9YYJ9Sy83xnlpRKPUZo57QIL19YRfDXGwY= From: "Paul E. Jones" To: "'Barry Leiba'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> <015b01ce0632$257ddca0$707995e0$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 17:00:05 -0500 Message-ID: <01da01ce0647$a70cc640$f52652c0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaADexDJ4AlyhwCMCM09v/gIfWwAemPkD5tA= Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 08 Feb 2013 22:00:24 +0000 (UTC) Cc: 'Chris Newman' , media-types@iana.org, webfinger@ietf.org Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 22:00:29 -0000 "not used" sounds reasonable. Using your language (plus "not used")... In particular, because RFC 4627 already defines the character encoding for JSON, no "charset" parameter is used. Paul > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of > Barry Leiba > Sent: Friday, February 08, 2013 2:37 PM > To: Paul E. Jones > Cc: Chris Newman; media-types@iana.org; webfinger@ietf.org > Subject: Re: [media-types] Media type application/jrd+json > > >> Optional parameters: None > > > > Per RFC 6838, I must put "N/A", not "none". > > OK. > > >> In particular, because RFC 4627 already defines the character > encoding > >> for JSON, no "charset" parameter is permitted. > > > > Do we want to say that the parameter is not permitted or just say that > > it is not necessary? My web server might make an attempt to add a > > charset parameter in the Content-Type if I don't explicitly insert > > one. I've not tested that, but I have seen odd behavior like that > > before, so I get in the habit of being explicit about it. > > Well, RFC 6657 explains the problems with conflicting charset > information. Even though this isn't a "text/*" media type, the issues > apply here as well, as, I think, do the conclusions: that media type > registrations should either (quoting from 6657 here) > > a. specify that the "charset" parameter is not used for the defined > subtype, because the charset information is transported inside > the payload (such as in "text/xml"), or > > b. require explicit unconditional inclusion of the "charset" > parameter, eliminating the need for a default value. > > I'm suggesting (a), but I'm also happy if you think it's safer to do (b), > as long as you make it clear that the only acceptable values are UTF-8, > UTF-16, and UTF-32, and that the one specified must match the encoding > used in the content. > > b From paulej@packetizer.com Fri Feb 8 14:27:10 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3484D21F8859 for ; Fri, 8 Feb 2013 14:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZrjB1IOjWLc for ; Fri, 8 Feb 2013 14:27:09 -0800 (PST) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id B6DBA21F87FA for ; Fri, 8 Feb 2013 14:27:09 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18MQntp008447 for ; Fri, 8 Feb 2013 22:27:09 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18MQfWm026132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 17:26:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360362401; bh=A8tSVgqy8QG8kNYeNIICAjn2jPO/Yh47btprB7AM0Dw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=IY4sk6SuP9SMPFTnEPAYYwSypgPY8ornMIbdyldmPFBCA0lWgw8Ej6CR0OMC6+h5H aGwQsKiEv0q+CA3mlxKijdD2g3Iq9+2AmzkVtawkd+Gm++vIY6wfMDaD+tqD06qIC7 UbWZX6a9rbDZAidJytctq7/stpiyd9JKUCLqdoRw= From: "Paul E. Jones" To: "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 17:26:47 -0500 Message-ID: <021601ce064b$6242c560$26c85020$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9ArWpI0sDArXCGZj6hGBg Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [192.0.33.72]); Fri, 08 Feb 2013 22:27:09 +0000 (UTC) Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [media-types] [webfinger] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 22:27:10 -0000 Bj=F6rn, > >I have no clue what to put here, honestly. Can you suggest text or > >point me to text I can borrow? I'm not aware of a spec that defines > >how to use the fragment syntax to dereference part of a JSON object, > >though some attempts have been made to define that. Is there = something > >we should use? We certainly can define that within this document, as > >that is a whole problem unto itself. >=20 > You could say something like "Same as for application/json" or "As per > RFC 6839" or say fragment identifier semantics are not defined for now > because the WebFinger community is still discussing this and it is un- > clear whether following the general +json conventions is suitable for > this type, as far as I am concerned. You just can't say nothing while > RFC 6839 says you SHOULD do something specific. We're not inventing anything new here: this format is just a JSON = object. So, perhaps the best solution is to just borrow words from RFC 6839: The syntax and semantics of fragment identifiers SHOULD be as = specified for "application/json". (At publication of this document, there is = no fragment identification syntax defined for "application/json".) That OK? =20 > >> > File extension(s): jrd+json > >> > >> Are you sure about having a `+` in file extensions? > > > >I have absolutely no preference, though this extension would make it > >easier for some using the Apache web server. We could just call it > >"jrd". I'm OK with flipping a coin on this one. >=20 > A possible problem is that file extensions often end up in regular ex- > pressions of some form, or in query strings in URLs, where the `+` may > be interpreted in a surprising manner, but I do not really care = either. I'll ask the WF group separately on this and see if I can get closure. Thanks! Paul From paulej@packetizer.com Fri Feb 8 14:31:06 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F7F21F8AE3 for ; Fri, 8 Feb 2013 14:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs2t5oCsvUGU for ; Fri, 8 Feb 2013 14:31:06 -0800 (PST) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 4976821F87FA for ; Fri, 8 Feb 2013 14:31:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18MUjsf008665 for ; Fri, 8 Feb 2013 22:31:05 GMT Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18MUeMX026428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 17:30:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360362641; bh=zQPJMQ4V70MdjdQ0Ec00lidG5iv31w8RZfZL7/bjCJA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sGizTWqby/XiW2zojQ1rRb1cmdsbeWymkmng96oCgA/2zqIz5fE1xNaYgjL0fU/lR topmRCtYMuZgR2mtuiKNy8vjzj3G6CmnMsVBeAaCcVx3+zX+0bXJF+EPwCQvXBTevt DGeZskoc6MUHgDdAo9XLdssj4oaT12yEu6s8Xdzw= From: "Paul E. Jones" To: "'Mike Jones'" , "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Feb 2013 17:30:47 -0500 Message-ID: <022501ce064b$f103b930$d30b2b90$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9ArWpI0sDArXCGQIN4EOlmOoXXSA= Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [192.0.33.72]); Fri, 08 Feb 2013 22:31:06 +0000 (UTC) Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [media-types] [webfinger] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 22:31:06 -0000 Thanks, Mike. I didn't see your reply before sending the other email on this topic. Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, February 08, 2013 4:55 PM > To: Bjoern Hoehrmann; Paul E. Jones > Cc: webfinger@ietf.org; 'Barry Leiba'; media-types@iana.org > Subject: RE: [webfinger] [media-types] Media type application/jrd+json > > If a file extension is going to be defined for the media type, I believe > that it should be "jrd". > > -- Mike > From barryleiba@gmail.com Fri Feb 8 11:17:01 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524F021F8BD1 for ; Fri, 8 Feb 2013 11:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOgXv6hi9g3y for ; Fri, 8 Feb 2013 11:17:01 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 025AB21F8BD4 for ; Fri, 8 Feb 2013 11:17:00 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id r18JGemr013645 for ; Fri, 8 Feb 2013 19:17:00 GMT Received: by mail-qa0-f51.google.com with SMTP id cr7so464985qab.3 for ; Fri, 08 Feb 2013 11:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=g+jBA7gmNFXozUdcJmg9I3E73DyGVNgH7QGWTg79Hrw=; b=kZaZ/rf9S3rpipaMnRGB5mu0W5cfpyb/f4VEsMReRfz9HdJJj9zleASTqPY2mJ6emv 0WVM1nBtoc+mdGwo8Sk25+iLzk6cx1K6bmzC2l1XCzVqx/YP6t5lV1fr+YYgqR8EfNEj NPXD+LJP/YdhtxQnKPF6J4vr8PqcxTLyuQRLyUzM5uaM7a2wg30dp1mfBVjfGsQ5hh8P uul2pPR336zAtl2p3lrxfwRvg204LwWcgNyX53XfW3ZlCKm5mz6r+PS02RX8D3e3murf TctnE6VAo1oSZdG2dLbvDA9H1wFYBzopO1zzkyQbP3LakTzQEL2eEb5loL8PZC8sQYyo zgyA== MIME-Version: 1.0 X-Received: by 10.49.118.138 with SMTP id km10mr2679639qeb.18.1360350981232; Fri, 08 Feb 2013 11:16:21 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.49.104.139 with HTTP; Fri, 8 Feb 2013 11:16:21 -0800 (PST) In-Reply-To: <64CAA751B008551D9D7EDC5B@192.168.15.107> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> Date: Fri, 8 Feb 2013 14:16:21 -0500 X-Google-Sender-Auth: D_9_fgQa3IKndUktysQvzD_cnFQ Message-ID: From: Barry Leiba To: Chris Newman Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Fri, 08 Feb 2013 19:17:00 +0000 (UTC) X-Mailman-Approved-At: Fri, 08 Feb 2013 22:17:08 -0800 Cc: "Paul E. Jones" , media-types@iana.org, "webfinger@ietf.org" Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:17:01 -0000 > The introduction of the "charset" parameter that is not present in the > application/json media type makes this incompatible with application/json > (since it implicitly allows use of character sets that are not permitted > with application/json). As a result, this registration is not compatible > with the "+json" suffix. That's a good point: JSON already specifies the encoding, so a charset parameter is not only not necessary, but is actively bad. I agree that eliminating "charset" is best, and I suggest actively noting that it's not allowed, to avoid any question. Perhaps something like this: NEW Optional parameters: None In particular, because RFC 4627 already defines the character encoding for JSON, no "charset" parameter is permitted. END Barry From barryleiba@gmail.com Fri Feb 8 11:37:12 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9696721F8B6D for ; Fri, 8 Feb 2013 11:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4vv0Gzc4Qpv for ; Fri, 8 Feb 2013 11:37:12 -0800 (PST) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 6987121F8A77 for ; Fri, 8 Feb 2013 11:37:12 -0800 (PST) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18Jaqo0004546 for ; Fri, 8 Feb 2013 19:37:12 GMT Received: by mail-qe0-f41.google.com with SMTP id 7so1869820qeb.0 for ; Fri, 08 Feb 2013 11:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wjU6Gt+deJiH8nHiAJX8NRdiC5XGT1fWi0f+2PJmrqE=; b=nwla+ylgNk6V3z42YF6zkqu9r2ePTkZA9xmqfd0LmNsNkJCnL/BfkcEaPL8dMqWL50 UIt/S/Sms/VTlRiouISpJRHANXieqogf+vseaY5Bs2CYV0zcVWHcHXUBmSQq9sAy8Y5V 4z0/p1KLSaNMs0+g8RUsIUeU1Rl2vbUT6/eHGN3veC24huNztrFDQEnFFQAzKUOjIs8g DmAkYT+x3ck0GGuDk9i9UK4RzLSf4yClSIetVv4hz1bp2Pcf3iSWueQ40KS73IsQFwbD SJRish7/RXv2ta3yjs+BZ8a7246E3Oe+JRmH2X3raMACH1dY4Qc/mMWORIWRsxY/D6vB rqfg== MIME-Version: 1.0 X-Received: by 10.229.195.230 with SMTP id ed38mr565920qcb.22.1360352211700; Fri, 08 Feb 2013 11:36:51 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.49.104.139 with HTTP; Fri, 8 Feb 2013 11:36:51 -0800 (PST) In-Reply-To: <015b01ce0632$257ddca0$707995e0$@packetizer.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> <015b01ce0632$257ddca0$707995e0$@packetizer.com> Date: Fri, 8 Feb 2013 14:36:51 -0500 X-Google-Sender-Auth: _hrJEDPO64ewl65pVThBaoDCqJU Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 08 Feb 2013 19:37:12 +0000 (UTC) X-Mailman-Approved-At: Fri, 08 Feb 2013 22:17:08 -0800 Cc: Chris Newman , media-types@iana.org, "webfinger@ietf.org" Subject: Re: [media-types] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:37:12 -0000 >> Optional parameters: None > > Per RFC 6838, I must put "N/A", not "none". OK. >> In particular, because RFC 4627 already defines the character encoding >> for JSON, no "charset" parameter is permitted. > > Do we want to say that the parameter is not permitted or just say that it is > not necessary? My web server might make an attempt to add a charset > parameter in the Content-Type if I don't explicitly insert one. I've not > tested that, but I have seen odd behavior like that before, so I get in the > habit of being explicit about it. Well, RFC 6657 explains the problems with conflicting charset information. Even though this isn't a "text/*" media type, the issues apply here as well, as, I think, do the conclusions: that media type registrations should either (quoting from 6657 here) a. specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (such as in "text/xml"), or b. require explicit unconditional inclusion of the "charset" parameter, eliminating the need for a default value. I'm suggesting (a), but I'm also happy if you think it's safer to do (b), as long as you make it clear that the only acceptable values are UTF-8, UTF-16, and UTF-32, and that the one specified must match the encoding used in the content. b From Michael.Jones@microsoft.com Fri Feb 8 13:55:39 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A819A21F8BB7 for ; Fri, 8 Feb 2013 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xvHIKZ0UPLn for ; Fri, 8 Feb 2013 13:55:39 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4C321F89FC for ; Fri, 8 Feb 2013 13:55:39 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id r18LtJuW016727 for ; Fri, 8 Feb 2013 21:55:39 GMT Received: from BY2FFO11FD014.protection.gbl (10.1.15.200) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Feb 2013 21:55:16 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Fri, 8 Feb 2013 21:55:16 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 8 Feb 2013 21:54:50 +0000 From: Mike Jones To: Bjoern Hoehrmann , "Paul E. Jones" Thread-Topic: [webfinger] [media-types] Media type application/jrd+json Thread-Index: AQHOBjA98omDNiCrwE67b/ziBYEdDZhwVKsAgAAsAgCAAACXUA== Date: Fri, 8 Feb 2013 21:54:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(13464002)(377454001)(24454001)(189002)(199002)(51856001)(16601075001)(77982001)(76482001)(47736001)(4396001)(50986001)(47976001)(50466001)(59766001)(49866001)(5343655001)(33656001)(79102001)(55846006)(23756002)(46102001)(74662001)(44976002)(31966008)(47446002)(15202345001)(74502001)(54356001)(16406001)(66066001)(80022001)(53806001)(20776003)(54316002)(63696002)(47776003)(56776001)(56816002)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0751474A44 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 08 Feb 2013 21:55:39 +0000 (UTC) X-Mailman-Approved-At: Fri, 08 Feb 2013 22:16:52 -0800 Cc: "webfinger@ietf.org" , 'Barry Leiba' , "media-types@iana.org" Subject: Re: [media-types] [webfinger] Media type application/jrd+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 21:55:39 -0000 If a file extension is going to be defined for the media type, I believe th= at it should be "jrd". -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Bjoern Hoehrmann Sent: Friday, February 08, 2013 1:52 PM To: Paul E. Jones Cc: webfinger@ietf.org; 'Barry Leiba'; media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json * Paul E. Jones wrote: >> >Fragment identifier considerations: N/A >>=20 >> As above, given RFC 6839 it's not clear what this means. > >I have no clue what to put here, honestly. Can you suggest text or=20 >point me to text I can borrow? I'm not aware of a spec that defines=20 >how to use the fragment syntax to dereference part of a JSON object,=20 >though some attempts have been made to define that. Is there something=20 >we should use? We certainly can define that within this document, as=20 >that is a whole problem unto itself. You could say something like "Same as for application/json" or "As per RFC = 6839" or say fragment identifier semantics are not defined for now because = the WebFinger community is still discussing this and it is un- clear whethe= r following the general +json conventions is suitable for this type, as far= as I am concerned. You just can't say nothing while RFC 6839 says you SHOU= LD do something specific. >> > File extension(s): jrd+json >>=20 >> Are you sure about having a `+` in file extensions? > >I have absolutely no preference, though this extension would make it=20 >easier for some using the Apache web server. We could just call it=20 >"jrd". I'm OK with flipping a coin on this one. A possible problem is that file extensions often end up in regular ex- pres= sions of some form, or in query strings in URLs, where the `+` may be inter= preted in a surprising manner, but I do not really care either. >I have modified the template per your advice, though we might need to=20 >adjust it further based on the answers to the above. I put the updated=20 >template below. Looks better, thanks. -- Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma= nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsw= orld.de 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/ _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From mca@amundsen.com Sat Feb 23 07:51:16 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3121F8FB0 for ; Sat, 23 Feb 2013 07:51:16 -0800 (PST) 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=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui58-lif+h+6 for ; Sat, 23 Feb 2013 07:51:15 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0221F8FAF for ; Sat, 23 Feb 2013 07:51:15 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so1325857wge.22 for ; Sat, 23 Feb 2013 07:51:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type:x-gm-message-state; bh=6k/jWl1ke4ymZHyougKTgxSwepeMl0qGZ41OCa3I6+4=; b=QrhPFkcu8yytCSZv78BqEV+I7Y7tsvBdiaHo+pvPHxSsHfv+5/UcXAJt/S/ee71emw ZlICM7KeQN8vroi9xrMqgh+7VWmvzaQLq8XyD7F7WfzLgaUuD2R4Wq3z2aLDgjH5TqqH jcCjw3cY7v09NNHyu7ZN6pVoCMtGXaj6k4EEq7j8XszehKivEFFLgt+XhbGuHb18waYL Bom4xo5/YLbgW2cx7dWCC91UnSn6Vk5EFzDMclu++puwhk2oOjS2tbqB0ykfEdIKfXsd ZYG0JZ+tkcOgpgcG9FV558MoS+11c6ZdONYDS4njGrknwpLESMKRYpZ1jCMh451h4uIG uDbQ== X-Received: by 10.194.5.137 with SMTP id s9mr8467904wjs.5.1361634673934; Sat, 23 Feb 2013 07:51:13 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.119.201 with HTTP; Sat, 23 Feb 2013 07:50:53 -0800 (PST) From: mike amundsen Date: Sat, 23 Feb 2013 10:50:53 -0500 X-Google-Sender-Auth: tbTm4BFXuXNTn6MTpojg1ClyISU Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d35800de0c404d666477f X-Gm-Message-State: ALoCoQlEOeRProvQeb2goUfvj416GVcTeUykoWUPt3x9nDkZVmiai8hYmFirsxoVYp4xG3MwDM5J Subject: [media-types] Modiyfing a registered VND type... X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 15:51:16 -0000 --047d7b5d35800de0c404d666477f Content-Type: text/plain; charset=ISO-8859-1 I am contemplating adding an optional parameter[0] to the application/vnd.collection+json[1][2] media type definition. What I want to do is register the "profile" parameter similar to the profile parameter proposed for XML media types back in 2009[3]. This would be OPTIONAL, backward-compatible for any existing implementations, and would not change the media type parsing or functionality. It would, instead, offer additional information about the content of the message body. What are the steps I need to follow in order to update the IANA registration[4] to include this in the registration information at IANA? TIA for your help. [0] http://eveinfo.net/wiki/rfc4288.htm#section-4.3 [1] http://www.iana.org/assignments/media-types/application/vnd.collection+json [2] http://amundsen.com/media-types/collection/ [3] http://buzzword.org.uk/2009/draft-inkster-profile-parameter-00.html#anchor2 [4] http://eveinfo.net/wiki/rfc4288.htm#section-9 mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen --047d7b5d35800de0c404d666477f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am contemplating adding an optional=A0parameter[0]=A0to the application/v= nd.collection+json[1][2] media type=A0definition.

What I= want to do is register the "profile" parameter similar to the pr= ofile=A0parameter=A0proposed for XML media types back in 2009[3]. This woul= d be OPTIONAL, backward-compatible for any existing implementations, and wo= uld not change the media type parsing or functionality. It would, instead, = offer additional information about the content of the message body.

What are the steps I need to follow in order to update = the IANA registration[4] to include this in the registration information at= IANA?

TIA for your help.

--047d7b5d35800de0c404d666477f-- From ned.freed@mrochek.com Sat Feb 23 08:05:43 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56921F8FD3 for ; Sat, 23 Feb 2013 08:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgR7jkDceBmg for ; Sat, 23 Feb 2013 08:05:42 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 784AC21F8FD5 for ; Sat, 23 Feb 2013 08:05:42 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OQIX4PCK7K000BNN@mauve.mrochek.com> for media-types@ietf.org; Sat, 23 Feb 2013 08:02:27 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OQH0ICCQ1C000054@mauve.mrochek.com>; Sat, 23 Feb 2013 08:02:25 -0800 (PST) Message-id: <01OQIX4NXKKA000054@mauve.mrochek.com> Date: Sat, 23 Feb 2013 08:01:16 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 23 Feb 2013 10:50:53 -0500" References: To: mike amundsen Cc: media-types@ietf.org Subject: Re: [media-types] Modiyfing a registered VND type... X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:05:43 -0000 > I am contemplating adding an optional parameter[0] to the > application/vnd.collection+json[1][2] media type definition. > What I want to do is register the "profile" parameter similar to the > profile parameter proposed for XML media types back in 2009[3]. This would > be OPTIONAL, backward-compatible for any existing implementations, and > would not change the media type parsing or functionality. It would, > instead, offer additional information about the content of the message body. > What are the steps I need to follow in order to update the IANA > registration[4] to include this in the registration information at IANA? > TIA for your help. Given that you are the registered contact, it's easy: Just send your updated registration to IANA. Ned From zednis@rpi.edu Sat Feb 23 15:57:18 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A786B21F8E3A for ; Sat, 23 Feb 2013 15:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t--VbVouPfDP for ; Sat, 23 Feb 2013 15:57:17 -0800 (PST) Received: from smtp10.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 106DA21F8DDC for ; Sat, 23 Feb 2013 15:57:16 -0800 (PST) Received: from smtp-auth2.server.rpi.edu (smtp-auth2.server.rpi.edu [128.113.2.232]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id r1NNvFoU026870; Sat, 23 Feb 2013 18:57:15 -0500 Received: from smtp-auth2.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth2.server.rpi.edu (Postfix) with ESMTP id 6381C18022; Sat, 23 Feb 2013 18:55:10 -0500 (EST) Received: from [192.168.1.139] (c-76-120-60-27.hsd1.co.comcast.net [76.120.60.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zednis) by smtp-auth2.server.rpi.edu (Postfix) with ESMTPSA id AA2931800C; Sat, 23 Feb 2013 18:55:09 -0500 (EST) From: Stephan Zednik Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Feb 2013 16:57:09 -0700 Message-Id: <300B4DA2-6802-44D5-AB61-CFA9F85573FE@rpi.edu> To: media-types@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.5 (Score 0, tokens from: outgoing) X-CanIt-Incident-Id: 03J3XVfaM X-CanIt-Geo: ip=76.120.60.27; country=US; region=CO; city=Denver; latitude=39.7392; longitude=-104.9847; metrocode=751; areacode=303; http://maps.google.com/maps?q=39.7392,-104.9847&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Cc: "public-prov-comments@w3.org" , ietf-xml-mime@imc.org Subject: [media-types] request for comments on media types section of PROV-XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:58:52 -0000 link to media type section in editors draft of specification: = https://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html#media-type Type name: application Subtype name: provenance+xml Required parameters: none Optional parameters: charset - this parameter may be required when transferring non-ASCII = data across some protocols. Encoding considerations: The syntax of PROV-XML is expressed over code points in Unicode = [[!UNICODE]] Security considerations: PROV-XML is an XML language for describing the provenance of things; = applications may evaluate given data to dereference URIs, invoking the = security considerations of the scheme for that URI. Note in particular, = the privacy issues in [[!RFC3023]] section 10 for HTTP URIs. Data = obtained from an inaccurate or malicious data source may lead to = inaccurate or misleading conclusions, as well as the dereferencing of = unintended URIs. Care must be taken to align the trust in consulted = resources with the sensitivity of the intended use of the data. PROV-XML can express data which is presented to the user, for example, = by means of label attributes. Application rendering strings retrieved = from untrusted PROV-N documents must ensure that malignant strings may = not be used to mislead the reader. The security considerations in the = media type registration for XML ([[!RFC3023]] section 10) provide = additional guidance around the expression of arbitrary data and markup. PROV-XML is a language for describing the provenance of things, and = therefore a PROV-XML document is metadata for other resources. = Untrusted PROV-XML documents may mislead its consumers by indicating = that a third-party resource has a reputable lineage, when it has not. = Provenance of PROV-XML document should be sought.=20 PROV-XML uses QNames mappable to IRIs as term identifiers. Applications = interpreting data expressed in PROV-XML should address the security = issues of Internationalized Resource = Identifiers (IRIs) [[!RFC3987]] Section 8, as well as Uniform = Resource Identifier (URI): Generic Syntax [[!RFC3986]] Section 7. = Multiple IRIs may have the same appearance. Characters in different = scripts may look similar (a Cyrillic "о" may appear = similar to a Latin "o"). A character followed by combining = characters may have the same visual representation as another character = (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same = visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person = or application that is writing or interpreting data in PROV-N must take = care to use the IRI that matches the intended semantics, and avoid IRIs = that make look similar. Further information about matching of similar = characters can be found in Unicode Security = Considerations [[UNISEC]] and Internationalized Resource = Identifiers (IRIs) [[!RFC3987]] Section 8. Interoperability considerations: There are no known interoperability issues. Published specification: PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau http://www.w3.org/TR/prov-xml/= , 2012. Applications which use this media type: It may be used by any application for publishing provenance information. = This format is designed to be an XML form of provenance. Additional Information: Magic number(s): PROV-XML documents are XML documents and thus may have initial = strings similar to any XML document. File extension(s): .provx Base URI: As in XML. Macintosh file type code(s): "TEXT" Person & email address to contact for further information Ivan Herman, ivan@w3.org Intended usage: COMMON Restrictions on usage: None Author/Change controller: The PROV-XML specification is the product of the World Wide Web = Consortium's Provenance Working Group. The W3C has change control over = this specification. From derhoermi@gmx.net Mon Feb 25 06:32:26 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55F121F9344 for ; Mon, 25 Feb 2013 06:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uceB3SmWdZWQ for ; Mon, 25 Feb 2013 06:32:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 86B0321F92DD for ; Mon, 25 Feb 2013 06:32:20 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MARmu-1TyPYS3hEo-00BZzs for ; Mon, 25 Feb 2013 15:31:02 +0100 Received: (qmail invoked by alias); 25 Feb 2013 14:31:02 -0000 Received: from p5B233160.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.49.96] by mail.gmx.net (mp034) with SMTP; 25 Feb 2013 15:31:02 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18yB9obPT4yZwr/BY+UUchWfmp0jckygzyhnQhrbK oN35bjTkYAJFMr From: Bjoern Hoehrmann To: Stephan Zednik Date: Mon, 25 Feb 2013 15:31:00 +0100 Message-ID: References: <300B4DA2-6802-44D5-AB61-CFA9F85573FE@rpi.edu> In-Reply-To: <300B4DA2-6802-44D5-AB61-CFA9F85573FE@rpi.edu> 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: media-types@ietf.org, "public-prov-comments@w3.org" , ietf-xml-mime@imc.org Subject: Re: [media-types] request for comments on media types section of PROV-XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:32:27 -0000 * Stephan Zednik wrote: >link to media type section in editors draft of specification: >https://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html#media-type > >Type name: >application > >Subtype name: >provenance+xml > >Required parameters: >none > >Optional parameters: >charset - this parameter may be required when transferring non-ASCII data across some protocols. This should use language as provided in RFC 3023 section 7.1. >Encoding considerations: >The syntax of PROV-XML is expressed over code points in Unicode [[!UNICODE]] As above. >Security considerations: >[...] There are formatting problems here (like use of entity references). >Published specification: >PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau href="http://www.w3.org/TR/prov-xml/">http://www.w3.org/TR/prov-xml/, >2012. I believe this is still (after the RFC4288 revision) supposed to reference a specification that actually includes the template, and the published draft does not include it. >Additional Information: > > Magic number(s): > PROV-XML documents are XML documents and thus may have initial strings similar to any XML document. > > File extension(s): > .provx > > Base URI: > As in XML. I don't understand what that means; I suggest removing this field. >Author/Change controller: >The PROV-XML specification is the product of the World Wide Web >Consortium's Provenance Working Group. The W3C has change control over >this specification. Per http://tools.ietf.org/html/rfc6838#section-5.6 you should put that into two separate fields. I also note that you don't have any Fragment Identifier Considerations. -- 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/ From zednis@rpi.edu Mon Feb 25 23:55:51 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E039821F86DD for ; Mon, 25 Feb 2013 23:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMmfCx-gGQDS for ; Mon, 25 Feb 2013 23:55:49 -0800 (PST) Received: from smtp10.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D821F86D6 for ; Mon, 25 Feb 2013 23:55:46 -0800 (PST) Received: from smtp-auth2.server.rpi.edu (smtp-auth2.server.rpi.edu [128.113.2.232]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id r1Q7tfPO019799; Tue, 26 Feb 2013 02:55:41 -0500 Received: from smtp-auth2.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth2.server.rpi.edu (Postfix) with ESMTP id 8210218007; Tue, 26 Feb 2013 02:53:31 -0500 (EST) Received: from [192.168.1.139] (c-76-120-60-27.hsd1.co.comcast.net [76.120.60.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zednis) by smtp-auth2.server.rpi.edu (Postfix) with ESMTPSA id 85DC718002; Tue, 26 Feb 2013 02:53:30 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FAB3C27B-CF53-439F-A9AB-6684065D9976" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Stephan Zednik In-Reply-To: Date: Tue, 26 Feb 2013 00:55:43 -0700 Message-Id: References: <300B4DA2-6802-44D5-AB61-CFA9F85573FE@rpi.edu> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.5 (Score 0, tokens from: outgoing) X-CanIt-Incident-Id: 03J4TTFWi X-CanIt-Geo: ip=76.120.60.27; country=US; region=CO; city=Denver; latitude=39.7392; longitude=-104.9847; metrocode=751; areacode=303; http://maps.google.com/maps?q=39.7392,-104.9847&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Cc: media-types@ietf.org, "public-prov-comments@w3.org" , ietf-xml-mime@imc.org Subject: Re: [media-types] request for comments on media types section of PROV-XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 07:55:52 -0000 --Apple-Mail=_FAB3C27B-CF53-439F-A9AB-6684065D9976 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 25, 2013, at 7:31 AM, Bjoern Hoehrmann wrote: > * Stephan Zednik wrote: >> link to media type section in editors draft of specification: =20 >> = https://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html#media-type >>=20 >> Type name: >> application >>=20 >> Subtype name: >> provenance+xml >>=20 >> Required parameters: >> none >>=20 >> Optional parameters: >> charset - this parameter may be required when transferring non-ASCII = data across some protocols. >=20 > This should use language as provided in RFC 3023 section 7.1. Here, and a few areas below such as with "Base URI" I was following the = example OWL XML. from = http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type= .2C_File_Extension.2C_and_Macintosh_File_Type Should it be: "Same as charset parameter of application/xml as specified in RFC 3023 = (Section 3.2)." >=20 >> Encoding considerations: >> The syntax of PROV-XML is expressed over code points in Unicode = [[!UNICODE]] >=20 > As above. Should it be: "Same as encoding considerations of application/xml as specified in RFC = 3023 (Section 3.2)." >=20 >> Security considerations: >> [...] >=20 > There are formatting problems here (like use of entity references). Is the use of entity references here bad? Or is there something wrong = with them? Is the content ok? >=20 >> Published specification: >> PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau > = href=3D"http://www.w3.org/TR/prov-xml/">http://www.w3.org/TR/prov-xml/= ,=20 >> 2012. >=20 > I believe this is still (after the RFC4288 revision) supposed to > reference a specification that actually includes the template, and > the published draft does not include it. Could you rephrase? or better yet, provide insight on what should go = here. >=20 >> Additional Information: >>=20 >> Magic number(s): >> PROV-XML documents are XML documents and thus may have initial = strings similar to any XML document. >>=20 >> File extension(s): >> .provx >>=20 >> Base URI: >> As in XML. >=20 > I don't understand what that means; I suggest removing this field. I assume you mean "Base URI" and not all of "Additional Information"? Here I was following the example from the OWL XML. Base URI is mentioned in RFC 3023 Section 7.1 "These registrations SHOULD also make reference to RFC 3023 in = specifying magic numbers, fragment identifiers, base URIs, and use of = the BOM." >=20 >> Author/Change controller: >> The PROV-XML specification is the product of the World Wide Web=20 >> Consortium's Provenance Working Group. The W3C has change control = over=20 >> this specification. >=20 > Per http://tools.ietf.org/html/rfc6838#section-5.6 you should put that > into two separate fields. Author: The PROV-XML specification is the product of the World Wide Web = Consortium's Provenance Working Group. Change controller: The W3C has change control over this specification. > I also note that you don't have any Fragment > Identifier Considerations. I don't have any beyond what is in RFC 3023 Section 5. Should I put "none" or "Same as RFC 3023 (Section 5.)."? --Stephan > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 >=20 >=20 --Apple-Mail=_FAB3C27B-CF53-439F-A9AB-6684065D9976 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 derhoermi@gmx.net> = wrote:
* Stephan Zednik wrote:
link = to media type section in editors draft of specification:  
https://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html#me= dia-type

Type name:
application

Subtype = name:
provenance+xml

Required = parameters:
none

Optional parameters:
charset - this = parameter may be required when transferring non-ASCII data across some = protocols.

This should use language as provided in = RFC 3023 section 7.1.

Here, and a = few areas below such as with "Base URI" I was following the example OWL = XML.


Should it = be:

"3023 (Section 3.2)



Encoding = considerations:
The syntax of PROV-XML is expressed over code points = in Unicode [[!UNICODE]]

As = above.

Should it = be:

"Same as encoding considerations of = application/xml as specified in RFC 3023 (Section = 3.2)."


Security = considerations:
[...]

There are formatting = problems here (like use of entity = references).

Is the use of entity = references here bad?  Or is there something wrong with = them?

Is the content ok?


Published = specification:
PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik = (eds), Moreau <a
href=3D"http://www.w3.org/TR/prov-xml/= ">http://www.w3.org/TR/pro= v-xml/</a>,
2012.

I believe this is = still (after the RFC4288 revision) supposed to
reference a = specification that actually includes the template, and
the published = draft does not include it.

Could you = rephrase?  or better yet, provide insight on what should go = here.


Additional Information:

Magic = number(s):
= PROV-XML documents are XML documents and thus may have initial = strings similar to any XML document.

File extension(s):
= .provx

Base URI:
As in = XML.

I don't understand what that means; I suggest = removing this field.

I assume you mean = "Base URI" and not all of "Additional = Information"?

Here I was following the example = from the OWL XML.

Base URI is mentioned in RFC = 3023 Section 7.1

"These registrations SHOULD also make reference to RFC 3023 = in specifying magic = numbers, fragment identifiers, base URIs, and use of the = BOM."


Author/Change controller:
The PROV-XML specification is = the product of the World Wide Web
Consortium's Provenance Working = Group. The W3C has change control over
this = specification.

Per http://tools.ietf.= org/html/rfc6838#section-5.6 you should put that
into two = separate fields.

Author:
The PROV-XML specification is = the product of the World Wide Web Consortium's Provenance Working = Group.
Change controller:
The W3C has change control over this = specification.


I = also note that you don't have any Fragment
Identifier = Considerations.

I don't have any = beyond what is in RFC 3023 Section 5.

Should I = put "none" or "Same as RFC 3023 (Section = 5.)."?

--Stephan

--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de
Am = Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
2589= 9 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/ =



= --Apple-Mail=_FAB3C27B-CF53-439F-A9AB-6684065D9976-- From derhoermi@gmx.net Tue Feb 26 03:21:57 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461A821F8A1D for ; Tue, 26 Feb 2013 03:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWK28wTB+tFM for ; Tue, 26 Feb 2013 03:21:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1942121F8A25 for ; Tue, 26 Feb 2013 03:21:49 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MCeui-1U258w0hIQ-009O0l for ; Tue, 26 Feb 2013 12:21:48 +0100 Received: (qmail invoked by alias); 26 Feb 2013 11:21:47 -0000 Received: from p5B232021.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.32.33] by mail.gmx.net (mp004) with SMTP; 26 Feb 2013 12:21:47 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19Z7poyZq1Z4p6Wdm7gTG8B37VF+2hl+i7YBYyzJS 2SKUlfKN0hDf22 From: Bjoern Hoehrmann To: Stephan Zednik Date: Tue, 26 Feb 2013 12:21:45 +0100 Message-ID: References: <300B4DA2-6802-44D5-AB61-CFA9F85573FE@rpi.edu> In-Reply-To: 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: media-types@ietf.org, "public-prov-comments@w3.org" , ietf-xml-mime@imc.org Subject: Re: [media-types] request for comments on media types section of PROV-XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:21:57 -0000 * Stephan Zednik wrote: >On Feb 25, 2013, at 7:31 AM, Bjoern Hoehrmann wrote: >> * Stephan Zednik wrote: >>> Optional parameters: >>> charset - this parameter may be required when transferring non-ASCII data across some protocols. >> >> This should use language as provided in RFC 3023 section 7.1. > >Here, and a few areas below such as with "Base URI" I was following the example OWL XML. > >from http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type.2C_File_Extension.2C_and_Macintosh_File_Type It would be better to follow the example of a registered type. The type there has not been registered. >Should it be: > >"Same as charset parameter of application/xml as specified in RFC 3023 (Section 3.2)." Yes. >>> Encoding considerations: >>> The syntax of PROV-XML is expressed over code points in Unicode [[!UNICODE]] >> >> As above. > >Should it be: > >"Same as encoding considerations of application/xml as specified in RFC 3023 (Section 3.2)." Yes. >>> Security considerations: >>> [...] >> >> There are formatting problems here (like use of entity references). > >Is the use of entity references here bad? Or is there something wrong with them? Using them in plain text documents is bad, yes. >>> Published specification: >>> PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau >> href="http://www.w3.org/TR/prov-xml/">http://www.w3.org/TR/prov-xml/, >>> 2012. >> >> I believe this is still (after the RFC4288 revision) supposed to >> reference a specification that actually includes the template, and >> the published draft does not include it. > >Could you rephrase? or better yet, provide insight on what should go here. The issue will go away when your editor's draft is published under the address given above and the specification reference is updated to refer to it (it would have to cite "2013" as the year, then). >>> Additional Information: >>> >>> Magic number(s): >>> PROV-XML documents are XML documents and thus may have initial strings similar to any XML document. >>> >>> File extension(s): >>> .provx >>> >>> Base URI: >>> As in XML. >> >> I don't understand what that means; I suggest removing this field. > >I assume you mean "Base URI" and not all of "Additional Information"? Yes. >> I also note that you don't have any Fragment >> Identifier Considerations. > >I don't have any beyond what is in RFC 3023 Section 5. > >Should I put "none" or "Same as RFC 3023 (Section 5.)."? A value of "N/A" might be best. -- 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/ From zednis@rpi.edu Wed Feb 27 00:51:28 2013 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618521F85BB for ; Wed, 27 Feb 2013 00:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91i+5HhAAuwR for ; Wed, 27 Feb 2013 00:51:27 -0800 (PST) Received: from smtp9.server.rpi.edu (smtp9.server.rpi.edu [128.113.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4D421F85A1 for ; Wed, 27 Feb 2013 00:51:26 -0800 (PST) Received: from smtp-auth1.server.rpi.edu (smtp-auth1.server.rpi.edu [128.113.2.231]) by smtp9.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id r1R8ihN1012516; Wed, 27 Feb 2013 03:44:44 -0500 Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id B64365800B; Wed, 27 Feb 2013 03:48:35 -0500 (EST) Received: from [192.168.1.139] (c-76-120-60-27.hsd1.co.comcast.net [76.120.60.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zednis) by smtp-auth1.server.rpi.edu (Postfix) with ESMTPSA id EB6FE5800A; Wed, 27 Feb 2013 03:48:34 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Stephan Zednik In-Reply-To: Date: Wed, 27 Feb 2013 01:51:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <300B4DA2-6802-44D5-AB61-CFA9F85573FE@rpi.edu> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.5 (Score 0, tokens from: outgoing) X-CanIt-Incident-Id: 02J5kIIhV X-CanIt-Geo: ip=76.120.60.27; country=US; region=CO; city=Denver; latitude=39.7392; longitude=-104.9847; metrocode=751; areacode=303; http://maps.google.com/maps?q=39.7392,-104.9847&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.229 Cc: media-types@ietf.org, "public-prov-comments@w3.org" , ietf-xml-mime@imc.org Subject: Re: [media-types] request for comments on media types section of PROV-XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 08:51:28 -0000 Hi Bjoern, how is this? --Stephan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Type name: application Subtype name: provenance+xml Required parameters: none Optional parameters: Same as charset parameter of application/xml as specified in RFC3023 = (Section 3.2). Encoding considerations: Same as encoding considerations of application/xml as specified in RFC = 3023 (Section 3.2). Security considerations: PROV-XML is an XML language for describing the provenance of things; = applications may evaluate given data to dereference URIs, invoking the = security considerations of the scheme for that URI. Note in particular, = the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained = from an inaccurate or malicious data source may lead to inaccurate or = misleading conclusions, as well as the dereferencing of unintended URIs. = Care must be taken to align the trust in consulted resources with the = sensitivity of the intended use of the data. PROV-XML can express data which is presented to the user, for example, = by means of label attributes. Application rendering strings retrieved = from untrusted PROV-N documents must ensure that malignant strings may = not be used to mislead the reader. The security considerations in the = media type registration for XML ([RFC3023] section 10) provide = additional guidance around the expression of arbitrary data and markup. PROV-XML is a language for describing the provenance of things, and = therefore a PROV-XML document is metadata for other resources. Untrusted = PROV-XML documents may mislead its consumers by indicating that a = third-party resource has a reputable lineage, when it has not. = Provenance of PROV-XML document should be sought. PROV-XML uses QNames mappable to IRIs as term identifiers. Applications = interpreting data expressed in PROV-XML should address the security = issues of Internationalized Resource Identifiers (IRIs) [RFC3987] = Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax = [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different = scripts may look similar (a Cyrillic "=D0=BE" may appear similar to a = Latin "o"). A character followed by combining characters may have the = same visual representation as another character (LATIN SMALL LETTER E = followed by COMBINING ACUTE ACCENT has the same visual representation as = LATIN SMALL LETTER E WITH ACUTE). Any person or application that is = writing or interpreting data in PROV-N must take care to use the IRI = that matches the intended semantics, and avoid IRIs that make look = similar. Further information about matching of similar characters can be = found in Unicode Security Considerations [UNISEC] and Internationalized = Resource Identifiers (IRIs) [RFC3987] Section 8. Interoperability considerations: There are no known interoperability issues. Published specification: PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau = http://www.w3.org/TR/prov-xml/, 2013. Applications which use this media type: It may be used by any application for publishing provenance information. = This format is designed to be an XML form of provenance. Fragment identifier considerations: N/A Additional Information: Magic number(s): PROV-XML documents are XML documents and thus may have initial strings = similar to any XML document. File extension(s): .provx Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Ivan Herman, ivan@w3.org Intended usage: COMMON Restrictions on usage: None Author: The PROV-XML specification is the product of the World Wide Web = Consortium's Provenance Working Group. Change controller: The W3C, and the W3C Provenance Working Group, have change control over = this specification. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Feb 26, 2013, at 4:21 AM, Bjoern Hoehrmann wrote: > * Stephan Zednik wrote: >> On Feb 25, 2013, at 7:31 AM, Bjoern Hoehrmann = wrote: >>> * Stephan Zednik wrote: >>>> Optional parameters: >>>> charset - this parameter may be required when transferring = non-ASCII data across some protocols. >>>=20 >>> This should use language as provided in RFC 3023 section 7.1. >>=20 >> Here, and a few areas below such as with "Base URI" I was following = the example OWL XML. >>=20 >> from = http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type= .2C_File_Extension.2C_and_Macintosh_File_Type >=20 > It would be better to follow the example of a registered type. The = type > there has not been registered. >=20 >> Should it be: >>=20 >> "Same as charset parameter of application/xml as specified in RFC = 3023 (Section 3.2)." >=20 > Yes. >=20 >>>> Encoding considerations: >>>> The syntax of PROV-XML is expressed over code points in Unicode = [[!UNICODE]] >>>=20 >>> As above. >>=20 >> Should it be: >>=20 >> "Same as encoding considerations of application/xml as specified in = RFC 3023 (Section 3.2)." >=20 > Yes. >=20 >>>> Security considerations: >>>> [...] >>>=20 >>> There are formatting problems here (like use of entity references). >>=20 >> Is the use of entity references here bad? Or is there something = wrong with them? >=20 > Using them in plain text documents is bad, yes. >=20 >>>> Published specification: >>>> PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau >>> = href=3D"http://www.w3.org/TR/prov-xml/">http://www.w3.org/TR/prov-xml/= ,=20 >>>> 2012. >>>=20 >>> I believe this is still (after the RFC4288 revision) supposed to >>> reference a specification that actually includes the template, and >>> the published draft does not include it. >>=20 >> Could you rephrase? or better yet, provide insight on what should go = here. >=20 > The issue will go away when your editor's draft is published under the > address given above and the specification reference is updated to = refer > to it (it would have to cite "2013" as the year, then). >=20 >>>> Additional Information: >>>>=20 >>>> Magic number(s): >>>> PROV-XML documents are XML documents and thus may have initial = strings similar to any XML document. >>>>=20 >>>> File extension(s): >>>> .provx >>>>=20 >>>> Base URI: >>>> As in XML. >>>=20 >>> I don't understand what that means; I suggest removing this field. >>=20 >> I assume you mean "Base URI" and not all of "Additional Information"? >=20 > Yes. >=20 >>> I also note that you don't have any Fragment >>> Identifier Considerations. >>=20 >> I don't have any beyond what is in RFC 3023 Section 5. >>=20 >> Should I put "none" or "Same as RFC 3023 (Section 5.)."? >=20 > A value of "N/A" might be best. > --=20 > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 = http://www.bjoernsworld.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 = http://www.websitedev.de/=20 >=20 >=20