From nobody Thu Jun 9 08:31:38 2016 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 3A6E112D11C for ; Thu, 9 Jun 2016 08:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM3ZsN4XHEl1 for ; Thu, 9 Jun 2016 08:31:36 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B4B12B009 for ; Thu, 9 Jun 2016 08:31:34 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u59FVEkd012566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jun 2016 15:31:34 GMT Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by fallback-in2.mxes.net (Postfix) with ESMTP id 0A6172FDC2B for ; Thu, 9 Jun 2016 11:31:13 -0400 (EDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E0112509B6; Thu, 9 Jun 2016 11:30:31 -0400 (EDT) To: "media-types@iana.org" From: Sean Leonard Message-ID: <46fc6302-ad89-a185-330d-d7ef8318740c@seantek.com> Date: Thu, 9 Jun 2016 08:31:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Thu, 09 Jun 2016 15:31:34 +0000 (UTC) Archived-At: Cc: Julian Reschke , RFC Editor Subject: [media-types] The styling of media types in IETF specifications X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 15:31:37 -0000 During the publication of draft-seantek-windows-image-03 (soon to be=20 RFC 7903), the RFC Editor questioned: > 2) We note that the names of the media types being registered > sometimes appear without quotation marks (e.g., image/x-wmf) and a > couple of times appear enclosed in double quotation marks (e.g., > "image/x-wmf"). Should the usage be consistent? I checked RFC 6838, and RFC 6838 is itself inconsistent between quoting=20 and unquoting media types. How shall media types in IETF specifications be stylized in plain text,=20 and in xml2rfc? Specifically: shall they be quoted "application/pdf", or = unquoted application/pdf? In xml2rfc, shall they be quoted or unquoted,=20 shall the quotes be curly quotes or straight quotes, and shall the text=20 be in elements or plain? My 2=C2=A2: When referring to the media type as a string in a protocol element, in=20 plain text "application/pdf" is correct (possibly with other elements,=20 e.g., "text/plain; charset=3DISO-8859-1". In xml2rfc, the same situations= =20 should be covered by application/pdf (no quotes). When referring to the media type as a prose statement of the contents or = using the media type for its semantics, do not use quotes and do not=20 encase in . Examples: An application that renders application/pdf data needs to put it in a = window with scroll bars. When a generator generates text/html, it SHOULD balance the tags. Basically the use of the media type can be substituted by a prose and=20 possibly more unwieldy description, such as: An application that renders PDFs needs to put it in a window with=20 scroll bars. When a generator generates HTML documents, it SHOULD balance the tags.= Thank you, Sean From nobody Thu Jun 9 10:43:04 2016 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 8766812D6A7 for ; Thu, 9 Jun 2016 10:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE2ZXv2uMj9C for ; Thu, 9 Jun 2016 10:43:01 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208C312D526 for ; Thu, 9 Jun 2016 10:43:01 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u59HgeYe023900 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 9 Jun 2016 17:43:01 GMT Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u59HdIH2039349; Thu, 9 Jun 2016 13:42:36 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 23fcny0rf8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jun 2016 13:42:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u59HgXKK028029; Thu, 9 Jun 2016 13:42:34 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u59HgPYJ027867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jun 2016 13:42:30 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 9 Jun 2016 17:42:07 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.125]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 13:42:07 -0400 From: "HANSEN, TONY L" To: Sean Leonard , "media-types@iana.org" Thread-Topic: [media-types] The styling of media types in IETF specifications Thread-Index: AQHRwmQJAGqZwPSrPkysq8qRqBkItp/hZ7IA Date: Thu, 9 Jun 2016 17:42:07 +0000 Message-ID: References: <46fc6302-ad89-a185-330d-d7ef8318740c@seantek.com> In-Reply-To: <46fc6302-ad89-a185-330d-d7ef8318740c@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.110.223] Content-Type: text/plain; charset="utf-8" Content-ID: <18050093F89A82489865CB0E84ED0716@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-09_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606090194 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Thu, 09 Jun 2016 17:43:01 +0000 (UTC) Archived-At: Cc: RFC Editor , Julian Reschke Subject: Re: [media-types] The styling of media types in IETF specifications X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 17:43:03 -0000 SU1POiBXaXRoaW4gYSBkb2N1bWVudCwgYW4gYXV0aG9yIHNob3VsZCBiZSBjb25zaXN0ZW50LiBJ ZiB0aGV5IGFyZSBub3QsIHRoYXQgaXMgd29ydGggcG9pbnRpbmcgb3V0LCBidXQgbm90IHdvcnRo IHJlamVjdGluZyBhIGRvY3VtZW50IGlmIHRoZXkgY2hvb3NlIG5vdCB0byBiZS4gQnV0IGFkdm9j YXRpbmcgbW9yZSB0aGFuIHRoYXQgaXMgZ29pbmcgdG9vIGZhci4gQW5kIGl0IGNlcnRhaW5seSBk b2VzbuKAmXQgbmVlZCB0byBiZSB3cml0dGVuIGd1aWRhbmNlIGFueXdoZXJlLg0KDQoJVG9ueSBI YW5zZW4NCg0KT24gNi85LzE2LCAxMTozMSBBTSwgIm1lZGlhLXR5cGVzIG9uIGJlaGFsZiBvZiBT ZWFuIExlb25hcmQiIDxtZWRpYS10eXBlcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBk ZXYraWV0ZkBzZWFudGVrLmNvbT4gd3JvdGU6DQoNCj4gIER1cmluZyB0aGUgcHVibGljYXRpb24g b2YgZHJhZnQtc2VhbnRlay13aW5kb3dzLWltYWdlLTAzIChzb29uIHRvIGJlIA0KPlJGQyA3OTAz KSwgdGhlIFJGQyBFZGl0b3IgcXVlc3Rpb25lZDoNCj4NCj4+IDIpIFdlIG5vdGUgdGhhdCB0aGUg bmFtZXMgb2YgdGhlIG1lZGlhIHR5cGVzIGJlaW5nIHJlZ2lzdGVyZWQNCj4+IHNvbWV0aW1lcyBh cHBlYXIgd2l0aG91dCBxdW90YXRpb24gbWFya3MgKGUuZy4sIGltYWdlL3gtd21mKSBhbmQgYQ0K Pj4gY291cGxlIG9mIHRpbWVzIGFwcGVhciBlbmNsb3NlZCBpbiBkb3VibGUgcXVvdGF0aW9uIG1h cmtzIChlLmcuLA0KPj4gImltYWdlL3gtd21mIikuIFNob3VsZCB0aGUgdXNhZ2UgYmUgY29uc2lz dGVudD8NCj4NCj5JIGNoZWNrZWQgUkZDIDY4MzgsIGFuZCBSRkMgNjgzOCBpcyBpdHNlbGYgaW5j b25zaXN0ZW50IGJldHdlZW4gcXVvdGluZyANCj5hbmQgdW5xdW90aW5nIG1lZGlhIHR5cGVzLg0K Pg0KPkhvdyBzaGFsbCBtZWRpYSB0eXBlcyBpbiBJRVRGIHNwZWNpZmljYXRpb25zIGJlIHN0eWxp emVkIGluIHBsYWluIHRleHQsIA0KPmFuZCBpbiB4bWwycmZjPyBTcGVjaWZpY2FsbHk6IHNoYWxs IHRoZXkgYmUgcXVvdGVkICJhcHBsaWNhdGlvbi9wZGYiLCBvciANCj51bnF1b3RlZCBhcHBsaWNh dGlvbi9wZGY/IEluIHhtbDJyZmMsIHNoYWxsIHRoZXkgYmUgcXVvdGVkIG9yIHVucXVvdGVkLCAN Cj5zaGFsbCB0aGUgcXVvdGVzIGJlIGN1cmx5IHF1b3RlcyBvciBzdHJhaWdodCBxdW90ZXMsIGFu ZCBzaGFsbCB0aGUgdGV4dCANCj5iZSBpbiA8dHQ+IGVsZW1lbnRzIG9yIHBsYWluPw0KPg0KPk15 IDLCojoNCj4NCj5XaGVuIHJlZmVycmluZyB0byB0aGUgbWVkaWEgdHlwZSBhcyBhIHN0cmluZyBp biBhIHByb3RvY29sIGVsZW1lbnQsIGluIA0KPnBsYWluIHRleHQgImFwcGxpY2F0aW9uL3BkZiIg aXMgY29ycmVjdCAocG9zc2libHkgd2l0aCBvdGhlciBlbGVtZW50cywgDQo+ZS5nLiwgInRleHQv cGxhaW47IGNoYXJzZXQ9SVNPLTg4NTktMSIuIEluIHhtbDJyZmMsIHRoZSBzYW1lIHNpdHVhdGlv bnMgDQo+c2hvdWxkIGJlIGNvdmVyZWQgYnkgPHR0PmFwcGxpY2F0aW9uL3BkZjwvdHQ+IChubyBx dW90ZXMpLg0KPg0KPldoZW4gcmVmZXJyaW5nIHRvIHRoZSBtZWRpYSB0eXBlIGFzIGEgcHJvc2Ug c3RhdGVtZW50IG9mIHRoZSBjb250ZW50cyBvciANCj51c2luZyB0aGUgbWVkaWEgdHlwZSBmb3Ig aXRzIHNlbWFudGljcywgZG8gbm90IHVzZSBxdW90ZXMgYW5kIGRvIG5vdCANCj5lbmNhc2UgaW4g PHR0Pi4gRXhhbXBsZXM6DQo+DQo+ICAgQW4gYXBwbGljYXRpb24gdGhhdCByZW5kZXJzIGFwcGxp Y2F0aW9uL3BkZiBkYXRhIG5lZWRzIHRvIHB1dCBpdCBpbiBhIA0KPndpbmRvdyB3aXRoIHNjcm9s bCBiYXJzLg0KPg0KPiAgIFdoZW4gYSBnZW5lcmF0b3IgZ2VuZXJhdGVzIHRleHQvaHRtbCwgaXQg U0hPVUxEIGJhbGFuY2UgdGhlIHRhZ3MuDQo+DQo+QmFzaWNhbGx5IHRoZSB1c2Ugb2YgdGhlIG1l ZGlhIHR5cGUgY2FuIGJlIHN1YnN0aXR1dGVkIGJ5IGEgcHJvc2UgYW5kIA0KPnBvc3NpYmx5IG1v cmUgdW53aWVsZHkgZGVzY3JpcHRpb24sIHN1Y2ggYXM6DQo+DQo+ICAgQW4gYXBwbGljYXRpb24g dGhhdCByZW5kZXJzIFBERnMgbmVlZHMgdG8gcHV0IGl0IGluIGEgd2luZG93IHdpdGggDQo+c2Ny b2xsIGJhcnMuDQo+DQo+ICAgV2hlbiBhIGdlbmVyYXRvciBnZW5lcmF0ZXMgSFRNTCBkb2N1bWVu dHMsIGl0IFNIT1VMRCBiYWxhbmNlIHRoZSB0YWdzLg0KPg0KPg0KPlRoYW5rIHlvdSwNCj4NCj5T ZWFuDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5tZWRpYS10eXBlcyBtYWlsaW5nIGxpc3QNCj5tZWRpYS10eXBlc0BpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVkaWEtdHlwZXMNCg0K From nobody Thu Jun 9 16:46:34 2016 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 1FD4C12D7F1 for ; Thu, 9 Jun 2016 16:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynOBWlbu_RH1 for ; Thu, 9 Jun 2016 16:46:32 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC75D12D7CE for ; Thu, 9 Jun 2016 16:46:31 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id u59NkA1q015685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jun 2016 23:46:31 GMT Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in2.mxes.net (Postfix) with ESMTP id 8FBD12FDC2B for ; Thu, 9 Jun 2016 19:46:10 -0400 (EDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 861E722E1F3; Thu, 9 Jun 2016 19:45:27 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2016 09:45:25 +1000 Message-Id: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> To: "media-types@iana.org" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Thu, 09 Jun 2016 23:46:31 +0000 (UTC) Archived-At: Cc: Benoit Claise , Andy Bierman Subject: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 23:46:33 -0000 YANG is attempting to register a number of media types that begin with = "application/yang."; see: = https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 E.g., it calls "application/yang.api" a "subtype" of "application/yang". I read RFC6838 to prohibit this, because the portion of a subtype = preceded by the first "." indicates the registration tree in a facet, = and faceted media types are prohibited from being registered in the = standards tree (unless they're grandfathered in in Appendix A). = Furthermore, the drafts' use of "subtype" is erroneous. Is that understanding correct? If so, should they be using different = media types, or is there some other way to accommodate what they want? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 9 19:14:59 2016 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 0ABFF12DA61 for ; Thu, 9 Jun 2016 19:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdA5BuKQV3H3 for ; Thu, 9 Jun 2016 19:14:56 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E78412D5BF for ; Thu, 9 Jun 2016 19:14:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5A2EYDd013225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jun 2016 02:14:55 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4536E509B6; Thu, 9 Jun 2016 22:14:33 -0400 (EDT) To: Mark Nottingham , "media-types@iana.org" References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> From: Sean Leonard Message-ID: <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> Date: Thu, 9 Jun 2016 19:15:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Delayed for 10:44:02 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Fri, 10 Jun 2016 02:14:55 +0000 (UTC) Archived-At: Cc: Benoit Claise , Andy Bierman Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 02:14:58 -0000 When it comes to Internet media types, "subtype" refers to everything=20 after the "/" and "type" refers to everything prior to the "/". The field "Subtype name" is a field in the media type registration=20 template--its usage in those drafts is correct. When referring to the construct as a whole, the term "media type" is=20 generally used, not "media subtype" or "subtype". However, I suppose=20 that "subtype" would be technically correct (although not preferred)=20 because application/xml (for example) is actually a subtype of=20 application. Stylistically it should be called the media type=20 application/xml, etc. They should be called application/yang-api, application/yang-patch,=20 application/yang-patch-status, etc. I am assuming that YANG is referring specifically to the language (akin=20 to saying "C++" or "JavaScript"), and not referring specifically to the=20 structured syntax (akin to saying "JSON"). If YANG is referring=20 specifically to a structured syntax, then the media types should end in=20 +yang. My knowledge of YANG is not deep enough to opine further on this=20 point. Regards, Sean On 6/9/2016 4:45 PM, Mark Nottingham wrote: > YANG is attempting to register a number of media types that begin with = "application/yang."; see: > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section= -4.2 > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-1= 1.3 > > E.g., it calls "application/yang.api" a "subtype" of "application/yang"= =2E > > I read RFC6838 to prohibit this, because the portion of a subtype prece= ded by the first "." indicates the registration tree in a facet, and face= ted media types are prohibited from being registered in the standards tre= e (unless they're grandfathered in in Appendix A). Furthermore, the draft= s' use of "subtype" is erroneous. > > Is that understanding correct? If so, should they be using different me= dia types, or is there some other way to accommodate what they want? > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Thu Jun 9 19:35:24 2016 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 02D0F12D8F4 for ; Thu, 9 Jun 2016 19:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqYLcsAX3yKt for ; Thu, 9 Jun 2016 19:35:20 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9DD12D8F5 for ; Thu, 9 Jun 2016 19:35:20 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5A2Z0BB008519 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jun 2016 02:35:20 GMT Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3C29822E1F3; Thu, 9 Jun 2016 22:34:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> Date: Fri, 10 Jun 2016 12:34:53 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3124) X-Greylist: Delayed for 02:49:31 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 10 Jun 2016 02:35:20 +0000 (UTC) Archived-At: Cc: Benoit Claise , "media-types@iana.org" , Andy Bierman Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 02:35:23 -0000 > On 10 Jun 2016, at 12:15 PM, Sean Leonard = wrote: >=20 > When it comes to Internet media types, "subtype" refers to everything = after the "/" and "type" refers to everything prior to the "/". >=20 > The field "Subtype name" is a field in the media type registration = template--its usage in those drafts is correct. Even: """ The parent MIME media type for RESTCONF resources is application/yang, = which is defined in [RFC6020]. This document defines the following = sub-types for this media type. """ ? That seems to read as if "application/foo.bar" is a subtype of = "application/foo". >=20 > When referring to the construct as a whole, the term "media type" is = generally used, not "media subtype" or "subtype". However, I suppose = that "subtype" would be technically correct (although not preferred) = because application/xml (for example) is actually a subtype of = application. Stylistically it should be called the media type = application/xml, etc. >=20 > They should be called application/yang-api, application/yang-patch, = application/yang-patch-status, etc. >=20 > I am assuming that YANG is referring specifically to the language = (akin to saying "C++" or "JavaScript"), and not referring specifically = to the structured syntax (akin to saying "JSON"). If YANG is referring = specifically to a structured syntax, then the media types should end in = +yang. My knowledge of YANG is not deep enough to opine further on this = point. >=20 > Regards, >=20 > Sean >=20 > On 6/9/2016 4:45 PM, Mark Nottingham wrote: >> YANG is attempting to register a number of media types that begin = with "application/yang."; see: >> = https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 >> = https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 >>=20 >> E.g., it calls "application/yang.api" a "subtype" of = "application/yang". >>=20 >> I read RFC6838 to prohibit this, because the portion of a subtype = preceded by the first "." indicates the registration tree in a facet, = and faceted media types are prohibited from being registered in the = standards tree (unless they're grandfathered in in Appendix A). = Furthermore, the drafts' use of "subtype" is erroneous. >>=20 >> Is that understanding correct? If so, should they be using different = media types, or is there some other way to accommodate what they want? >>=20 >> Cheers, >>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types >=20 >=20 >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 9 19:58:04 2016 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 BF8BF12D0F8 for ; Thu, 9 Jun 2016 19:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mQw2X_dDY_o for ; Thu, 9 Jun 2016 19:58:01 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF9712B007 for ; Thu, 9 Jun 2016 19:58:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5A2vet7013785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jun 2016 02:58:00 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7293E50A85; Thu, 9 Jun 2016 22:57:39 -0400 (EDT) To: Mark Nottingham References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> From: Sean Leonard Message-ID: <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> Date: Thu, 9 Jun 2016 19:58:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 10 Jun 2016 02:58:00 +0000 (UTC) Archived-At: Cc: Benoit Claise , "media-types@iana.org" , Andy Bierman Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 02:58:03 -0000 On 6/9/2016 7:34 PM, Mark Nottingham wrote: >> On 10 Jun 2016, at 12:15 PM, Sean Leonard wrote= : >> >> When it comes to Internet media types, "subtype" refers to everything = after the "/" and "type" refers to everything prior to the "/". >> >> The field "Subtype name" is a field in the media type registration tem= plate--its usage in those drafts is correct. > Even: > > """ > The parent MIME media type for RESTCONF resources is application/yang, = which is defined in [RFC6020]. This document defines the following sub-t= ypes for this media type. > """ > > ? That seems to read as if "application/foo.bar" is a subtype of "appli= cation/foo". Sorry, I missed that because I did a search on "subtypes" instead of=20 "sub-types" . On a technical note: is there a compelling reason why the media type has = to be application/yang-patch? The fact that it is a patch is obvious by=20 the use of the header "Accept-Patch". Why not just say application/yang, = or application/xml, or application/json, as appropriate? It looks (to me) like the content is obviously a patch or patch-status,=20 as evidenced by strings/data elements such as "ietf-yang-patch:yang-patch-status" and . I do not see a compelling reason to use the media type to duplicate=20 obvious information. **** On a related note: okay, now I am seeing "sub types" in=20 draft-ietf-netconf-restconf-13. Sneaky little devils, eh ;-) (I am=20 referring to the subtypes, not the authors ;-) ) Specifically: Subtype name: yang.xxx, where "xxx" is 1 of "api", "data", "datastore", "errors", "operation", or "stream" I have never seen a registration like this. Usually you have one=20 registration per subtype. What you're trying to do here, is much better served by using required=20 or optional parameters, namely: Content-Type: application/yang; subtype=3D"xxx" Where xxx is api, data, datastore, errors, operation, or stream. That=20 way it's extensible without needing another whole RFC for it. Must say=20 whether it's case sensitive; it looks case insensitive. May I suggest=20 renaming the parameter to something other than subtype, although nothing = better comes to mind... However, I think it is duplicitous (both redundant, and underhanded) to=20 have a subtype parameter when (as with yang patch) the data itself=20 describes the response very clearly, such as: We have seen this pattern elsewhere: see the registrations for PKCS #7 / = CMS and the smime-type and encapsulatingContent parameters. The problem is that this is basically a hint to a receiver of what lies=20 inside. But what if what lies inside doesn't match the parameter? Who=20 wins? You should say which one wins. Ideally, you should only have one=20 place in your protocol say what it is, to avoid divergent behavior. Regards, Sean > > >> When referring to the construct as a whole, the term "media type" is g= enerally used, not "media subtype" or "subtype". However, I suppose that = "subtype" would be technically correct (although not preferred) because a= pplication/xml (for example) is actually a subtype of application. Stylis= tically it should be called the media type application/xml, etc. >> >> They should be called application/yang-api, application/yang-patch, ap= plication/yang-patch-status, etc. >> >> I am assuming that YANG is referring specifically to the language (aki= n to saying "C++" or "JavaScript"), and not referring specifically to the= structured syntax (akin to saying "JSON"). If YANG is referring specific= ally to a structured syntax, then the media types should end in +yang. My= knowledge of YANG is not deep enough to opine further on this point. >> >> Regards, >> >> Sean >> >> On 6/9/2016 4:45 PM, Mark Nottingham wrote: >>> YANG is attempting to register a number of media types that begin wit= h "application/yang."; see: >>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#secti= on-4.2 >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section= -11.3 >>> >>> E.g., it calls "application/yang.api" a "subtype" of "application/yan= g". >>> >>> I read RFC6838 to prohibit this, because the portion of a subtype pre= ceded by the first "." indicates the registration tree in a facet, and fa= ceted media types are prohibited from being registered in the standards t= ree (unless they're grandfathered in in Appendix A). Furthermore, the dra= fts' use of "subtype" is erroneous. >>> >>> Is that understanding correct? If so, should they be using different = media types, or is there some other way to accommodate what they want? >>> >>> Cheers, >>> >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> _______________________________________________ >>> media-types mailing list >>> media-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/media-types >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Fri Jun 10 22:19:37 2016 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 5615112D794 for ; Fri, 10 Jun 2016 22:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coactus-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjJhvWAwnD3S for ; Fri, 10 Jun 2016 22:19:34 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D5712D58E for ; Fri, 10 Jun 2016 22:19:34 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5B5JDmj014335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jun 2016 05:19:33 GMT Received: by mail-vk0-x22c.google.com with SMTP id e4so122516741vkb.1 for ; Fri, 10 Jun 2016 22:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coactus-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lHCi9JaCUWEWahd86BSioe7UPxNNBkiTQm9ZdeHqd7g=; b=tI1Y/i7ZXaKzOsf/tJNU4ri7hSg9hWQq7EO8Yf8FHfxkgIYuzy26s/Ly6eloTNiekr 5L9RLTO47kaY12DKX5WxNXywmT4gO8kYqOUbc4Roab7bz8zZQysNGJW1By7vtynsKpuv +DSNhAzTPY3tvp3lJ2Dfx9DREWRyMw8GFwazcY81/bMfW1lkoV1UVgLLVR7EcOEs//jJ wdIk4d2bZY0ZIBlwNyLitacMmidWCBujpcC8eIbAov6PvJvbKGFMQW3JjG0fZ4EvVV1+ wS+JzElEC1+WGObnbfJQ8RgvdQvBGIQ+Ai92Jhgxh79gu9071IqJM6jRrDtCkfYFmt+b ohFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lHCi9JaCUWEWahd86BSioe7UPxNNBkiTQm9ZdeHqd7g=; b=gn7itXMB4Wuu4FW38FwJZ57+XZzITSghtUp/OhEUo/as52KfJ6KTmQKN+Lbd704X3E jdWHNg1Mz+wlnyvPe0BT61gch+ueCOnpHrjnzv8z5dZvZD9u2HNrzRxpi15Gyllromuy JUDwa8+8XYwky0+uCZ3PotqufE2Dguc/9gPuaHZzx2QmTaQ4GNir0euC2k+OofEZm1Sz UBN4CIMSee27G7ZlXywHCA8Da4HNqBqS9VSFNA4/fjsjVzVPzLTmQEQ4sWQmAmDP8Ssj PhZ6wTX1ECnFspE76U3lTXGc+QwPyyH1UiFiLEA9muooiwegb5hKk6OPrRJVpkMTo8pU G0Nw== X-Gm-Message-State: ALyK8tJ3ZfZnJRCFeR8TKmF6puy9+3Fp+SwyXt4LWy0HZJ2EXp7n4Nevp3cY/doOUud7eB27rqFhBeOkjOGEHA== X-Received: by 10.159.36.245 with SMTP id 108mr2340797uar.121.1465622352716; Fri, 10 Jun 2016 22:19:12 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.159.53.70 with HTTP; Fri, 10 Jun 2016 22:19:12 -0700 (PDT) X-Originating-IP: [23.233.58.109] In-Reply-To: <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> From: Mark Baker Date: Sat, 11 Jun 2016 01:19:12 -0400 X-Google-Sender-Auth: PMzyf6_JABEsjR0iBqdCTE8s7MU Message-ID: To: Sean Leonard Content-Type: text/plain; charset=UTF-8 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Sat, 11 Jun 2016 05:19:33 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Nottingham , "media-types@iana.org" , Andy Bierman Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jun 2016 05:19:35 -0000 On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard wrote: > On a technical note: is there a compelling reason why the media type has to > be application/yang-patch? The fact that it is a patch is obvious by the use > of the header "Accept-Patch". Why not just say application/yang, or > application/xml, or application/json, as appropriate? For the same reason we deliver HTML as text/html and not text/sgml or text/plain. IMO, these registrations look like they just need a +yang suffix. What they're currently doing is defining subtype facets as peers to vnd, prs, and x, and I can't imagine that was the intent. From nobody Fri Jun 10 23:17:37 2016 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 15FCC12DA76 for ; Fri, 10 Jun 2016 23:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w_EDV3wnvSs for ; Fri, 10 Jun 2016 23:17:34 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48AC12DA70 for ; Fri, 10 Jun 2016 23:17:33 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5B6HCT4022094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jun 2016 06:17:32 GMT Received: by mail-qg0-x235.google.com with SMTP id p34so46587820qgp.1 for ; Fri, 10 Jun 2016 23:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LJetd5C2NpMMdsdRfFWnbr00PSnY7CP9ciRELgYS7RA=; b=E+pdOrbjql/qIEWcghyF5PwwgEOUURIuBqU0WjkAcrXd24cY503Wf7qkRclkYW/IFC 0phE40lM3xn2u2NEJRzqc43lPbt8LmXlAGvgR3cISIKoJmxosgchLhJmLSdzVB4D7Nd1 gTak/LBZbMWPJmeY6VR0nCHg6IU+KFyR6llgUBfIZzJ3eLcJF+Chgad6KjAxbRr63ftx AkQrUERyt5LhRKJzQmFw0unN5HbLmVRWkH4bzzp74d73g2YEA+SyVcaPbBzEP22YUZqx bUnrq7MlhzUx/D2EnDxEGnzqpCRhiUScCWOG03Qjpr5QBcwbZ/k3u90Mp2zzHJfernPZ /UdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LJetd5C2NpMMdsdRfFWnbr00PSnY7CP9ciRELgYS7RA=; b=gyyJ1VwyP1gQgughVhDezOCyg7roNM+yk8OxEbGny7ijbH/fXwg2sdnjD6HAZO/6dU B1xosTqFUO32RUujbGHn6K1jxhEWRdDFYBYbU/P0o3s+ovygzcve29b2LpQwZWkLiCrT IZOhrGckTTBdo2uOS8vrk9rLUlK0Sbjcn+bPpumwvVK7RgFcNTzj6E4n480zG7FyLRNN FzaXYT6R1gNyn/pdQXPb4OeQJ0vE0MLcpZKqkhxNHiQoLQbW9+gFB09P62xortPWcZ3L DQNViH5cj0hQ/ddIiwvI/v7ahk9htsjPtGUiGA+HpsOHKI6m5z9r1lQ0G4Y48F5cL+uT 89YQ== X-Gm-Message-State: ALyK8tITlotc9sbsNawrWrid5CVP1/76zfSEhcUZTUjuAalg7plkR0mAOeCMN0QAMfV5N3GvPTj5GFowyozpsQ== MIME-Version: 1.0 X-Received: by 10.140.203.213 with SMTP id y204mr5373229qha.45.1465625832358; Fri, 10 Jun 2016 23:17:12 -0700 (PDT) Received: by 10.200.56.16 with HTTP; Fri, 10 Jun 2016 23:17:12 -0700 (PDT) In-Reply-To: References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> Date: Fri, 10 Jun 2016 23:17:12 -0700 Message-ID: From: Andy Bierman To: Mark Baker Content-Type: multipart/alternative; boundary=001a114f41181c9b590534fa9ba0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [IPv6:2620:0:2830:201::1:71]); Sat, 11 Jun 2016 06:17:32 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Nottingham , "media-types@iana.org" , Sean Leonard Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jun 2016 06:17:36 -0000 --001a114f41181c9b590534fa9ba0 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker wrote: > On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard > wrote: > > On a technical note: is there a compelling reason why the media type has > to > > be application/yang-patch? The fact that it is a patch is obvious by the > use > > of the header "Accept-Patch". Why not just say application/yang, or > > application/xml, or application/json, as appropriate? > > For the same reason we deliver HTML as text/html and not text/sgml or > text/plain. > > IMO, these registrations look like they just need a +yang suffix. What > they're currently doing is defining subtype facets as peers to vnd, > prs, and x, and I can't imagine that was the intent. > YANG is not an encoding format. It is a schema language. Instance documents conforming to YANG schema are encoded in XML or JSON. Andy --001a114f41181c9b590534fa9ba0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker <distobj@acm.org> wrote:
On Thu, Jun 9, 2016 at 10:58 = PM, Sean Leonard <dev+ietf@sea= ntek.com> wrote:
> On a technical note: is there a compelling reason why the media type h= as to
> be application/yang-patch? The fact that it is a patch is obvious by t= he use
> of the header "Accept-Patch". Why not just say application/y= ang, or
> application/xml, or application/json, as appropriate?

For the same reason we deliver HTML as text/html and not text/sgml or
text/plain.

IMO, these registrations look like they just need a +yang suffix. What
they're currently doing is defining subtype facets as peers to vnd,
prs, and x, and I can't imagine that was the intent.

YANG is not an enco= ding format. It is a schema language.
Insta= nce documents conforming to YANG schema are encoded in XML or JSON.

Andy

--001a114f41181c9b590534fa9ba0-- From nobody Sat Jun 11 10:17:18 2016 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 6F7E412D7EF for ; Sat, 11 Jun 2016 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMStrdFwKlR7 for ; Sat, 11 Jun 2016 10:17:16 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05FC12D638 for ; Sat, 11 Jun 2016 10:17:15 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5BHGtc4007108 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 11 Jun 2016 17:17:15 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 569DB509B8; Sat, 11 Jun 2016 13:16:53 -0400 (EDT) To: Andy Bierman , Mark Baker , "media-types@iana.org" References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> From: Sean Leonard Message-ID: <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> Date: Sat, 11 Jun 2016 10:17:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1F9132BB011A2D67955E40BF" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Sat, 11 Jun 2016 17:17:15 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Nottingham Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jun 2016 17:17:17 -0000 This is a multi-part message in MIME format. --------------1F9132BB011A2D67955E40BF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 6/10/2016 11:17 PM, Andy Bierman wrote: > > > On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker > wrote: > > On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard > > wrote: > > On a technical note: is there a compelling reason why the media > type has to > > be application/yang-patch? The fact that it is a patch is > obvious by the use > > of the header "Accept-Patch". Why not just say application/yang, = or > > application/xml, or application/json, as appropriate? > > For the same reason we deliver HTML as text/html and not text/sgml = or > text/plain. > > IMO, these registrations look like they just need a +yang suffix. W= hat > they're currently doing is defining subtype facets as peers to vnd,= > prs, and x, and I can't imagine that was the intent. > > > YANG is not an encoding format. It is a schema language. > Instance documents conforming to YANG schema are encoded in XML or JSON= =2E That confirms my suspicion. So, these proposed media type(s) should have = +xml, +json, or nothing (as structured syntax suffixes are optional,=20 they are really intended more as a hint to intermediate decoders such as = debugging tools). They should not have +yang. Sean --------------1F9132BB011A2D67955E40BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/10/2016 11:17 PM, Andy Bierman wrote:


On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker <distobj@acm.org> wrote:
On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
> On a technical note: is there a compelling reason why the media type has to
> be application/yang-patch? The fact that it is a patch is obvious by the use
> of the header "Accept-Patch". Why not just say application/yang, or
> application/xml, or application/json, as appropriate?

For the same reason we deliver HTML as text/html and not text/sgml or
text/plain.

IMO, these registrations look like they just need a +yang suffix. What
they're currently doing is defining subtype facets as peers to vnd,
prs, and x, and I can't imagine that was the intent.

YANG is not an encoding format. It is a schema language.
Instance documents conforming to YANG schema are encoded in XML or JSON.

That confirms my suspicion. So, these proposed media type(s) should have +xml, +json, or nothing (as structured syntax suffixes are optional, they are really intended more as a hint to intermediate decoders such as debugging tools). They should not have +yang.

Sean

--------------1F9132BB011A2D67955E40BF-- From nobody Sat Jun 11 10:22:43 2016 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 F214112D0AA for ; Sat, 11 Jun 2016 10:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIDUYLSN6w9P for ; Sat, 11 Jun 2016 10:22:39 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC8112B061 for ; Sat, 11 Jun 2016 10:22:39 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5BHMIYL026192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jun 2016 17:22:39 GMT Received: by mail-qg0-x231.google.com with SMTP id p34so50767227qgp.1 for ; Sat, 11 Jun 2016 10:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=c4tXsKD3EetHyEPCSVQi6DTTp1bonsBFXrs66QcYfAw=; b=o4Yt4O8hkoEKGtkl+nzmWJZxBc1i8Vc2k/jmcUTLmek3ghAfH3ReKzfG6t7+/vjIxr VBZF+WQLUi6aswb5y0fmR4I8Bhn1YxxY5bN3oM6Fsjr7Cicnd/6iColMsU+TbwVQKf2z E1KWaMpKicJdDZio96L+sENq5wrJcVAwDDbbVEwXPNwShOkmkbH0KQajC6FYUbP9aNtc PpD+WViBplWKMW0xx1xhLb9MHwPH+ka3IsWmyQYHN8mJgRIotTNeT/prOOxaf74sUNib 9uUbxoEb8bOQhKgbi0LmAS8EUXOZMt+6N77m4/RLA0iE0TTpH/P1M5xRWuMXtmzgbs4Y YOcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=c4tXsKD3EetHyEPCSVQi6DTTp1bonsBFXrs66QcYfAw=; b=XwvvQtx9fgXCOK9J9IyqFQpFbJ9EhHNfFYPwfaON7Rln5ZkAXYXbO5xfNSU4hlgEHn nsw9dPM24/Nq1rUGu1Hn6wXJIjkE581bl3yzS6N9qAMgndh8xRc9UALCUKIgEda/d7tt EQBPBFhkADx8o1fAUpOZd5ZhHCwwX1WE4BsIo088i7NXmvVSmvZt1aQvkSSLhSYt6NGO j1YdFiLfx2hf1wTr/3Ma3AI/C8b7OTxXLiLfGrulfkDZviRiU/pVrQ1pFHiO9tZsAQLd djfsAdz66dD9O0t9Tes0aEfcwhSokgAfeDXskjQIxyHNJwphDrj9SPK86Y/zWfCwSAXN USCw== X-Gm-Message-State: ALyK8tKs+uOAoc9aYczrhSk8eny4DMcmdCMPxgBbcZTkyBLdKj6sH9KNHp6JBG0bHqcLtCVCh6RD3keLlug5pQ== MIME-Version: 1.0 X-Received: by 10.141.44.69 with SMTP id v66mr2574381qhe.74.1465665738342; Sat, 11 Jun 2016 10:22:18 -0700 (PDT) Received: by 10.200.56.16 with HTTP; Sat, 11 Jun 2016 10:22:18 -0700 (PDT) In-Reply-To: <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> Date: Sat, 11 Jun 2016 10:22:18 -0700 Message-ID: From: Andy Bierman To: Sean Leonard Content-Type: multipart/alternative; boundary=94eb2c0bdc5cb19ca6053503e5f2 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Sat, 11 Jun 2016 17:22:39 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Baker , Mark Nottingham , "media-types@iana.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jun 2016 17:22:41 -0000 --94eb2c0bdc5cb19ca6053503e5f2 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 11, 2016 at 10:17 AM, Sean Leonard wrote: > On 6/10/2016 11:17 PM, Andy Bierman wrote: > > > > On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker wrote: > >> On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard < >> dev+ietf@seantek.com> wrote: >> > On a technical note: is there a compelling reason why the media type >> has to >> > be application/yang-patch? The fact that it is a patch is obvious by >> the use >> > of the header "Accept-Patch". Why not just say application/yang, or >> > application/xml, or application/json, as appropriate? >> >> For the same reason we deliver HTML as text/html and not text/sgml or >> text/plain. >> >> IMO, these registrations look like they just need a +yang suffix. What >> they're currently doing is defining subtype facets as peers to vnd, >> prs, and x, and I can't imagine that was the intent. >> > > YANG is not an encoding format. It is a schema language. > Instance documents conforming to YANG schema are encoded in XML or JSON. > > > That confirms my suspicion. So, these proposed media type(s) should have > +xml, +json, or nothing (as structured syntax suffixes are optional, they > are really intended more as a hint to intermediate decoders such as > debugging tools). They should not have +yang. > > Yes. The CORE WG is developing a YANG to CBOR mapping https://tools.ietf.org/html/draft-ietf-core-yang-cbor-00 So we have +xml and +json now, and soon +cbor I think the original question was whether our IANA requests were correct or not. Sean > > Andy --94eb2c0bdc5cb19ca6053503e5f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 11, 2016 at 10:17 AM, Sean Leonard <dev+ietf@seantek.co= m> wrote:
=20 =20 =20
On 6/10/2016 11:17 PM, Andy Bierman wrote:


On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker <distobj@acm.org> wrote:
On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
> On a technical note: is there a compelling reason why the media type has to
> be application/yang-patch? The fact that it is a patch is obvious by the use
> of the header "Accept-Patch". Why not just say application/yang, or
> application/xml, or application/json, as appropriate?
For the same reason we deliver HTML as text/html and not text/sgml or
text/plain.

IMO, these registrations look like they just need a +yang suffix. What
they're currently doing is defining subtype facets as peers to vnd,
prs, and x, and I can't imagine that was the intent.

YANG is not an encoding format. It is a schema language.
Instance documents conforming to YANG schema are encoded in XML or JSON.

That confirms my suspicion. So, these proposed media type(s) should have +xml, +json, or nothing (as structured syntax suffixes are optional, they are really intended more as a hint to intermediate decoders such as debugging tools). They should not have +yang.


Yes.=C2=A0 The= CORE WG is developing a YANG to CBOR mapping

So we have +xm= l and +json now, and soon +cbor

I think the origin= al question was whether our IANA requests were correct or not.
Sean


Andy

--94eb2c0bdc5cb19ca6053503e5f2-- From nobody Mon Jun 13 09:34:23 2016 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 CFA2112D87E for ; Mon, 13 Jun 2016 09:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coactus-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVpoFGba-N5S for ; Mon, 13 Jun 2016 09:34:20 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BAF12D1B9 for ; Mon, 13 Jun 2016 09:34:20 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5DGXxcn007380 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Jun 2016 16:34:19 GMT Received: by mail-vk0-x233.google.com with SMTP id u64so74794918vkf.3 for ; Mon, 13 Jun 2016 09:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coactus-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1xG7OtTZNm6Qf1IKerE/XzTBs8/KRTd4rPxhA0drsPg=; b=vCWDzqFhzDtY05HdGq5qnzY/MdLUSCv+QVAu0+YkSWUjc7TwdCqpo+XhINHOS1V84u +5tiag1e3rHuQJT5OHKdzoQj0GGlAHSlTqAHKoU1847pstqb6R9qTc2UK4HrbDdR/ZB8 NmGFbNLpCL9I1GcLI5D47CO7Wg90JFlFpJXXKPIGxk84R71HNO/6SrWU8lew06z1FHWb ifVahLFb4HOfx2uzCo4XJ2Q8UMPb6a08hv7VHxPvs6T/75uzBdvfiWF3H/9cY5amJhKz b5dNHjzRAM+UFk5TvSuJ7Rw0tQ5GUGH61KI24qVnUr/9Kc3jf3i3slL5Jx9yWjtDoafv 892A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1xG7OtTZNm6Qf1IKerE/XzTBs8/KRTd4rPxhA0drsPg=; b=PzmWBOkVK+zfjmoH0QH/vjxHEh79VRZIcr5BPrej/zTskWbWv2i+A3wCKMA0tmgZEq IEo0ANkkQDfP/5r1KD+x7f3aEVGWySVRJl+rWMuZJ8oSCNjAp7ZtJ5LZ2PtiUjj2zKQr Qwwq+GDI24RLc5wETZZNBe+IDeXWmQy2QJvf/wX/ePcmz0WOxqJv8EAanC6RdcOFyGmB bDJJZTJI59y42YAIMmHGerwxpCLuKK6gaIXSWC3oqPw86+tBkSBb0FCMgUBJCvT6QMUp LSMwohXrXqOrxjuI7R3pp3c/hbDHlTXRkgspyujYnYQ7Eo9jfPukkNMioFE3bEzi/EaP ctAQ== X-Gm-Message-State: ALyK8tJqMQ+wdKA5kjiV+YCRwBmwsRUJ+Xx0XTq+eAJWFH2F6/Ot+a3ErWEH98vdpdLhqKwpkYrxalRtoDAHQg== MIME-Version: 1.0 X-Received: by 10.31.83.130 with SMTP id h124mr4281475vkb.93.1465835639104; Mon, 13 Jun 2016 09:33:59 -0700 (PDT) Sender: mark@coactus.com Received: by 10.159.53.70 with HTTP; Mon, 13 Jun 2016 09:33:58 -0700 (PDT) X-Originating-IP: [199.7.159.62] Received: by 10.159.53.70 with HTTP; Mon, 13 Jun 2016 09:33:58 -0700 (PDT) In-Reply-To: <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> Date: Mon, 13 Jun 2016 12:33:58 -0400 X-Google-Sender-Auth: 2BRyUUrX3LVt5ELCaXzTAa6vn4o Message-ID: From: Mark Baker To: Sean Leonard Content-Type: multipart/alternative; boundary=001a114e60a491846705352b74b0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Mon, 13 Jun 2016 16:34:19 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Nottingham , Andy Bierman , media-types@iana.org Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 16:34:22 -0000 --001a114e60a491846705352b74b0 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 11, 2016 at 1:17 PM, Sean Leonard wrote: >> YANG is not an encoding format. It is a schema language. >> Instance documents conforming to YANG schema are encoded in XML or JSON. > > > That confirms my suspicion. So, these proposed media type(s) should have > +xml, +json, or nothing (as structured syntax suffixes are optional, they > are really intended more as a hint to intermediate decoders such as > debugging tools). They should not have +yang. Yah, having just spent some quality time with RFC 6090 over the weekend, I concur. And to answer mnot's question, yep, the period needs to go. --001a114e60a491846705352b74b0 Content-Type: text/html; charset=UTF-8

On Sat, Jun 11, 2016 at 1:17 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>> YANG is not an encoding format. It is a schema language.
>> Instance documents conforming to YANG schema are encoded in XML or JSON.
>
>
> That confirms my suspicion. So, these proposed media type(s) should have
> +xml, +json, or nothing (as structured syntax suffixes are optional, they
> are really intended more as a hint to intermediate decoders such as
> debugging tools). They should not have +yang.

Yah, having just spent some quality time with RFC 6090 over the weekend, I concur.

And to answer mnot's question, yep, the period needs to go.

--001a114e60a491846705352b74b0-- From nobody Mon Jun 13 19:34:58 2016 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 A5F8212D59B for ; Mon, 13 Jun 2016 19:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x3AxwakHxzP for ; Mon, 13 Jun 2016 19:34:55 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776AC12D0DA for ; Mon, 13 Jun 2016 19:34:55 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5E2YYed030526 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 14 Jun 2016 02:34:55 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 65BF750A73; Mon, 13 Jun 2016 22:34:33 -0400 (EDT) To: Mark Baker References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> From: Sean Leonard Message-ID: Date: Mon, 13 Jun 2016 19:35:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------849B9F76E692DAEF67618B55" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Tue, 14 Jun 2016 02:34:55 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Nottingham , Andy Bierman , media-types@iana.org Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 02:34:57 -0000 This is a multi-part message in MIME format. --------------849B9F76E692DAEF67618B55 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/13/2016 9:33 AM, Mark Baker wrote: > > On Sat, Jun 11, 2016 at 1:17 PM, Sean Leonard > wrote: > >> YANG is not an encoding format. It is a schema language. > >> Instance documents conforming to YANG schema are encoded in XML or > JSON. > > > > > > That confirms my suspicion. So, these proposed media type(s) should have > > +xml, +json, or nothing (as structured syntax suffixes are optional, > they > > are really intended more as a hint to intermediate decoders such as > > debugging tools). They should not have +yang. > > Yah, having just spent some quality time with RFC 6090 over the > weekend, I concur. > You mean this RFC 6090? Fundamental Elliptic Curve Cryptography Algorithms Not sure if that is the right RFC for the topic... Sean > > And to answer mnot's question, yep, the period needs to go. > --------------849B9F76E692DAEF67618B55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/13/2016 9:33 AM, Mark Baker wrote:

On Sat, Jun 11, 2016 at 1:17 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>> YANG is not an encoding format. It is a schema language.
>> Instance documents conforming to YANG schema are encoded in XML or JSON.
>
>
> That confirms my suspicion. So, these proposed media type(s) should have
> +xml, +json, or nothing (as structured syntax suffixes are optional, they
> are really intended more as a hint to intermediate decoders such as
> debugging tools). They should not have +yang.

Yah, having just spent some quality time with RFC 6090 over the weekend, I concur.

You mean this RFC 6090?

Fundamental Elliptic Curve Cryptography Algorithms


Not sure if that is the right RFC for the topic...

Sean

And to answer mnot's question, yep, the period needs to go.


--------------849B9F76E692DAEF67618B55-- From nobody Mon Jun 13 20:51:26 2016 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 8024212D777 for ; Mon, 13 Jun 2016 20:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coactus-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytUys7XAlDzc for ; Mon, 13 Jun 2016 20:51:24 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EEA712D771 for ; Mon, 13 Jun 2016 20:51:24 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5E3p3uk015798 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jun 2016 03:51:24 GMT Received: by mail-vk0-x22b.google.com with SMTP id t129so77279320vka.1 for ; Mon, 13 Jun 2016 20:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coactus-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JfL1vpiTNlOYYOe0pES4vOoADfV5q00lFkT5KUEgpPU=; b=CNhjzeYL9/NKUiHcefH0tYs4kS4FH4vz9j3aXReiAI18rPwjEMvHmxafy6UfOx1HTB X93Y4u7IQ5cuvj+OrlbzoxvIDFXSui+sbWmddiWVWqsWu4ymkRJmmJ3UXTTHRV4oOKrs mOI5OZtZKLnherji4RJQpOmLhAu/dQLYgBMgu1ic/Rw0D2MvIWTlMa/y9RwnkD5q76Zn hLIfTb0bu5QwoX7aIiFh1SRqwFVLu3iTEBbDZGS1WQ6HOvyn1DJYAhRqUBDkeJlAuVnC 9qIjLL+rLolHa0a31dhGXGfBczmBQqcYloCDhSwsEFHQtsAYjF8k668ONW7eubTnb0lu /6yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JfL1vpiTNlOYYOe0pES4vOoADfV5q00lFkT5KUEgpPU=; b=W20JOoVAnFeakqZysrHMvNtfxB13MQlzbvu/S9hnI3E5aqo1+wv396tJFX/A9+rpXr k/fHOC5FdeGP5feESQ2/82JNxFjR8F4B4CspCG3GxU6PhOWvfX6qE/GWmH9uLpK7hQ3M I1bdTIqESUaHic6cs7MM0C/JJTr618gPJYqGf3pI8jLKBJWhv5bs0DKepDrkexUhIZU5 mQBDIltF9YmXNeFjq4a0gWye6Qi/yCy+onH0X9Knph44wn5wRAZoOJ0fJYMvc5Gxid+A ljHXh94ECEBbIhvgVDdIZNM7UfZ7/+q2Alw/POH3fPjhAEtolvaNjlQJrA4gpEvNU54D i81A== X-Gm-Message-State: ALyK8tKG6KQ2CiTBaUDWtFkf96zR9x+G9OIAA+EkK9ycfp/WKs3tBwg0J+Xg4gZd6RPz3NUMgBKUH3PdgAt76g== X-Received: by 10.31.142.202 with SMTP id q193mr8083151vkd.37.1465876263135; Mon, 13 Jun 2016 20:51:03 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.159.53.70 with HTTP; Mon, 13 Jun 2016 20:51:02 -0700 (PDT) X-Originating-IP: [23.233.58.109] In-Reply-To: References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <93c917a1-f67e-a44e-31b3-2e95d4b45f4e@seantek.com> <4e3dc596-d61c-a9b8-0b41-e0b4d159596f@seantek.com> From: Mark Baker Date: Mon, 13 Jun 2016 23:51:02 -0400 X-Google-Sender-Auth: bpuGIb5t9HcwX9IXZs7yzX4ysU8 Message-ID: To: Sean Leonard Content-Type: text/plain; charset=UTF-8 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [IPv6:2620:0:2d0:201::1:73]); Tue, 14 Jun 2016 03:51:24 +0000 (UTC) Archived-At: Cc: Benoit Claise , Mark Nottingham , Andy Bierman , media-types@iana.org Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 03:51:25 -0000 > You mean this RFC 6090? Obviously not. I meant 6020. From nobody Tue Jun 14 10:27:04 2016 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 37E8C12D878 for ; Tue, 14 Jun 2016 10:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZcD3a1mD4qt for ; Tue, 14 Jun 2016 10:27:00 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2012D12D875 for ; Tue, 14 Jun 2016 10:27:00 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5EHQdGi026063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jun 2016 17:26:59 GMT Received: by mail-qg0-x232.google.com with SMTP id l44so87935397qgd.0 for ; Tue, 14 Jun 2016 10:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oWVhCwNv2q9Ht/Mm32Od+j2MussSOiljsLUf2hxbm1I=; b=E+NWCCvcOmjGaeC82FTSqpRV7pjhRKi4QOecNcjCD/k8IbrnW6QRGhYjSNpyuGPWZH XGvOHMEOQdWyomEqYKWgVmmYXw85UGd4kfAXRreRLJKNetVWrdPwsg6rIlmvkbqfw/8E CDVQqMlwmpggauMTzyMp5uN4WYoZq5yDNCUD7hUq+xlL0wBXuWXyHT9byKINpaT/km4E jmE45TK+RRfw7cn3il4SX6p2qYoSPiUt5boSraLH2wtkNlRhnAvoiIu5xhybBTS/t78S haFLPpI6tcFULAttHsn5sq8/oLByB34s99weNAmP9zjgG/MRmkhF1+7fBi5jxZdBB2v2 OPnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oWVhCwNv2q9Ht/Mm32Od+j2MussSOiljsLUf2hxbm1I=; b=NUkZvBJCh4DQW+y37uke/JHj9ogGGjx6Ob9xbWjgSKAW1PTSMP5bZw/tXPBx6s1FT8 2V7r6hkYb38q/Bt3R2DO5Be/t+teoICAVDEpT63v33ASOvEnNAp8ITS4TWTAO6apUefr t8w+S3IlDOS4lvX/7OK0G5UpllzPexW4GXGRpWoxeK3NSSWU8tg+SMyzIhF0qaMVD+lu +JC9V6Am2JyR9Ma2L7pc0tqnL5KgQVB6GA+Pl/FXy5NO61eZndtPs8Ek9EMrbuMOQrWa y+MBAm7c3YNEeKQLvN/tjyICFetpt3pbyN+hGNh8hGq+NHRHKfWE2uXRQ/JX9x9TqQWw RSNw== X-Gm-Message-State: ALyK8tKKlOPi1OQGkN67/YkFQiY0bHaw4eAWbovNdjdKCsV8sLXtpgnSLkdoxqPwi5yUcRCh264hJmSmwbtYfw== MIME-Version: 1.0 X-Received: by 10.140.105.162 with SMTP id c31mr10482275qgf.100.1465925199008; Tue, 14 Jun 2016 10:26:39 -0700 (PDT) Received: by 10.200.56.16 with HTTP; Tue, 14 Jun 2016 10:26:38 -0700 (PDT) In-Reply-To: References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> Date: Tue, 14 Jun 2016 10:26:38 -0700 Message-ID: From: Andy Bierman To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113a980ec130a40535404edf X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Tue, 14 Jun 2016 17:26:59 +0000 (UTC) Archived-At: Cc: Benoit Claise , Martin Bjorklund , Kent Watsen , "media-types@iana.org" , Sean Leonard Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 17:27:02 -0000 --001a113a980ec130a40535404edf Content-Type: text/plain; charset=UTF-8 On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham wrote: > > > On 10 Jun 2016, at 12:15 PM, Sean Leonard wrote: > > > > When it comes to Internet media types, "subtype" refers to everything > after the "/" and "type" refers to everything prior to the "/". > > > > The field "Subtype name" is a field in the media type registration > template--its usage in those drafts is correct. > > Even: > > """ > The parent MIME media type for RESTCONF resources is application/yang, > which is defined in [RFC6020]. This document defines the following > sub-types for this media type. > """ > > ? That seems to read as if "application/foo.bar" is a subtype of > "application/foo". > > I can see from RFC 6838, 4.2 that we named all of our media types incorrectly. The media type application/yang just refers to UTF-8 text that represents a YANG module or submodule. It is expected to conform to the YANG syntax. https://tools.ietf.org/html/rfc6020#section-14.1 We are incorrectly using this as a tree root for adding subtypes. We want to create media types that conform to a particular YANG schema. We defined a YANG extension hack to define YANG data structures for a media type https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-8 (see restconf-media-type) Our IANA section for Media Sub Types is wrong https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 It appears we have to make a Media Type registration similar to RFC 6020 14.1 for each of (what we call) the sub-types. application/yang-api application/yang-data application/yang-datastore application/yang-errors application/yang-operation application/yang-stream application/yang-patch application/yang-patch-status Andy > > > > When referring to the construct as a whole, the term "media type" is > generally used, not "media subtype" or "subtype". However, I suppose that > "subtype" would be technically correct (although not preferred) because > application/xml (for example) is actually a subtype of application. > Stylistically it should be called the media type application/xml, etc. > > > > They should be called application/yang-api, application/yang-patch, > application/yang-patch-status, etc. > > > > I am assuming that YANG is referring specifically to the language (akin > to saying "C++" or "JavaScript"), and not referring specifically to the > structured syntax (akin to saying "JSON"). If YANG is referring > specifically to a structured syntax, then the media types should end in > +yang. My knowledge of YANG is not deep enough to opine further on this > point. > > > > Regards, > > > > Sean > > > > On 6/9/2016 4:45 PM, Mark Nottingham wrote: > >> YANG is attempting to register a number of media types that begin with > "application/yang."; see: > >> > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 > >> > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 > >> > >> E.g., it calls "application/yang.api" a "subtype" of "application/yang". > >> > >> I read RFC6838 to prohibit this, because the portion of a subtype > preceded by the first "." indicates the registration tree in a facet, and > faceted media types are prohibited from being registered in the standards > tree (unless they're grandfathered in in Appendix A). Furthermore, the > drafts' use of "subtype" is erroneous. > >> > >> Is that understanding correct? If so, should they be using different > media types, or is there some other way to accommodate what they want? > >> > >> Cheers, > >> > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > >> _______________________________________________ > >> media-types mailing list > >> media-types@ietf.org > >> https://www.ietf.org/mailman/listinfo/media-types > > > > > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > -- > Mark Nottingham https://www.mnot.net/ > > --001a113a980ec130a40535404edf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <<= a href=3D"mailto:mnot@mnot.net" target=3D"_blank">mnot@mnot.net> wrote:

> On 10 Jun 2016, at 12:15 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>
> When it comes to Internet media types, "subtype" refers to e= verything after the "/" and "type" refers to everything= prior to the "/".
>
> The field "Subtype name" is a field in the media type regist= ration template--its usage in those drafts is correct.

Even:

"""
The parent MIME media type for RESTCONF resources is application/yang, whic= h is defined in [RFC6020].=C2=A0 This document defines the following sub-ty= pes for this media type.
"""

? That seems to read as if "application/foo.bar" is a subtype of = "application/foo".



I can see from RFC 6838= , 4.2 that we named all of our media types incorrectly.

The media type application/yang just refers to UTF-8 text that repres= ents a YANG
module or submodule. It is expected to conform to the= YANG syntax.



(see restconf-media-type)

Our IANA s= ection for Media Sub Types is wrong

https= ://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3
<= /div>

It appears we have to make a Media Type registrati= on similar to RFC 6020 14.1
for each of (what we call) the sub-ty= pes.

=C2=A0 =C2=A0 =C2=A0application/yang-api
=C2=A0 =C2=A0 =C2=A0application/yang-data
=C2=A0 =C2=A0 =C2= =A0application/yang-datastore
=C2=A0 =C2=A0 =C2=A0application= /yang-errors
=C2=A0 =C2=A0 =C2=A0application/yang-operation
=
=C2=A0 =C2=A0 =C2=A0application/yang-stream

= =C2=A0 =C2=A0 =C2=A0application/yang-patch
=C2=A0 =C2=A0 =C2=A0ap= plication/yang-patch-status


Andy



>
> When referring to the construct as a whole, the term "media type&= quot; is generally used, not "media subtype" or "subtype&quo= t;. However, I suppose that "subtype" would be technically correc= t (although not preferred) because application/xml (for example) is actuall= y a subtype of application. Stylistically it should be called the media typ= e application/xml, etc.
>
> They should be called application/yang-api, application/yang-patch, ap= plication/yang-patch-status, etc.
>
> I am assuming that YANG is referring specifically to the language (aki= n to saying "C++" or "JavaScript"), and not referring s= pecifically to the structured syntax (akin to saying "JSON"). If = YANG is referring specifically to a structured syntax, then the media types= should end in +yang. My knowledge of YANG is not deep enough to opine furt= her on this point.
>
> Regards,
>
> Sean
>
> On 6/9/2016 4:45 PM, Mark Nottingham wrote:
>> YANG is attempting to register a number of media types that begin = with "application/yang."; see:
>>=C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2
>>=C2=A0 =C2=A0https://= tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3
>>
>> E.g., it calls "application/yang.api" a "subtype&qu= ot; of "application/yang".
>>
>> I read RFC6838 to prohibit this, because the portion of a subtype = preceded by the first "." indicates the registration tree in a fa= cet, and faceted media types are prohibited from being registered in the st= andards tree (unless they're grandfathered in in Appendix A). Furthermo= re, the drafts' use of "subtype" is erroneous.
>>
>> Is that understanding correct? If so, should they be using differe= nt media types, or is there some other way to accommodate what they want? >>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/med= ia-types
>
>
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-ty= pes

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


--001a113a980ec130a40535404edf-- From nobody Thu Jun 16 07:37:50 2016 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 A473912B02A for ; Thu, 16 Jun 2016 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFKdvChr77OQ for ; Thu, 16 Jun 2016 07:37:47 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9496A12D1A1 for ; Thu, 16 Jun 2016 07:37:47 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5GEbQet015201 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 16 Jun 2016 14:37:47 GMT Received: from 30-9-162.wireless.csail.mit.edu ([128.30.9.162]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bDY5U-0002D4-0b; Thu, 16 Jun 2016 14:16:04 +0000 To: media-types@iana.org From: Philippe Le Hegaret Message-ID: <5762B4A3.8080408@w3.org> Date: Thu, 16 Jun 2016 10:16:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:21:20 by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Thu, 16 Jun 2016 14:37:47 +0000 (UTC) Archived-At: Cc: Timed Text Working Group , 'Michael Dolan' Subject: [media-types] Update to media type "application/ttml+xml" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 14:37:49 -0000 The W3C Timed Text Working Group would like to update the media type "application/ttml+xml" as follows. Comments are welcome. It updates the media type, "application/ttml+xml" to add a new parameter, codecs. All other provisions of the media type specification remain the same. This supercedes the initial registration information in TTML 1.0 Second Edition. Text copied below but see also the original text at: https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype [[ Type name: application Subtype name: ttml+xml Required parameters: None. Optional parameters: charset If specified, the charset parameter must match the XML encoding declaration, or if absent, the actual encoding. See also Encoding Considerations below. profile The document profile of a TTMLDocument Instance may be specified using an optional profile parameter, which, if specified, the value of which must adhere to the syntax and semantics of ttp:profile parameter defined by TTML 1.0 Second Edition, Section 6.2.8 ttp:profile of the published specification. codecs The optional codecs parameter provides a short form version of the profile parameter with multiple-profile combinatorial capability. If a short (4-character) form of a profile is registered in the TTML Profile Registry, it is recommended that this codecs parameter be used and not the profile parameter. The nominal value of this parameter is a single 4 character code from the registry. Additionally, applications using the entries in the registry are encouraged to adopt the following combination syntax: Employ two combination operators, '+' (AND) and '|' (OR), which may be used to specify, respectively, that multiple processor profiles apply (simultaneously) or that any processor profile of a list of profiles may apply individually. If both operators are used in a codecs value, then the '+' operator has precedence. The example: "A+B|C+D|E" states that a TTML processor that implements any one of A+B or C+D or E processor profiles satisfies, at first order, the requirements to fetch and begin decode/processing of a TTML document, where X+Y means that both X and Y processor profiles must be supported, and X|Y means that either X or Y processor profile must be supported. For more information about processor profile combination, see TTML2 Profile Combination. Encoding considerations: Same for application/xml, except constrained to either UTF-8 or UTF-16. See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose of filling out the IANA Application for Media Type (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies. Security considerations: As with other XML types and as noted in IETF RFC 3023, XML Media Types, Section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail. In addition, because of the extensibility features for TTML and of XML in general, it is possible that "application/ttml+xml" may describe content that has security implications beyond those described here. However, TTML does not provide for any sort of active or executable content, and if the processor follows only the normative semantics of the published specification, this content will be outside TTML namespaces and may be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Although not prohibited, there are no expectations that XML signatures or encryption would normally be employed. Interoperability considerations: The published specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in TTML namespaces and in other namespaces. Because TTML is extensible, conformant "application/ttml+xml" processors may expect (and enforce) that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. Published specification: This media type registration is extracted from the TTML Profile Registry. Applications that use this media type: TTML is used in the television industry for the purpose of authoring, transcoding and exchanging timed text information and for delivering captions, subtitles, and other metadata for television material repurposed for the Web or, more generally, the Internet. There is partial and full support of TTML in components used by several Web browsers plugins, and in a number of caption authoring tools. Additional information: Magic number(s): File extension(s): .ttml Macintosh file type code(s): "TTML" Fragment identifiers: For documents labeled as application/ttml+xml, the fragment identifier notation is intended to be used with xml:id attributes, as described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) specification. Person & email address to contact for further information: Timed Text Working Group (public-tt@w3.org) Intended usage: COMMON Restrictions on usage: None Author: The published specification is a work product of the World Wide Web Consortium's Timed Text (TT) Working Group. Change controller: The W3C has change control over this specification. ]] https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype Thank you, Philippe From nobody Thu Jun 16 13:08:02 2016 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 7077512D73F for ; Thu, 16 Jun 2016 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajroxMy_oLcD for ; Thu, 16 Jun 2016 13:07:58 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92EE12DB1A for ; Thu, 16 Jun 2016 13:07:57 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5GK7Zue007340 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 16 Jun 2016 20:07:57 GMT Received: from aclermont-ferrand-654-1-533-1.w90-4.abo.wanadoo.fr ([90.4.249.1] helo=w3.org) by raoul.w3.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bDdZd-000Gcg-I1; Thu, 16 Jun 2016 20:07:33 +0000 Date: Thu, 16 Jun 2016 16:07:26 -0400 From: "Eric Prud'hommeaux" To: "'Michael Dolan'" Message-ID: <20160616200724.GC23703@w3.org> References: <5762B4A3.8080408@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5762B4A3.8080408@w3.org> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [IPv6:2620:0:2d0:201::1:71]); Thu, 16 Jun 2016 20:07:57 +0000 (UTC) Archived-At: Cc: Philippe Le Hegaret , Timed Text Working Group , media-types@iana.org Subject: Re: [media-types] Update to media type "application/ttml+xml" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 20:08:00 -0000 * Philippe Le Hegaret [2016-06-16 10:16-0400] > The W3C Timed Text Working Group would like to update the media type > "application/ttml+xml" as follows. Comments are welcome. > > It updates the media type, "application/ttml+xml" to add a new parameter, > codecs. All other provisions of the media type specification remain the > same. This supercedes the initial registration information in TTML 1.0 > Second Edition. > > Text copied below but see also the original text at: > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype > > [[ > > Type name: > > application > Subtype name: > > ttml+xml > Required parameters: > > None. > Optional parameters: > > charset > > If specified, the charset parameter must match the XML encoding > declaration, or if absent, the actual encoding. See also Encoding > Considerations below. > profile > > The document profile of a TTMLDocument Instance may be specified > using an optional profile parameter, which, if specified, the value of which > must adhere to the syntax and semantics of ttp:profile parameter defined by > TTML 1.0 Second Edition, Section 6.2.8 ttp:profile of the published > specification. > > codecs > > The optional codecs parameter provides a short form version of the > profile parameter with multiple-profile combinatorial capability. If a short > (4-character) form of a profile is registered in the TTML Profile Registry, > it is recommended that this codecs parameter be used and not the profile > parameter. The nominal value of this parameter is a single 4 character code > from the registry. > > Additionally, applications using the entries in the registry are > encouraged to adopt the following combination syntax: > > Employ two combination operators, '+' (AND) and '|' (OR), which may > be used to specify, respectively, that multiple processor profiles apply > (simultaneously) or that any processor profile of a list of profiles may > apply individually. If both operators are used in a codecs value, then the > '+' operator has precedence. > > The example: "A+B|C+D|E" states that a TTML processor that > implements any one of A+B or C+D or E processor profiles satisfies, at first > order, the requirements to fetch and begin decode/processing of a TTML PLH indicated that "at first order" is something like an initial claim about the embedded codecs. Is it the intention that there be some sort of recovery if that initial claim is incorrect? What should the processor do if the advertised codec is ogg and the actual codec is xvid? If you strike "at first order", I think you could avoid having to define the behavior in the event of invalid parameters. > document, where X+Y means that both X and Y processor profiles must be > supported, and X|Y means that either X or Y processor profile must be > supported. > > For more information about processor profile combination, see TTML2 > Profile Combination. "TTML2 Profile Comination" has no URL in the reg. The hyptertext version links to https://www.w3.org/TR/ttml2/#profile-attribute-processorProfileCombination propose instead link to https://www.w3.org/TR/ttml2/#processor-profile-combination-table and embedding that link in ()s in the text. > Encoding considerations: > > Same for application/xml, except constrained to either UTF-8 or UTF-16. > See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose of filling > out the IANA Application for Media Type > (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies. > Security considerations: > > As with other XML types and as noted in IETF RFC 3023, XML Media Types, > Section 10, repeated expansion of maliciously constructed XML entities can > be used to consume large amounts of memory, which may cause XML processors > in constrained environments to fail. > > In addition, because of the extensibility features for TTML and of XML > in general, it is possible that "application/ttml+xml" may describe content > that has security implications beyond those described here. However, TTML > does not provide for any sort of active or executable content, and if the > processor follows only the normative semantics of the published > specification, this content will be outside TTML namespaces and may be > ignored. Only in the case where the processor recognizes and processes the > additional content, or where further processing of that content is > dispatched to other processors, would security issues potentially arise. And > in that case, they would fall outside the domain of this registration > document. > > Although not prohibited, there are no expectations that XML signatures > or encryption would normally be employed. > Interoperability considerations: > > The published specification describes processing semantics that dictate > behavior that must be followed when dealing with, among other things, > unrecognized elements and attributes, both in TTML namespaces and in other > namespaces. > > Because TTML is extensible, conformant "application/ttml+xml" processors > may expect (and enforce) that content received is well-formed XML, but it > cannot be guaranteed that the content is valid to a particular DTD or Schema > or that the processor will recognize all of the elements and attributes in > the document. > Published specification: > > This media type registration is extracted from the TTML Profile > Registry. > Applications that use this media type: > > TTML is used in the television industry for the purpose of authoring, > transcoding and exchanging timed text information and for delivering > captions, subtitles, and other metadata for television material repurposed > for the Web or, more generally, the Internet. > > There is partial and full support of TTML in components used by several > Web browsers plugins, and in a number of caption authoring tools. > Additional information: > > Magic number(s): > File extension(s): > > .ttml > Macintosh file type code(s): > > "TTML" > Fragment identifiers: > > For documents labeled as application/ttml+xml, the fragment > identifier notation is intended to be used with xml:id attributes, as > described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) > specification. > > Person & email address to contact for further information: > > Timed Text Working Group (public-tt@w3.org) > Intended usage: > > COMMON > Restrictions on usage: > > None > Author: > > The published specification is a work product of the World Wide Web > Consortium's Timed Text (TT) Working Group. > Change controller: > > The W3C has change control over this specification. > ]] > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype > > Thank you, > > Philippe > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper. From nobody Fri Jun 17 00:54:10 2016 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 D941D12D1B9 for ; Fri, 17 Jun 2016 00:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hawI9h8EAe5z for ; Fri, 17 Jun 2016 00:54:08 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF39412B053 for ; Fri, 17 Jun 2016 00:54:07 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5H7rjH9008101 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 07:54:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15277; q=dns/txt; s=iport; t=1466150047; x=1467359647; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ncL8i+yJp/gUK0JRlnAouDqnOk0qO0I1lPY0lMk86V8=; b=hiAuEgxnIIbfB2saqph9M+v5oK5V7mMwIBZlN1XxIBTWDAAoBPIATLQk zcmmBK7EaDozgYIxSON8oZM6JyMsOgf7dh8XItp7G2kpLFPB+jN2T4MqF mD92Eu1j65gCPzzHxVLAAbrmKaOvBvfkZVXJ1tMOyo2b/sbvZk8AbQy4n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAwD6p2NX/xbLJq1dhBQrUrVehQGBe?= =?us-ascii?q?hcBDIVzAoFjFAEBAQEBAQFlJ4RLAQEBAwEBAQEgSwsFCwsYJwMCAicfEQYBDAY?= =?us-ascii?q?CAQEQiBQIDq99kFYBAQEBAQEBAQEBAQEBAQEBAQEBAQEchieBd4JWhBIRAYMdg?= =?us-ascii?q?loFjXSKfYYFiCSBaYdcI4U6j3UeNoNyOjIBiEWBNQEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,482,1459814400"; d="scan'208,217";a="677775175" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 07:36:04 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5H7a4OX021906; Fri, 17 Jun 2016 07:36:04 GMT To: Andy Bierman , Mark Nottingham References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> From: Benoit Claise Message-ID: <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> Date: Fri, 17 Jun 2016 09:36:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FFE1ED0A42C723664665FD3B" X-Greylist: Delayed for 00:17:36 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 17 Jun 2016 07:54:07 +0000 (UTC) Archived-At: Cc: "netconf-chairs@tools.ietf.org" , Martin Bjorklund , Kent Watsen , "media-types@iana.org" , Sean Leonard Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 07:54:10 -0000 This is a multi-part message in MIME format. --------------FFE1ED0A42C723664665FD3B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm not sure what the conclusion is regarding this email thread? Also, it should be time to include the NETCONF community on this topic. Why not an email thread with both netconf and media-types? Regards, B. > > > On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham > wrote: > > > > On 10 Jun 2016, at 12:15 PM, Sean Leonard > wrote: > > > > When it comes to Internet media types, "subtype" refers to > everything after the "/" and "type" refers to everything prior to > the "/". > > > > The field "Subtype name" is a field in the media type > registration template--its usage in those drafts is correct. > > Even: > > """ > The parent MIME media type for RESTCONF resources is > application/yang, which is defined in [RFC6020]. This document > defines the following sub-types for this media type. > """ > > ? That seems to read as if "application/foo.bar" is a subtype of > "application/foo". > > > > I can see from RFC 6838, 4.2 that we named all of our media types > incorrectly. > > The media type application/yang just refers to UTF-8 text that > represents a YANG > module or submodule. It is expected to conform to the YANG syntax. > > https://tools.ietf.org/html/rfc6020#section-14.1 > > We are incorrectly using this as a tree root for adding subtypes. > > We want to create media types that conform to a particular YANG schema. > We defined a YANG extension hack to define YANG data structures for a > media type > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-8 > (see restconf-media-type) > > Our IANA section for Media Sub Types is wrong > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 > > It appears we have to make a Media Type registration similar to RFC > 6020 14.1 > for each of (what we call) the sub-types. > > application/yang-api > application/yang-data > application/yang-datastore > application/yang-errors > application/yang-operation > application/yang-stream > > application/yang-patch > application/yang-patch-status > > > Andy > > > > > > > When referring to the construct as a whole, the term "media > type" is generally used, not "media subtype" or "subtype". > However, I suppose that "subtype" would be technically correct > (although not preferred) because application/xml (for example) is > actually a subtype of application. Stylistically it should be > called the media type application/xml, etc. > > > > They should be called application/yang-api, > application/yang-patch, application/yang-patch-status, etc. > > > > I am assuming that YANG is referring specifically to the > language (akin to saying "C++" or "JavaScript"), and not referring > specifically to the structured syntax (akin to saying "JSON"). If > YANG is referring specifically to a structured syntax, then the > media types should end in +yang. My knowledge of YANG is not deep > enough to opine further on this point. > > > > Regards, > > > > Sean > > > > On 6/9/2016 4:45 PM, Mark Nottingham wrote: > >> YANG is attempting to register a number of media types that > begin with "application/yang."; see: > >> > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 > >> > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 > >> > >> E.g., it calls "application/yang.api" a "subtype" of > "application/yang". > >> > >> I read RFC6838 to prohibit this, because the portion of a > subtype preceded by the first "." indicates the registration tree > in a facet, and faceted media types are prohibited from being > registered in the standards tree (unless they're grandfathered in > in Appendix A). Furthermore, the drafts' use of "subtype" is > erroneous. > >> > >> Is that understanding correct? If so, should they be using > different media types, or is there some other way to accommodate > what they want? > >> > >> Cheers, > >> > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > >> _______________________________________________ > >> media-types mailing list > >> media-types@ietf.org > >> https://www.ietf.org/mailman/listinfo/media-types > > > > > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > -- > Mark Nottingham https://www.mnot.net/ > > --------------FFE1ED0A42C723664665FD3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm not sure what the conclusion is regarding this email thread?
Also, it should be time to include the NETCONF community on this topic.
Why not an email thread with both netconf and media-types?

Regards, B.


On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 10 Jun 2016, at 12:15 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>
> When it comes to Internet media types, "subtype" refers to everything after the "/" and "type" refers to everything prior to the "/".
>
> The field "Subtype name" is a field in the media type registration template--its usage in those drafts is correct.

Even:

"""
The parent MIME media type for RESTCONF resources is application/yang, which is defined in [RFC6020].  This document defines the following sub-types for this media type.
"""

? That seems to read as if "application/foo.bar" is a subtype of "application/foo".



I can see from RFC 6838, 4.2 that we named all of our media types incorrectly.

The media type application/yang just refers to UTF-8 text that represents a YANG
module or submodule. It is expected to conform to the YANG syntax.


We are incorrectly using this as a tree root for adding subtypes.

We want to create media types that conform to a particular YANG schema.
We defined a YANG extension hack to define YANG data structures for a media type
(see restconf-media-type)

Our IANA section for Media Sub Types is wrong


It appears we have to make a Media Type registration similar to RFC 6020 14.1
for each of (what we call) the sub-types.

     application/yang-api
     application/yang-data
     application/yang-datastore
     application/yang-errors
     application/yang-operation
     application/yang-stream

     application/yang-patch
     application/yang-patch-status


Andy



>
> When referring to the construct as a whole, the term "media type" is generally used, not "media subtype" or "subtype". However, I suppose that "subtype" would be technically correct (although not preferred) because application/xml (for example) is actually a subtype of application. Stylistically it should be called the media type application/xml, etc.
>
> They should be called application/yang-api, application/yang-patch, application/yang-patch-status, etc.
>
> I am assuming that YANG is referring specifically to the language (akin to saying "C++" or "JavaScript"), and not referring specifically to the structured syntax (akin to saying "JSON"). If YANG is referring specifically to a structured syntax, then the media types should end in +yang. My knowledge of YANG is not deep enough to opine further on this point.
>
> Regards,
>
> Sean
>
> On 6/9/2016 4:45 PM, Mark Nottingham wrote:
>> YANG is attempting to register a number of media types that begin with "application/yang."; see:
>>   https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2
>>   https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3
>>
>> E.g., it calls "application/yang.api" a "subtype" of "application/yang".
>>
>> I read RFC6838 to prohibit this, because the portion of a subtype preceded by the first "." indicates the registration tree in a facet, and faceted media types are prohibited from being registered in the standards tree (unless they're grandfathered in in Appendix A). Furthermore, the drafts' use of "subtype" is erroneous.
>>
>> Is that understanding correct? If so, should they be using different media types, or is there some other way to accommodate what they want?
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/media-types
>
>
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types

--
Mark Nottingham   https://www.mnot.net/



--------------FFE1ED0A42C723664665FD3B-- From nobody Fri Jun 17 04:43:12 2016 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 58E6912D104 for ; Fri, 17 Jun 2016 04:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTX24p-RYi8a for ; Fri, 17 Jun 2016 04:43:08 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D058112B016 for ; Fri, 17 Jun 2016 04:43:06 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5HBgj6x011976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 11:43:06 GMT Received: by mail-vk0-x229.google.com with SMTP id j2so112092389vkg.2 for ; Fri, 17 Jun 2016 04:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4M/vVIdL0rU71CDY9eS3TKVG+otlyIFXvUi7+tN/hGU=; b=N+B0v+ycD06fbu4ZOAGpWXFS+HnvJqjgjEr+WZHJubE31rdMhn2nqUfY0nejK1jxvS yN9LJB3c2lcctwzNMxVESsVsBsB3nrkcX10S6zvttikNB+uvk4vvw+nB6oH3c5EIDruo 25TDX/IFqz6xMKEw4BE7HRY9sBiM5zEnFbPOnogKKCwW7b2Wut1Vf3qGivQvk5fWxHYF xRzeE/AQVsQDHKWCq+zqFNMnTCY4DFDJx/EbS7H8FBJoCms9xBDlDiMtwRd7qwI88rXV nrNMXaPLKzdNu13Mhl5erc/6tjdjXY8On4Ud1FUeGXa8Bi9Ay6g43Y1LuJtnfAGzPNgu M8pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4M/vVIdL0rU71CDY9eS3TKVG+otlyIFXvUi7+tN/hGU=; b=IIXCcWX15guhxkyL0cOtaPgtT6tlc66yztL8ICNdx3UbyuNjiq+ET3eZjxGOBWckE2 gYQ876SySY5j8VBbKWkeJnqEo70hWNVuzv9jkj6rocwim1aZUar68A5aTq36nKmhWX+n 0sV2uMwbsxclODZQC93fCGRojACKuDNTZPJ7k0O4QgMqvtnI6GtU0l+HbmuxiFR8twMY ITcEvhD50hcquOUOXhoJ94AElS5s4nuHj9UtAHhAXQLcNAprinYv5Hj2AnOgaAM+OLyS X1vMBo5JZZXmkCY5/RyHFXcKCrhiseZSY/4ZZvsTwTu92val4llugZZnAWaJZL5ImBRW FKfA== X-Gm-Message-State: ALyK8tKW4aWpczUzJI+7bS4+SJwqmoWC74Xv4WbH6/SKpPwI9fACY+h+CERVVJQn4NK6s7Sak9ePyieOr3YUaw== MIME-Version: 1.0 X-Received: by 10.31.5.80 with SMTP id 77mr909757vkf.132.1466163765590; Fri, 17 Jun 2016 04:42:45 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Fri, 17 Jun 2016 04:42:45 -0700 (PDT) In-Reply-To: <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> Date: Fri, 17 Jun 2016 04:42:45 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1143db926e5935053577dafc X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Fri, 17 Jun 2016 11:43:06 +0000 (UTC) Archived-At: Cc: Martin Bjorklund , Kent Watsen , Mark Nottingham , Sean Leonard , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 11:43:10 -0000 --001a1143db926e5935053577dafc Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise wrote: > I'm not sure what the conclusion is regarding this email thread? > Also, it should be time to include the NETCONF community on this topic. > Why not an email thread with both netconf and media-types? > > I am changing the media type name so that faceted names are not used. yang.foo becomes yang-foo The IANA registration section is being redone to conform to RFC 6838 > Regards, B. > Andy > > > On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham wrote: > >> >> > On 10 Jun 2016, at 12:15 PM, Sean Leonard < >> dev+ietf@seantek.com> wrote: >> > >> > When it comes to Internet media types, "subtype" refers to everything >> after the "/" and "type" refers to everything prior to the "/". >> > >> > The field "Subtype name" is a field in the media type registration >> template--its usage in those drafts is correct. >> >> Even: >> >> """ >> The parent MIME media type for RESTCONF resources is application/yang, >> which is defined in [RFC6020]. This document defines the following >> sub-types for this media type. >> """ >> >> ? That seems to read as if "application/foo.bar" is a subtype of >> "application/foo". >> >> > > I can see from RFC 6838, 4.2 that we named all of our media types > incorrectly. > > The media type application/yang just refers to UTF-8 text that represents > a YANG > module or submodule. It is expected to conform to the YANG syntax. > > https://tools.ietf.org/html/rfc6020#section-14.1 > > We are incorrectly using this as a tree root for adding subtypes. > > We want to create media types that conform to a particular YANG schema. > We defined a YANG extension hack to define YANG data structures for a > media type > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-8 > (see restconf-media-type) > > Our IANA section for Media Sub Types is wrong > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 > > It appears we have to make a Media Type registration similar to RFC 6020 > 14.1 > for each of (what we call) the sub-types. > > application/yang-api > application/yang-data > application/yang-datastore > application/yang-errors > application/yang-operation > application/yang-stream > > application/yang-patch > application/yang-patch-status > > > Andy > > > >> > >> > When referring to the construct as a whole, the term "media type" is >> generally used, not "media subtype" or "subtype". However, I suppose that >> "subtype" would be technically correct (although not preferred) because >> application/xml (for example) is actually a subtype of application. >> Stylistically it should be called the media type application/xml, etc. >> > >> > They should be called application/yang-api, application/yang-patch, >> application/yang-patch-status, etc. >> > >> > I am assuming that YANG is referring specifically to the language (akin >> to saying "C++" or "JavaScript"), and not referring specifically to the >> structured syntax (akin to saying "JSON"). If YANG is referring >> specifically to a structured syntax, then the media types should end in >> +yang. My knowledge of YANG is not deep enough to opine further on this >> point. >> > >> > Regards, >> > >> > Sean >> > >> > On 6/9/2016 4:45 PM, Mark Nottingham wrote: >> >> YANG is attempting to register a number of media types that begin with >> "application/yang."; see: >> >> >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 >> >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 >> >> >> >> E.g., it calls "application/yang.api" a "subtype" of >> "application/yang". >> >> >> >> I read RFC6838 to prohibit this, because the portion of a subtype >> preceded by the first "." indicates the registration tree in a facet, and >> faceted media types are prohibited from being registered in the standards >> tree (unless they're grandfathered in in Appendix A). Furthermore, the >> drafts' use of "subtype" is erroneous. >> >> >> >> Is that understanding correct? If so, should they be using different >> media types, or is there some other way to accommodate what they want? >> >> >> >> Cheers, >> >> >> >> >> >> -- >> >> Mark Nottingham https://www.mnot.net/ >> >> >> >> _______________________________________________ >> >> media-types mailing list >> >> media-types@ietf.org >> >> https://www.ietf.org/mailman/listinfo/media-types >> > >> > >> > >> > _______________________________________________ >> > media-types mailing list >> > media-types@ietf.org >> > https://www.ietf.org/mailman/listinfo/media-types >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > > --001a1143db926e5935053577dafc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise <<= a href=3D"mailto:bclaise@cisco.com" target=3D"_blank">bclaise@cisco.com= > wrote:
=20 =20 =20
I'm not sure what the conclusion is regarding this email thread?
Also, it should be time to include the NETCONF community on this topic.
Why not an email thread with both netconf and media-types?


I am changing the me= dia type name so that faceted names are not used.

= yang.foo becomes yang-foo

The IANA registratio= n section is being redone to conform to RFC 6838

<= br>

=C2=A0
Regards, B.

Andy
=C2=A0
=20


On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 10 Jun 2016, at 12:15 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>
> When it comes to Internet media types, "subtype&quo= t; refers to everything after the "/" and "type&q= uot; refers to everything prior to the "/".
>
> The field "Subtype name" is a field in the med= ia type registration template--its usage in those drafts is correct.

Even:

"""
The parent MIME media type for RESTCONF resources is application/yang, which is defined in [RFC6020].=C2=A0 This document defines the following sub-types for this media type.
"""

? That seems to read as if "application/foo.bar" is= a subtype of "application/foo".



I can see from RFC 6838, 4.2 that we named all of our media types incorrectly.

The media type application/yang just refers to UTF-8 text that represents a YANG
module or submodule. It is expected to conform to the YANG syntax.


We are incorrectly using this as a tree root for adding subtypes.

We want to create media types that conform to a particular YANG schema.
We defined a YANG extension hack to define YANG data structures for a media type
(see restconf-media-type)

Our IANA section for Media Sub Types is wrong


It appears we have to make a Media Type registration similar to RFC 6020 14.1
for each of (what we call) the sub-types.

=C2=A0 =C2=A0 =C2=A0application/yang-api
=C2=A0 =C2=A0 =C2=A0application/yang-data
=C2=A0 =C2=A0 =C2=A0application/yang-datastore
=C2=A0 =C2=A0 =C2=A0application/yang-errors
=C2=A0 =C2=A0 =C2=A0application/yang-operation
=C2=A0 =C2=A0 =C2=A0application/yang-stream

=C2=A0 =C2=A0 =C2=A0application/yang-patch
=C2=A0 =C2=A0 =C2=A0application/yang-patch-status


Andy



>
> When referring to the construct as a whole, the term "media type" is generally used, not "media sub= type" or "subtype". However, I suppose that "subtype&qu= ot; would be technically correct (although not preferred) because application/xml (for example) is actually a subtype of application. Stylistically it should be called the media type application/xml, etc.
>
> They should be called application/yang-api, application/yang-patch, application/yang-patch-status, etc.
>
> I am assuming that YANG is referring specifically to the language (akin to saying "C++" or "JavaScr= ipt"), and not referring specifically to the structured syntax (akin to saying "JSON"). If YANG is referring specificall= y to a structured syntax, then the media types should end in +yang. My knowledge of YANG is not deep enough to opine further on this point.
>
> Regards,
>
> Sean
>
> On 6/9/2016 4:45 PM, Mark Nottingham wrote:
>> YANG is attempting to register a number of media types that begin with "application/yang."; see:
>>=C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section= -4.2
>>=C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11= .3
>>
>> E.g., it calls "application/yang.api" a &q= uot;subtype" of "application/yang".
>>
>> I read RFC6838 to prohibit this, because the portion of a subtype preceded by the first "." indi= cates the registration tree in a facet, and faceted media types are prohibited from being registered in the standards tree (unless they're grandfathered in in Appendix A). Furthermore, the drafts' use of "subtype" is er= roneous.
>>
>> Is that understanding correct? If so, should they be using different media types, or is there some other way to accommodate what they want?
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/ >>
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org
>> https://www.ietf.org/mailman= /listinfo/media-types
>
>
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/media-types

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




--001a1143db926e5935053577dafc-- From nobody Fri Jun 17 05:59:14 2016 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 E543012D579 for ; Fri, 17 Jun 2016 05:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcQuJhQyYFjS for ; Fri, 17 Jun 2016 05:59:11 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06D112D516 for ; Fri, 17 Jun 2016 05:59:10 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5HCwnB2013466 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 17 Jun 2016 12:59:10 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B4CFC50A84; Fri, 17 Jun 2016 08:58:47 -0400 (EDT) To: Andy Bierman , Benoit Claise References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> From: Sean Leonard Message-ID: <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> Date: Fri, 17 Jun 2016 05:59:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A81D13952D0E3825A79FD561" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 17 Jun 2016 12:59:10 +0000 (UTC) Archived-At: Cc: Mark Nottingham , Martin Bjorklund , Kent Watsen , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 12:59:13 -0000 This is a multi-part message in MIME format. --------------A81D13952D0E3825A79FD561 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 6/17/2016 4:42 AM, Andy Bierman wrote: > > > On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise > wrote: > > I'm not sure what the conclusion is regarding this email thread? > Also, it should be time to include the NETCONF community on this > topic. > Why not an email thread with both netconf and media-types? > > > I am changing the media type name so that faceted names are not used. > > yang.foo becomes yang-foo > > The IANA registration section is being redone to conform to RFC 6838 > application/yang.foo -> application/yang-foo corrects the faceted name problem, yes. However, the other point has not been addressed. I do not see a technical reason or justification for registering 8 media types, when application/yang; yangtype="foo" (api, data, datastore, errors, operation, stream, patch, patch-status) suffices. Please address. Best regards, Sean > > > Regards, B. > > > Andy > >> >> >> On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham > > wrote: >> >> >> > On 10 Jun 2016, at 12:15 PM, Sean Leonard >> > wrote: >> > >> > When it comes to Internet media types, "subtype" refers to >> everything after the "/" and "type" refers to everything >> prior to the "/". >> > >> > The field "Subtype name" is a field in the media type >> registration template--its usage in those drafts is correct. >> >> Even: >> >> """ >> The parent MIME media type for RESTCONF resources is >> application/yang, which is defined in [RFC6020]. This >> document defines the following sub-types for this media type. >> """ >> >> ? That seems to read as if "application/foo.bar" is a subtype >> of "application/foo". >> >> >> >> I can see from RFC 6838, 4.2 that we named all of our media types >> incorrectly. >> >> The media type application/yang just refers to UTF-8 text that >> represents a YANG >> module or submodule. It is expected to conform to the YANG syntax. >> >> https://tools.ietf.org/html/rfc6020#section-14.1 >> >> We are incorrectly using this as a tree root for adding subtypes. >> >> We want to create media types that conform to a particular YANG >> schema. >> We defined a YANG extension hack to define YANG data structures >> for a media type >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-8 >> (see restconf-media-type) >> >> Our IANA section for Media Sub Types is wrong >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 >> >> It appears we have to make a Media Type registration similar to >> RFC 6020 14.1 >> for each of (what we call) the sub-types. >> >> application/yang-api >> application/yang-data >> application/yang-datastore >> application/yang-errors >> application/yang-operation >> application/yang-stream >> >> application/yang-patch >> application/yang-patch-status >> >> >> Andy >> >> >> >> > >> > When referring to the construct as a whole, the term "media >> type" is generally used, not "media subtype" or "subtype". >> However, I suppose that "subtype" would be technically >> correct (although not preferred) because application/xml (for >> example) is actually a subtype of application. Stylistically >> it should be called the media type application/xml, etc. >> > >> > They should be called application/yang-api, >> application/yang-patch, application/yang-patch-status, etc. >> > >> > I am assuming that YANG is referring specifically to the >> language (akin to saying "C++" or "JavaScript"), and not >> referring specifically to the structured syntax (akin to >> saying "JSON"). If YANG is referring specifically to a >> structured syntax, then the media types should end in +yang. >> My knowledge of YANG is not deep enough to opine further on >> this point. >> > >> > Regards, >> > >> > Sean >> > >> > On 6/9/2016 4:45 PM, Mark Nottingham wrote: >> >> YANG is attempting to register a number of media types >> that begin with "application/yang."; see: >> >> >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 >> >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 >> >> >> >> E.g., it calls "application/yang.api" a "subtype" of >> "application/yang". >> >> >> >> I read RFC6838 to prohibit this, because the portion of a >> subtype preceded by the first "." indicates the registration >> tree in a facet, and faceted media types are prohibited from >> being registered in the standards tree (unless they're >> grandfathered in in Appendix A). Furthermore, the drafts' use >> of "subtype" is erroneous. >> >> >> >> Is that understanding correct? If so, should they be using >> different media types, or is there some other way to >> accommodate what they want? >> >> >> >> Cheers, >> >> >> >> >> >> -- >> >> Mark Nottingham https://www.mnot.net/ >> >> >> >> _______________________________________________ >> >> media-types mailing list >> >> media-types@ietf.org >> >> https://www.ietf.org/mailman/listinfo/media-types >> > >> > >> > >> > _______________________________________________ >> > media-types mailing list >> > media-types@ietf.org >> > https://www.ietf.org/mailman/listinfo/media-types >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --------------A81D13952D0E3825A79FD561 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 6/17/2016 4:42 AM, Andy Bierman wrote:


On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise <bclaise@cisco.com> wrote:
I'm not sure what the conclusion is regarding this email thread?
Also, it should be time to include the NETCONF community on this topic.
Why not an email thread with both netconf and media-types?


I am changing the media type name so that faceted names are not used.

yang.foo becomes yang-foo

The IANA registration section is being redone to conform to RFC 6838


application/yang.foo -> application/yang-foo

corrects the faceted name problem, yes.

However, the other point has not been addressed. I do not see a technical reason or justification for registering 8 media types, when application/yang; yangtype="foo" (api, data, datastore, errors, operation, stream, patch, patch-status) suffices. Please address.

Best regards,

Sean



 
Regards, B.

Andy
 


On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 10 Jun 2016, at 12:15 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>
> When it comes to Internet media types, "subtype" refers to everything after the "/" and "type" refers to everything prior to the "/".
>
> The field "Subtype name" is a field in the media type registration template--its usage in those drafts is correct.

Even:

"""
The parent MIME media type for RESTCONF resources is application/yang, which is defined in [RFC6020].  This document defines the following sub-types for this media type.
"""

? That seems to read as if "application/foo.bar" is a subtype of "application/foo".



I can see from RFC 6838, 4.2 that we named all of our media types incorrectly.

The media type application/yang just refers to UTF-8 text that represents a YANG
module or submodule. It is expected to conform to the YANG syntax.


We are incorrectly using this as a tree root for adding subtypes.

We want to create media types that conform to a particular YANG schema.
We defined a YANG extension hack to define YANG data structures for a media type
(see restconf-media-type)

Our IANA section for Media Sub Types is wrong


It appears we have to make a Media Type registration similar to RFC 6020 14.1
for each of (what we call) the sub-types.

     application/yang-api
     application/yang-data
     application/yang-datastore
     application/yang-errors
     application/yang-operation
     application/yang-stream

     application/yang-patch
     application/yang-patch-status


Andy



>
> When referring to the construct as a whole, the term "media type" is generally used, not "media subtype" or "subtype". However, I suppose that "subtype" would be technically correct (although not preferred) because application/xml (for example) is actually a subtype of application. Stylistically it should be called the media type application/xml, etc.
>
> They should be called application/yang-api, application/yang-patch, application/yang-patch-status, etc.
>
> I am assuming that YANG is referring specifically to the language (akin to saying "C++" or "JavaScript"), and not referring specifically to the structured syntax (akin to saying "JSON"). If YANG is referring specifically to a structured syntax, then the media types should end in +yang. My knowledge of YANG is not deep enough to opine further on this point.
>
> Regards,
>
> Sean
>
> On 6/9/2016 4:45 PM, Mark Nottingham wrote:
>> YANG is attempting to register a number of media types that begin with "application/yang."; see:
>>   https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2
>>   https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3
>>
>> E.g., it calls "application/yang.api" a "subtype" of "application/yang".
>>
>> I read RFC6838 to prohibit this, because the portion of a subtype preceded by the first "." indicates the registration tree in a facet, and faceted media types are prohibited from being registered in the standards tree (unless they're grandfathered in in Appendix A). Furthermore, the drafts' use of "subtype" is erroneous.
>>
>> Is that understanding correct? If so, should they be using different media types, or is there some other way to accommodate what they want?
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/media-types
>
>
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types

--
Mark Nottingham   https://www.mnot.net/






_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types


--------------A81D13952D0E3825A79FD561-- From nobody Fri Jun 17 07:47:31 2016 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 605D112D62F for ; Fri, 17 Jun 2016 07:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1RSLeac7AZF for ; Fri, 17 Jun 2016 07:47:26 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE26312D5B9 for ; Fri, 17 Jun 2016 07:47:17 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5HEkopc020029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 14:47:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25735; q=dns/txt; s=iport; t=1466174831; x=1467384431; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=lwedb2ltw7SV8t6COb38C9n4mzT83r8aM4qPXL3md4M=; b=JezIxZe8rVvDp/AgGNoPbV3Nc9YlofKtNBzIxOsuvx9uNwlyJ1ankphy ZJV8rn2lx/0YR0/2umt9Aa7NFA5z0hAL4W777tgaMrmBypgwTZ7/aOBnw Co4RvS9mu+xcBwncIlKueRp6iWM9xMhfry12TiZ/xmoGPfLHEQQ6Qt1qi c=; X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208,217";a="677782303" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 14:46:49 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5HEkmmx000920; Fri, 17 Jun 2016 14:46:49 GMT To: Sean Leonard , Andy Bierman References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> From: Benoit Claise Message-ID: <1b4ea4b1-3f74-0ff1-c8e8-2e1f4e4dc8e8@cisco.com> Date: Fri, 17 Jun 2016 16:46:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> Content-Type: multipart/alternative; boundary="------------D379BDED6D65CD09A8085EAB" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Fri, 17 Jun 2016 14:47:11 +0000 (UTC) Archived-At: Cc: Martin Bjorklund , Kent Watsen , art-ads@ietf.org, Mark Nottingham , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 14:47:29 -0000 This is a multi-part message in MIME format. --------------D379BDED6D65CD09A8085EAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 6/17/2016 2:59 PM, Sean Leonard wrote: > On 6/17/2016 4:42 AM, Andy Bierman wrote: >> >> >> On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise > > wrote: >> >> I'm not sure what the conclusion is regarding this email thread? >> Also, it should be time to include the NETCONF community on this >> topic. >> Why not an email thread with both netconf and media-types? >> >> >> I am changing the media type name so that faceted names are not used. >> >> yang.foo becomes yang-foo >> >> The IANA registration section is being redone to conform to RFC 6838 >> > > application/yang.foo -> application/yang-foo > > corrects the faceted name problem, yes. > > However, the other point has not been addressed. I do not see a > technical reason or justification for registering 8 media types, when > application/yang; yangtype="foo" (api, data, datastore, errors, > operation, stream, patch, patch-status) suffices. Please address. Is this a constraint imposed by the media-type designated expert or a preference? Maybe this is mentioned by one of the RFCs at http://www.iana.org/assignments/media-types/media-types.xhtml? Sorry I have not read them all. If a preference, then it should be discussed on the NETCONF mailling list. Regards, Benoit > > Best regards, > > Sean > >> >> >> Regards, B. >> >> >> Andy >> >>> >>> >>> On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham >>> wrote: >>> >>> >>> > On 10 Jun 2016, at 12:15 PM, Sean Leonard >>> > wrote: >>> > >>> > When it comes to Internet media types, "subtype" refers to >>> everything after the "/" and "type" refers to everything >>> prior to the "/". >>> > >>> > The field "Subtype name" is a field in the media type >>> registration template--its usage in those drafts is correct. >>> >>> Even: >>> >>> """ >>> The parent MIME media type for RESTCONF resources is >>> application/yang, which is defined in [RFC6020]. This >>> document defines the following sub-types for this media type. >>> """ >>> >>> ? That seems to read as if "application/foo.bar" is a >>> subtype of "application/foo". >>> >>> >>> >>> I can see from RFC 6838, 4.2 that we named all of our media >>> types incorrectly. >>> >>> The media type application/yang just refers to UTF-8 text that >>> represents a YANG >>> module or submodule. It is expected to conform to the YANG syntax. >>> >>> https://tools.ietf.org/html/rfc6020#section-14.1 >>> >>> We are incorrectly using this as a tree root for adding subtypes. >>> >>> We want to create media types that conform to a particular YANG >>> schema. >>> We defined a YANG extension hack to define YANG data structures >>> for a media type >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-8 >>> (see restconf-media-type) >>> >>> Our IANA section for Media Sub Types is wrong >>> >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 >>> >>> It appears we have to make a Media Type registration similar to >>> RFC 6020 14.1 >>> for each of (what we call) the sub-types. >>> >>> application/yang-api >>> application/yang-data >>> application/yang-datastore >>> application/yang-errors >>> application/yang-operation >>> application/yang-stream >>> >>> application/yang-patch >>> application/yang-patch-status >>> >>> >>> Andy >>> >>> >>> >>> > >>> > When referring to the construct as a whole, the term >>> "media type" is generally used, not "media subtype" or >>> "subtype". However, I suppose that "subtype" would be >>> technically correct (although not preferred) because >>> application/xml (for example) is actually a subtype of >>> application. Stylistically it should be called the media >>> type application/xml, etc. >>> > >>> > They should be called application/yang-api, >>> application/yang-patch, application/yang-patch-status, etc. >>> > >>> > I am assuming that YANG is referring specifically to the >>> language (akin to saying "C++" or "JavaScript"), and not >>> referring specifically to the structured syntax (akin to >>> saying "JSON"). If YANG is referring specifically to a >>> structured syntax, then the media types should end in +yang. >>> My knowledge of YANG is not deep enough to opine further on >>> this point. >>> > >>> > Regards, >>> > >>> > Sean >>> > >>> > On 6/9/2016 4:45 PM, Mark Nottingham wrote: >>> >> YANG is attempting to register a number of media types >>> that begin with "application/yang."; see: >>> >> >>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2 >>> >> >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3 >>> >> >>> >> E.g., it calls "application/yang.api" a "subtype" of >>> "application/yang". >>> >> >>> >> I read RFC6838 to prohibit this, because the portion of a >>> subtype preceded by the first "." indicates the registration >>> tree in a facet, and faceted media types are prohibited from >>> being registered in the standards tree (unless they're >>> grandfathered in in Appendix A). Furthermore, the drafts' >>> use of "subtype" is erroneous. >>> >> >>> >> Is that understanding correct? If so, should they be >>> using different media types, or is there some other way to >>> accommodate what they want? >>> >> >>> >> Cheers, >>> >> >>> >> >>> >> -- >>> >> Mark Nottingham https://www.mnot.net/ >>> >> >>> >> _______________________________________________ >>> >> media-types mailing list >>> >> media-types@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/media-types >>> > >>> > >>> > >>> > _______________________________________________ >>> > media-types mailing list >>> > media-types@ietf.org >>> > https://www.ietf.org/mailman/listinfo/media-types >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> >> >> >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types > > --------------D379BDED6D65CD09A8085EAB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 6/17/2016 2:59 PM, Sean Leonard wrote:
On 6/17/2016 4:42 AM, Andy Bierman wrote:


On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise <bclaise@cisco.com> wrote:
I'm not sure what the conclusion is regarding this email thread?
Also, it should be time to include the NETCONF community on this topic.
Why not an email thread with both netconf and media-types?


I am changing the media type name so that faceted names are not used.

yang.foo becomes yang-foo

The IANA registration section is being redone to conform to RFC 6838


application/yang.foo -> application/yang-foo

corrects the faceted name problem, yes.

However, the other point has not been addressed. I do not see a technical reason or justification for registering 8 media types, when application/yang; yangtype="foo" (api, data, datastore, errors, operation, stream, patch, patch-status) suffices. Please address.
Is this a constraint imposed by the media-type designated expert or a preference?
Maybe this is mentioned by one of the RFCs at http://www.iana.org/assignments/media-types/media-types.xhtml? Sorry I have not read them all.
If a preference, then it should be discussed on the NETCONF mailling list.

Regards, Benoit



Best regards,

Sean



 
Regards, B.

Andy
 


On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 10 Jun 2016, at 12:15 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
>
> When it comes to Internet media types, "subtype" refers to everything after the "/" and "type" refers to everything prior to the "/".
>
> The field "Subtype name" is a field in the media type registration template--its usage in those drafts is correct.

Even:

"""
The parent MIME media type for RESTCONF resources is application/yang, which is defined in [RFC6020].  This document defines the following sub-types for this media type.
"""

? That seems to read as if "application/foo.bar" is a subtype of "application/foo".



I can see from RFC 6838, 4.2 that we named all of our media types incorrectly.

The media type application/yang just refers to UTF-8 text that represents a YANG
module or submodule. It is expected to conform to the YANG syntax.


We are incorrectly using this as a tree root for adding subtypes.

We want to create media types that conform to a particular YANG schema.
We defined a YANG extension hack to define YANG data structures for a media type
(see restconf-media-type)

Our IANA section for Media Sub Types is wrong


It appears we have to make a Media Type registration similar to RFC 6020 14.1
for each of (what we call) the sub-types.

     application/yang-api
     application/yang-data
     application/yang-datastore
     application/yang-errors
     application/yang-operation
     application/yang-stream

     application/yang-patch
     application/yang-patch-status


Andy



>
> When referring to the construct as a whole, the term "media type" is generally used, not "media subtype" or "subtype". However, I suppose that "subtype" would be technically correct (although not preferred) because application/xml (for example) is actually a subtype of application. Stylistically it should be called the media type application/xml, etc.
>
> They should be called application/yang-api, application/yang-patch, application/yang-patch-status, etc.
>
> I am assuming that YANG is referring specifically to the language (akin to saying "C++" or "JavaScript"), and not referring specifically to the structured syntax (akin to saying "JSON"). If YANG is referring specifically to a structured syntax, then the media types should end in +yang. My knowledge of YANG is not deep enough to opine further on this point.
>
> Regards,
>
> Sean
>
> On 6/9/2016 4:45 PM, Mark Nottingham wrote:
>> YANG is attempting to register a number of media types that begin with "application/yang."; see:
>>   https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2
>>   https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3
>>
>> E.g., it calls "application/yang.api" a "subtype" of "application/yang".
>>
>> I read RFC6838 to prohibit this, because the portion of a subtype preceded by the first "." indicates the registration tree in a facet, and faceted media types are prohibited from being registered in the standards tree (unless they're grandfathered in in Appendix A). Furthermore, the drafts' use of "subtype" is erroneous.
>>
>> Is that understanding correct? If so, should they be using different media types, or is there some other way to accommodate what they want?
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/media-types
>
>
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types

--
Mark Nottingham   https://www.mnot.net/






_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types



--------------D379BDED6D65CD09A8085EAB-- From nobody Fri Jun 17 08:01:53 2016 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 57BCC12D6A5 for ; Fri, 17 Jun 2016 08:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coactus-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feAOE9eJwbHS for ; Fri, 17 Jun 2016 08:01:51 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9732012D6A1 for ; Fri, 17 Jun 2016 08:01:51 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5HF1UMK024608 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 15:01:51 GMT Received: by mail-vk0-x232.google.com with SMTP id j2so119231707vkg.2 for ; Fri, 17 Jun 2016 08:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coactus-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8fDUeFfV23w+z6y1KVm6+EntdF9p7exfEz1tfqmugZI=; b=qD9c2aVGzlZIO/DqUngHLbHrbT3yzp0jYmPfGCoIcpXfJ+EfK4ICzCG0mNRClQ8/wg rnNzhvD6YbPrepsUOAlHbZtn181fl7ybTUe3A6zDg9uK5LA3ZG7DyY60hlpXgAAVcGFu uPYL1MMPhH0czGqnLsMYsWx0EyTvRPdpzXkzdqb8RD8+vFlTYtpJqQmdUvTMwniHB5Ed bYUTRYb6NuypVcvLO2Dt5a0oqzzhmraz9QhCpsBC6Z0RL5+kQHPetPBIXBkEHzl2gDvq EBP8V19C5Q1pIjsaonw3fyYlyMsOKK7fZTGNNoaHfs/waYcY6x0AUar3WXkwB07HmgOL YIXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8fDUeFfV23w+z6y1KVm6+EntdF9p7exfEz1tfqmugZI=; b=FPoygNn6inHEw/6kT5uo2YnVfHIfPj7I6Mb9NWBwZcLmkwYEmMM6BxKBw9DmxqE+a9 1deG0b4aIICJQYEcayA3mGC0Arc+HwGVEPL/rCtGi5swjoc/ck+uLqPF49FsQXi3R2bm 0vk3pwdnAGgEyzEnoXy1I5um1f8MoymRTzlUJ0p2JYu5HeDxbMKYVlpcITloIIyFQh8p feN9LF6K4z9BMVYDOFghPdmLgIgws0M9npNTojgkhkyLMvWgzt+shvkbicZVKdkNRnP6 7L3HsWWIVpqJ2Mp8vgxTWsdIDV3cmHL/qNmKs0mDJZbsRB4hwsUumKUPxz303+e6OzKt OIgQ== X-Gm-Message-State: ALyK8tIE7/lEdXBM4CBgmUGB1/0DaPr7oZtAVhW9PfDad3P+zFVecG6l7UycLIm8vE64WikezbOllAM8CFcZiQ== X-Received: by 10.176.1.86 with SMTP id 80mr1067856uak.65.1466175690203; Fri, 17 Jun 2016 08:01:30 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.159.53.70 with HTTP; Fri, 17 Jun 2016 08:01:28 -0700 (PDT) X-Originating-IP: [23.233.58.109] In-Reply-To: <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> From: Mark Baker Date: Fri, 17 Jun 2016 11:01:28 -0400 X-Google-Sender-Auth: zr1NgReifOqHrWp5nSyhVb2Pnbs Message-ID: To: Sean Leonard Content-Type: text/plain; charset=UTF-8 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Fri, 17 Jun 2016 15:01:51 +0000 (UTC) Archived-At: Cc: Martin Bjorklund , Kent Watsen , Andy Bierman , Mark Nottingham , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 15:01:52 -0000 On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard wrote: > However, the other point has not been addressed. I do not see a technical > reason or justification for registering 8 media types, when > application/yang; yangtype="foo" (api, data, datastore, errors, operation, > stream, patch, patch-status) suffices. Please address. Each of those vocabularies are distinct languages with no - AFAICT - compatibility defined between them. Parameters aren't meant to carry additional typing info, though are occasionally used this way - in a non-authoritative manner - for certain types of compound documents (eg. media containers/codecs). That doesn't appear to apply here. From nobody Fri Jun 17 09:09:11 2016 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 3586112D7DF for ; Fri, 17 Jun 2016 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNnNymJHzEUN for ; Fri, 17 Jun 2016 09:09:08 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632F512D665 for ; Fri, 17 Jun 2016 09:09:07 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5HG8ifq029707 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 17 Jun 2016 16:09:05 GMT Received: from deRahm.local ([80.187.107.66]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0Lc3GP-1bdcZP3EhR-00jWLG; Fri, 17 Jun 2016 18:08:39 +0200 Message-ID: <57642083.9080807@hoplahup.net> Date: Fri, 17 Jun 2016 18:08:35 +0200 From: Paul Libbrecht User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Philippe Le Hegaret References: <5762B4A3.8080408@w3.org> In-Reply-To: <5762B4A3.8080408@w3.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/alternative; boundary="------------010409010105030405000708" X-Provags-ID: V03:K0:A+q/+UvNQrdH2yzPY6A/ck5v4HiipA0vciIrcHDWujjSUSIXb+X uhnDjcfQFEn2i7E2go5F50F/5K5CtA3gWKIDY3jja4PKa3PWcDCOLb481ZXyDXGatV7fi0/ CXASE8j+omAlXYC12dbclLsVbRxHLT69tTpAwCiwEuU9ns02nF+x3DrUZtdJZ2V+WZ3s++6 fCiPEl1FaQnYwFn6La3oA== X-UI-Out-Filterresults: notjunk:1;V01:K0:FBek6XzBN2s=:iXNfwpNoPNuHYRsvlJYwWf SJI3r5c4fwjv+DrbQPerY/r1DsMSJ98e79e/98x/+wNT+eSALbf+RlGgU20AKrF6HmbvKAWDx wM5xSBWo6YkEtieMqofz2OvsPjklrpO68XrDRRPIVZqVj11x+WzaA1jubY0bkGx3Oa+WL/Qyo HmRif4TczLpozO1mC9hkbb51ZYQgeFs6TjE0eboLwIHdBceTCo4QmMfiNyoreSm2tL0nAb+4v A79rr8jBCFy/NXbjA1KXZQr9pBblJDsZoap/mEnnM8PdsdfnMAh450gK+4GogM720sqvtX/sD 6XoAk1uZD8E1h1Pt/hn8D8bQ1ShBDwRzKtGEWb5Sj/MFDXTsqSXbicZ50PTnlMtF/ZObLpGnq uYOgdAGrSS51RDZP7g1bFpTpkTblfpdwD7gkLe+c+HvC5VCrKFLQMp1I8LnkacpmGFq6fkVYv 3K9GDsIQjwZL+Kfc9jmT/cymrQqX41GpUyqF7dL6WGqwuqwxjUcl5V1rGvZL1HZPfTjKySx3j YiLURZVprc1QyNgVRC5Edh/SMj7cIWi/JEVn+dHF8eE3Cb5Jisp7cxhHLxcrIbWub7IoTxS73 FEVlM7Ya7TtVWeVooZz0n63RwyH5yJ2eRHDMQGKAY6lDXQz3BbVO3iSi4ZuXTUdE5hM8EqrAo RniDQaGnXDYd3D6ZY2UpiNx2bLHTOjQ7W6anAWpr5vlqDalZvOnKUsUEedy6MDQCjo5HxhhWO E/fa49Qontxl8vfgglIv9fwlrBX7IIWpAzrgUg== X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Fri, 17 Jun 2016 16:09:06 +0000 (UTC) Archived-At: Cc: Timed Text Working Group , media-types@iana.org, 'Michael Dolan' Subject: Re: [media-types] Update to media type "application/ttml+xml" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 16:09:10 -0000 This is a multi-part message in MIME format. --------------010409010105030405000708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Philippe, I could not find a complete information but it looks like TTML is a format that could be contained in a clipboard. E.g. when transporting a (piece of a) transcript from one document to another. Could I, thus, suggest that you add below the Macintosh File type and such extra information two fields: - Windows clipboard flavour: - MacOS uniform type identifier: In order to find the right clipboard type names, a little bit of research should be done on the existing practice. Which tools exist out there which can accept or produce TTML? thanks in advance. Paul > Philippe Le Hegaret > 16 June 2016 at 16:16 > The W3C Timed Text Working Group would like to update the media type > "application/ttml+xml" as follows. Comments are welcome. > > It updates the media type, "application/ttml+xml" to add a new > parameter, codecs. All other provisions of the media type > specification remain the same. This supercedes the initial > registration information in TTML 1.0 Second Edition. > > Text copied below but see also the original text at: > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype > > > [[ > > Type name: > > application > Subtype name: > > ttml+xml > Required parameters: > > None. > Optional parameters: > > charset > > If specified, the charset parameter must match the XML > encoding declaration, or if absent, the actual encoding. See also > Encoding Considerations below. > profile > > The document profile of a TTMLDocument Instance may be > specified using an optional profile parameter, which, if specified, > the value of which must adhere to the syntax and semantics of > ttp:profile parameter defined by TTML 1.0 Second Edition, Section > 6.2.8 ttp:profile of the published specification. > > codecs > > The optional codecs parameter provides a short form version of > the profile parameter with multiple-profile combinatorial capability. > If a short (4-character) form of a profile is registered in the TTML > Profile Registry, it is recommended that this codecs parameter be used > and not the profile parameter. The nominal value of this parameter is > a single 4 character code from the registry. > > Additionally, applications using the entries in the registry > are encouraged to adopt the following combination syntax: > > Employ two combination operators, '+' (AND) and '|' (OR), > which may be used to specify, respectively, that multiple processor > profiles apply (simultaneously) or that any processor profile of a > list of profiles may apply individually. If both operators are used in > a codecs value, then the '+' operator has precedence. > > The example: "A+B|C+D|E" states that a TTML processor that > implements any one of A+B or C+D or E processor profiles satisfies, at > first order, the requirements to fetch and begin decode/processing of > a TTML document, where X+Y means that both X and Y processor profiles > must be supported, and X|Y means that either X or Y processor profile > must be supported. > > For more information about processor profile combination, see > TTML2 Profile Combination. > > Encoding considerations: > > Same for application/xml, except constrained to either UTF-8 or > UTF-16. See IETF RFC 3023, XML Media Types, Section 3.2. For the > purpose of filling out the IANA Application for Media Type > (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies. > Security considerations: > > As with other XML types and as noted in IETF RFC 3023, XML Media > Types, Section 10, repeated expansion of maliciously constructed XML > entities can be used to consume large amounts of memory, which may > cause XML processors in constrained environments to fail. > > In addition, because of the extensibility features for TTML and of > XML in general, it is possible that "application/ttml+xml" may > describe content that has security implications beyond those described > here. However, TTML does not provide for any sort of active or > executable content, and if the processor follows only the normative > semantics of the published specification, this content will be outside > TTML namespaces and may be ignored. Only in the case where the > processor recognizes and processes the additional content, or where > further processing of that content is dispatched to other processors, > would security issues potentially arise. And in that case, they would > fall outside the domain of this registration document. > > Although not prohibited, there are no expectations that XML > signatures or encryption would normally be employed. > Interoperability considerations: > > The published specification describes processing semantics that > dictate behavior that must be followed when dealing with, among other > things, unrecognized elements and attributes, both in TTML namespaces > and in other namespaces. > > Because TTML is extensible, conformant "application/ttml+xml" > processors may expect (and enforce) that content received is > well-formed XML, but it cannot be guaranteed that the content is valid > to a particular DTD or Schema or that the processor will recognize all > of the elements and attributes in the document. > Published specification: > > This media type registration is extracted from the TTML Profile > Registry. > Applications that use this media type: > > TTML is used in the television industry for the purpose of > authoring, transcoding and exchanging timed text information and for > delivering captions, subtitles, and other metadata for television > material repurposed for the Web or, more generally, the Internet. > > There is partial and full support of TTML in components used by > several Web browsers plugins, and in a number of caption authoring tools. > Additional information: > > Magic number(s): > File extension(s): > > .ttml > Macintosh file type code(s): > > "TTML" > Fragment identifiers: > > For documents labeled as application/ttml+xml, the fragment > identifier notation is intended to be used with xml:id attributes, as > described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) > specification. > > Person & email address to contact for further information: > > Timed Text Working Group (public-tt@w3.org) > Intended usage: > > COMMON > Restrictions on usage: > > None > Author: > > The published specification is a work product of the World Wide > Web Consortium's Timed Text (TT) Working Group. > Change controller: > > The W3C has change control over this specification. > ]] > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype > > Thank you, > > Philippe > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --------------010409010105030405000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Philippe,

I could not find a complete information but it looks like TTML is a format that could be contained in a clipboard. E.g. when transporting a (piece of a) transcript from one document to another. Could I, thus, suggest that you add below the Macintosh File type and such extra information two fields:
- Windows clipboard flavour:
- MacOS uniform type identifier:
In order to find the right clipboard type names, a little bit of research should be done on the existing practice.
Which tools exist out there which can accept or produce TTML?

thanks in advance.

Paul
16 June 2016 at 16:16
The W3C Timed Text Working Group would like to update the media type "application/ttml+xml" as follows. Comments are welcome.

It updates the media type, "application/ttml+xml" to add a new parameter, codecs. All other provisions of the media type specification remain the same. This supercedes the initial registration information in TTML 1.0 Second Edition.

Text copied below but see also the original text at:
 https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype

[[

Type name:

    application
Subtype name:

    ttml+xml
Required parameters:

    None.
Optional parameters:

    charset

        If specified, the charset parameter must match the XML encoding declaration, or if absent, the actual encoding. See also Encoding Considerations below.
    profile

        The document profile of a TTMLDocument Instance may be specified using an optional profile parameter, which, if specified, the value of which must adhere to the syntax and semantics of ttp:profile parameter defined by TTML 1.0 Second Edition, Section 6.2.8 ttp:profile of the published specification.

    codecs

        The optional codecs parameter provides a short form version of the profile parameter with multiple-profile combinatorial capability. If a short (4-character) form of a profile is registered in the TTML Profile Registry, it is recommended that this codecs parameter be used and not the profile parameter. The nominal value of this parameter is a single 4 character code from the registry.

        Additionally, applications using the entries in the registry are encouraged to adopt the following combination syntax:

        Employ two combination operators, '+' (AND) and '|' (OR), which may be used to specify, respectively, that multiple processor profiles apply (simultaneously) or that any processor profile of a list of profiles may apply individually. If both operators are used in a codecs value, then the '+' operator has precedence.

        The example: "A+B|C+D|E" states that a TTML processor that implements any one of A+B or C+D or E processor profiles satisfies, at first order, the requirements to fetch and begin decode/processing of a TTML document, where X+Y means that both X and Y processor profiles must be supported, and X|Y means that either X or Y processor profile must be supported.

        For more information about processor profile combination, see TTML2 Profile Combination.

Encoding considerations:

    Same for application/xml, except constrained to either UTF-8 or UTF-16. See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose of filling out the IANA Application for Media Type (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies.
Security considerations:

    As with other XML types and as noted in IETF RFC 3023, XML Media Types, Section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail.

    In addition, because of the extensibility features for TTML and of XML in general, it is possible that "application/ttml+xml" may describe content that has security implications beyond those described here. However, TTML does not provide for any sort of active or executable content, and if the processor follows only the normative semantics of the published specification, this content will be outside TTML namespaces and may be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document.

    Although not prohibited, there are no expectations that XML signatures or encryption would normally be employed.
Interoperability considerations:

    The published specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in TTML namespaces and in other namespaces.

    Because TTML is extensible, conformant "application/ttml+xml" processors may expect (and enforce) that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document.
Published specification:

    This media type registration is extracted from the TTML Profile Registry.
Applications that use this media type:

    TTML is used in the television industry for the purpose of authoring, transcoding and exchanging timed text information and for delivering captions, subtitles, and other metadata for television material repurposed for the Web or, more generally, the Internet.

    There is partial and full support of TTML in components used by several Web browsers plugins, and in a number of caption authoring tools.
Additional information:

    Magic number(s):
    File extension(s):

        .ttml
    Macintosh file type code(s):

        "TTML"
    Fragment identifiers:

        For documents labeled as application/ttml+xml, the fragment identifier notation is intended to be used with xml:id attributes, as described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) specification.

Person & email address to contact for further information:

    Timed Text Working Group (public-tt@w3.org)
Intended usage:

    COMMON
Restrictions on usage:

    None
Author:

    The published specification is a work product of the World Wide Web Consortium's Timed Text (TT) Working Group.
Change controller:

    The W3C has change control over this specification.
]]
https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype

Thank you,

Philippe

_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types

--------------010409010105030405000708-- From nobody Fri Jun 17 09:47:45 2016 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 6B84C12D158 for ; Fri, 17 Jun 2016 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lejp4m35ijJ4 for ; Fri, 17 Jun 2016 09:47:43 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6739F12D85E for ; Fri, 17 Jun 2016 09:47:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5HGlMJH008564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 17 Jun 2016 16:47:43 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1HD8EK7M8010YMZ@mauve.mrochek.com> for media-types@iana.org; Fri, 17 Jun 2016 09:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1466181738; bh=NzH3NEKuAzj4ufYVihsyqjyGHvjXJFLoEabKVmkoCZs=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=QkYgPkXfDl80IxheL0HNZy3I0JrymSqAufuyseBsELQkA6krq9iG/XwnsqnM3vM0S Sxbp1BaF1S0Lm/8I/BA+sjs982nVVud6BQRSNUaQZgel5A2YSbUW84ca+qCfoOlCK6 +rbQgSUiYFMUSaglU7G1mo8xANn/YDBaxLE64RyI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q17NM7WHC000005M@mauve.mrochek.com>; Fri, 17 Jun 2016 09:42:16 -0700 (PDT) Message-id: <01Q1HD8CXX7A00005M@mauve.mrochek.com> Date: Fri, 17 Jun 2016 09:36:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 Jun 2016 11:01:28 -0400" References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> To: Mark Baker X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 17 Jun 2016 16:47:43 +0000 (UTC) Archived-At: Cc: Martin Bjorklund , Kent Watsen , Andy Bierman , Mark Nottingham , Sean Leonard , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 16:47:44 -0000 > On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard wrote: > > However, the other point has not been addressed. I do not see a technical > > reason or justification for registering 8 media types, when > > application/yang; yangtype="foo" (api, data, datastore, errors, operation, > > stream, patch, patch-status) suffices. Please address. > Each of those vocabularies are distinct languages with no - AFAICT - > compatibility defined between them. Parameters aren't meant to carry > additional typing info, though are occasionally used this way - in a > non-authoritative manner - for certain types of compound documents > (eg. media containers/codecs). That doesn't appear to apply here. If so, then it sounds to me like distinct types are entirely appropriate. Generally speaking we try not to have more than one name for a given type - the reasons for this are, I hope, obvious. If there's a need to carry information externally to further label the type or control it's handling, that's what type and disposition parameters are for. That said, we have made exceptions in cases where types are used in contexts where additional external parameterization isn't possible. This has happened several times, and it's why there's no hard rule requiring a single name for a type. Ned From nobody Fri Jun 17 09:58:44 2016 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 0DA9212D6A8 for ; Fri, 17 Jun 2016 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnsrHA6Oi3Fg for ; Fri, 17 Jun 2016 09:58:40 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE3D12D60B for ; Fri, 17 Jun 2016 09:58:40 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5HGwJWE017528 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 16:58:40 GMT Received: by mail-vk0-x22d.google.com with SMTP id j2so123605800vkg.2 for ; Fri, 17 Jun 2016 09:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NjYYuAHWbSO7C0H6fJpTLzwTIqAvH2m37wvHUMsZlk8=; b=nPfuyquD79QgnPw4YNROuSpP7suuoGJupk5RS6L+DOAX4V462KBBbV2SkGT+i+5jkN MtPfZd2wRjraWlpQI6BW050qDMbP9UTolEJ/4xZBNjg2aP3VCv+ldvUxJI20jBNAG+1L uwStckrbjsU9PnDiGUCjZj1ZR8Le4fuNIm5OKk3MP0ZRmc4RgwX2xm5qoVzFD+3g1tFr rhH9jM0PbuWUV2fqnbpHY0fLJ8M3PtCemRAybB9ga72k3+ZIdl1ZPBN0fiy03ryStMQ8 AbZPjM72t/FZHWNG+vfnmCgJo0QJk+wv/6EwiI7qYYi5LfXm404oNVX3t2HB8OjEekAn hxCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NjYYuAHWbSO7C0H6fJpTLzwTIqAvH2m37wvHUMsZlk8=; b=LZWA6RZKC/nirXL1mPA/v2uPaR7uHVZMQforgQ68QEh/wn5Yn0St91TKQbPMR/L4vs q9z+5ru7W50gUTcAlzmP/gxAsRpyOpoEQwIyFp9z3pUCwFkb57g19lUfPfxN/ky8s+Yg RZXX31yiQEkp2mBq7lDRnVEN17usDU45txHhHhApBqVIlToDdmLekdG5+CoqAtGilcVL vmckLn5Lzran+yY5AH3cm1T6/fwFxhfJfbyCJJ5+xjjZnzsQe9tzlBp/RlDRuqzCpIsX ge794W2Dlcm9C9ngvXugU9Xv8zTYfjq41HiWydcDP+SNEmLd95wT9+cOaS2QlMskNvjt wmMQ== X-Gm-Message-State: ALyK8tI47+bqkJ9nNYd1TeFqkSwJ3fkQKolKf4fnAPtns9W6dzI/MA/zgTLq693ZZTP8qu+1ZXAvplCWnMXqVw== MIME-Version: 1.0 X-Received: by 10.31.94.201 with SMTP id s192mr1551425vkb.89.1466182699481; Fri, 17 Jun 2016 09:58:19 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Fri, 17 Jun 2016 09:58:18 -0700 (PDT) In-Reply-To: <01Q1HD8CXX7A00005M@mauve.mrochek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> <01Q1HD8CXX7A00005M@mauve.mrochek.com> Date: Fri, 17 Jun 2016 09:58:18 -0700 Message-ID: From: Andy Bierman To: Ned Freed Content-Type: multipart/alternative; boundary=001a114e513cfaa30405357c42f3 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [IPv6:2620:0:2d0:201::1:73]); Fri, 17 Jun 2016 16:58:40 +0000 (UTC) Archived-At: Cc: Mark Baker , Martin Bjorklund , Kent Watsen , Mark Nottingham , Sean Leonard , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 16:58:42 -0000 --001a114e513cfaa30405357c42f3 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed wrote: > > On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard > wrote: > > > However, the other point has not been addressed. I do not see a > technical > > > reason or justification for registering 8 media types, when > > > application/yang; yangtype="foo" (api, data, datastore, errors, > operation, > > > stream, patch, patch-status) suffices. Please address. > > > Each of those vocabularies are distinct languages with no - AFAICT - > > compatibility defined between them. Parameters aren't meant to carry > > additional typing info, though are occasionally used this way - in a > > non-authoritative manner - for certain types of compound documents > > (eg. media containers/codecs). That doesn't appear to apply here. > > If so, then it sounds to me like distinct types are entirely appropriate. > > Generally speaking we try not to have more than one name for a given type > - the > reasons for this are, I hope, obvious. If there's a need to carry > information > externally to further label the type or control it's handling, that's what > type > and disposition parameters are for. > > That said, we have made exceptions in cases where types are used in > contexts > where additional external parameterization isn't possible. This has > happened > several times, and it's why there's no hard rule requiring a single name > for a type. > I would really like to simplify the registration. Do I need 1 registration for +xml and another for +json? If so, then there are 16 of these. So far. They all share the common property that the instance document conforms to a specific YANG "restconf-media-type". This is a YANG extension and can be used in any YANG module, so there could be 100s or 1000s of these that will never get registered. If we could have 1 media type with a parameter, plus encoding, that would be best. > Ned > > Andy --001a114e513cfaa30405357c42f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed <ned.freed@mrochek.com<= /a>> wrote:
> On Fri, Jun 17= , 2016 at 8:59 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
> > However, the other point has not been addressed. I do not see a t= echnical
> > reason or justification for registering 8 media types, when
> > application/yang; yangtype=3D"foo" (api, data, datastor= e, errors, operation,
> > stream, patch, patch-status) suffices. Please address.

> Each of those vocabularies are distinct languages with no - AFAICT - > compatibility defined between them. Parameters aren't meant to car= ry
> additional typing info, though are occasionally used this way - in a > non-authoritative manner - for certain types of compound documents
> (eg. media containers/codecs). That doesn't appear to apply here.<= br>
If so, then it sounds to me like distinct types are entirely appropriate.
Generally speaking we try not to have more than one name for a given type -= the
reasons for this are, I hope, obvious. If there's a need to carry infor= mation
externally to further label the type or control it's handling, that'= ;s what type
and disposition parameters are for.

That said, we have made exceptions in cases where types are used in=C2=A0 c= ontexts
where additional external parameterization isn't possible. This has hap= pened
several times, and it's why there's no hard rule requiring a single= name
for a type.


I would real= ly like to simplify the registration.
Do I need 1 registration fo= r +xml and another for +json?
If so, then there are 16 of these. = So far.

They all share the common property that th= e instance document conforms
to a specific YANG "restconf-me= dia-type". This is a YANG extension and
can be used in any Y= ANG module, so there could be 100s or 1000s of these
that will ne= ver get registered.

If we could have 1 media type = with a parameter, plus encoding, that would be best.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned



<= /div>
Andy

--001a114e513cfaa30405357c42f3-- From nobody Fri Jun 17 16:22:06 2016 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 915DC12DC45 for ; Fri, 17 Jun 2016 16:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdI8INGKlFVn for ; Fri, 17 Jun 2016 16:22:04 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC39512D63C for ; Fri, 17 Jun 2016 16:22:03 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5HNLgSb030320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 23:22:02 GMT Received: by mail-vk0-x231.google.com with SMTP id u64so134584662vkf.3 for ; Fri, 17 Jun 2016 16:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gvI7v1MHpKE5FJW5/PrH3pGJg1crcWugLRbkPskXUyw=; b=O00MSg6HiFHbIJm9lvKo5L8U4Ta8dM8mhllPWIIzW3wbd7mDOUuYSqMpKe07QUZrZG fTEZ/M1+6n7QbXM0Xwm0PlIsAfwfnx0/8LMlqRthIJhKQbtktyn7cIAKtbX66y3wz4oy hILVJeywT9uLtP+4JGkjaln3cLDOMf4fnVSg0AzOCYO3Zzk/40YoPLXyLbA+uLHHGDaN RoqZAXR6spdL20xKenbPm95rasJaArYVO5MDhKybIDgQfZ11WQQh+BvK1jKWaeQN/eju LzVzHrtEecHOQ2Kmd3U3iye6T4QtGXLMr3GEj1yuX6v7MCXOWOJ9AqLENdLRouhKu7C1 SkdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gvI7v1MHpKE5FJW5/PrH3pGJg1crcWugLRbkPskXUyw=; b=ehXGnB60nd20Frd7j81uG56zaFdUkpgdyCkXpEE1g4/x2buvpeSrXqCBiLkVqKTo38 dooOurhUkIWO5oOAFj+Ane3CJsDkRzDJJH67Sura3jV/y/hv7xHNmjPLUPyOn9eVlIEl 9rgsoS2vESuTD9ivka+ZrsxbQD9ziOQNfnjDlI6glTzMbz7YGHX7FHxqG2xf9RF28dor kkDPt6IdgoUmM9fXOzErYV6KafSs1LCn14VMh9gxFbCqy4ZDNsdg+7f+ErB2Cu2Qz9bK g0sJSQPmmvN3CZeZ68tEQgeW4lmiOEhy6VL5gYR2hMQ2fy7ZHQ9vY81GE6Z/ZzlhwuML sghQ== X-Gm-Message-State: ALyK8tLvtH/0M2sBgpU8tg4X54p7iPTys0GdDNvUxdEmn1wsUKqxApCQ3OjK0lmgdSHYxZrdDGSlM1g2pj11cg== MIME-Version: 1.0 X-Received: by 10.176.7.7 with SMTP id h7mr1954969uah.9.1466205702180; Fri, 17 Jun 2016 16:21:42 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Fri, 17 Jun 2016 16:21:42 -0700 (PDT) In-Reply-To: <01Q1HD8CXX7A00005M@mauve.mrochek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> <01Q1HD8CXX7A00005M@mauve.mrochek.com> Date: Fri, 17 Jun 2016 16:21:42 -0700 Message-ID: From: Andy Bierman To: Ned Freed Content-Type: multipart/alternative; boundary=94eb2c1229d80c01640535819e57 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [IPv6:2620:0:2830:201::1:71]); Fri, 17 Jun 2016 23:22:02 +0000 (UTC) Archived-At: Cc: Mark Baker , Martin Bjorklund , Kent Watsen , Mark Nottingham , Sean Leonard , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 23:22:05 -0000 --94eb2c1229d80c01640535819e57 Content-Type: text/plain; charset=UTF-8 Hi, We would like to support the restconf-media-type even from different YANG modules: module A { import ietf-restconf { prefix rc; } rc:restconf-media-type "foo" { container X { } } } module B { import ietf-restconf { prefix rc; } rc:restconf-media-type "foo" { container Y { } } } We cannot control usage of this YANG extension and therefore we cannot prevent duplicates. The current proposal will not work. 1 media type with a mandatory parameter "type" would work for what we need: application/yang-data+xml;type=A:foo application/yang-data+xml;type=B:foo application/yang-data+json;type=B:foo Andy On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed wrote: > > On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard > wrote: > > > However, the other point has not been addressed. I do not see a > technical > > > reason or justification for registering 8 media types, when > > > application/yang; yangtype="foo" (api, data, datastore, errors, > operation, > > > stream, patch, patch-status) suffices. Please address. > > > Each of those vocabularies are distinct languages with no - AFAICT - > > compatibility defined between them. Parameters aren't meant to carry > > additional typing info, though are occasionally used this way - in a > > non-authoritative manner - for certain types of compound documents > > (eg. media containers/codecs). That doesn't appear to apply here. > > If so, then it sounds to me like distinct types are entirely appropriate. > > Generally speaking we try not to have more than one name for a given type > - the > reasons for this are, I hope, obvious. If there's a need to carry > information > externally to further label the type or control it's handling, that's what > type > and disposition parameters are for. > > That said, we have made exceptions in cases where types are used in > contexts > where additional external parameterization isn't possible. This has > happened > several times, and it's why there's no hard rule requiring a single name > for a type. > > Ned > > --94eb2c1229d80c01640535819e57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


We would like to sup= port the restconf-media-type even from different YANG modules:
module A {
=C2=A0 =C2=A0import ietf-restconf { prefi= x rc; }
=C2=A0 =C2=A0rc:restconf-media-type "foo" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0container X { }
=C2=A0 =C2=A0}<= /div>

}

module B {
=C2=A0 =C2=A0import ietf-restconf { prefix rc; }
=C2=A0 = =C2=A0rc:restconf-media-type "foo" {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0container Y { }
=C2=A0 =C2=A0}

}



We cannot c= ontrol usage of this YANG extension and therefore we cannot prevent duplica= tes.
The current proposal will not work.

1 media type with a mandatory parameter "type" would work for wh= at we need:

=C2=A0 =C2=A0 application/yang-data+xm= l;type=3DA:foo

=C2=A0 =C2=A0 application/yang-data= +xml;type=3DB:foo

=C2=A0 =C2=A0 applicati= on/yang-data+json;type=3DB:foo


Andy


On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed <ned.fr= eed@mrochek.com> wrote:
>= ; On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
> > However, the other point has not been addressed. I do not see a t= echnical
> > reason or justification for registering 8 media types, when
> > application/yang; yangtype=3D"foo" (api, data, datastor= e, errors, operation,
> > stream, patch, patch-status) suffices. Please address.

> Each of those vocabularies are distinct languages with no - AFAICT - > compatibility defined between them. Parameters aren't meant to car= ry
> additional typing info, though are occasionally used this way - in a > non-authoritative manner - for certain types of compound documents
> (eg. media containers/codecs). That doesn't appear to apply here.<= br>
If so, then it sounds to me like distinct types are entirely appropriate.
Generally speaking we try not to have more than one name for a given type -= the
reasons for this are, I hope, obvious. If there's a need to carry infor= mation
externally to further label the type or control it's handling, that'= ;s what type
and disposition parameters are for.

That said, we have made exceptions in cases where types are used in=C2=A0 c= ontexts
where additional external parameterization isn't possible. This has hap= pened
several times, and it's why there's no hard rule requiring a single= name
for a type.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned


--94eb2c1229d80c01640535819e57-- From mike@dolan.tv Fri Jun 17 17:13:55 2016 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 4CB7212DC62 for ; Fri, 17 Jun 2016 17:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tbtinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_REzq1YbeCb for ; Fri, 17 Jun 2016 17:13:52 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDF712DC5F for ; Fri, 17 Jun 2016 17:13:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0096.outbound.protection.outlook.com [157.56.110.96]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5I0DVNf002308 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 18 Jun 2016 00:13:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TBTInc.onmicrosoft.com; s=selector1-dolan-tv; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8eNTIk8LY1Tvpps54+0xiuCss3JvhAIKzMZeE118KEA=; b=Cyfkmw4TEck1FYV32Sm4n6Dz9lsmDno7/K30WNvGIg1UDrzO8onnJZYmFT/BW9UiDQ0LS5mRPJgpN2jfmB283xSfDrbKVGFn+P9BSRy3hy47Vb578zKOviSaZduqjJZFICLhkMwWU3m93debzDGHuj+aVT5yWnaG6TMYKNdHQfc= Received: from SN1PR10MB0494.namprd10.prod.outlook.com (10.162.103.142) by SN1PR10MB0493.namprd10.prod.outlook.com (10.162.103.141) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 17 Jun 2016 23:57:08 +0000 Received: from SN1PR10MB0494.namprd10.prod.outlook.com ([10.162.103.142]) by SN1PR10MB0494.namprd10.prod.outlook.com ([10.162.103.142]) with mapi id 15.01.0517.014; Fri, 17 Jun 2016 23:57:08 +0000 From: Michael Dolan To: "Eric Prud'hommeaux" Thread-Topic: [media-types] Update to media type "application/ttml+xml" Thread-Index: AQHRyAq7636ub6Ez70K13lRk8lT965/uVO7w Date: Fri, 17 Jun 2016 23:57:08 +0000 Message-ID: References: <5762B4A3.8080408@w3.org> <20160616200724.GC23703@w3.org> In-Reply-To: <20160616200724.GC23703@w3.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mike@dolan.tv; x-originating-ip: [2602:306:c40d:4ce0:9c20:7c6d:5d79:e93f] x-ms-office365-filtering-correlation-id: 2d1a394e-6b01-4840-d108-08d3970b17cd x-microsoft-exchange-diagnostics: 1; SN1PR10MB0493; 6:jNhlfnhI270zQrXJqAjylQC4wq+MJ2bXLOW8kCMXm5QeqFL5N0bDHVT7Maj9waleIHtAuXsjwEX25azSw9eYWpFkeCrULy5rx2l5PHGgfj7LpXFTv0bpdVeomgb6+mUXQXEDn+026cm27yazX4MRdI2OKervozqJozs+9AUJVF95aO9cFxaMz4I3swI2TedIf4qEDqlZA3JLYotFlkiZ7yGOdGkKlX3OrnbTaSDk1b8e4W09KAGquwzl0ecXGv+E78Bp7GN8876kHaG6/cIu2/343OAFxQP4bA6lf9e8httxXnMri3vWBc1BhCcgOfkp; 5:YwPtthJZqxy+JCmpVk7eJqrT9LPsOmgoJwkA9XF+kCRBcN4KSiZ16ncwCp2oFWWLodVBQwIlYB4wdGn4kPI3iR6Iei6MDmm5xl531rpfE6V0r64+hgeQDpreYZswD0tgXt7NaHU1jdOlX5BVYEIlgQ==; 24:e6C0BAJXmCtP0QL+VmtIE2cK19GfAPHta6uKJ2ODlHNxQnIrOr1LwZiLyolUUdHnnRYlI1SQLpsIg7B0Nsqi2XQGKGjs1raaeoAlhfSzVSQ=; 7:I/5MgopOzF1JcmsKN8ADtxnb3LGJaR8pRCIDx698WSOv3KF4ZdVWPzxKOhVEZUT/fupRPI30i+w5nS9tCNSVTSfBs+pFLpy0m+jhe+63XTvMw7Irb1hyVYb0DEvmsqN0mmUSFpadCrPnCZZQ1TjcBpzJMBNvObn2Rleyfu40BY+6Rob6V+mxE4rr1RtgpubqKh9z4LN3ZSGqZgj0ErZUUg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR10MB0493; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046); SRVR:SN1PR10MB0493; BCL:0; PCL:0; RULEID:; SRVR:SN1PR10MB0493; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(50854003)(584324002)(189002)(377454003)(52044002)(199003)(377424004)(92566002)(74316001)(15650500001)(2420400007)(5004730100002)(2906002)(8936002)(2950100001)(10710500007)(5002640100001)(106356001)(11100500001)(189998001)(86362001)(7110500001)(101416001)(106116001)(10400500002)(97736004)(110136002)(68736007)(99286002)(105586002)(33656002)(9686002)(4326007)(15975445007)(8676002)(19580395003)(19580405001)(31430400001)(74482002)(3660700001)(102836003)(586003)(122556002)(3280700002)(76176999)(81166006)(50986999)(54356999)(81156014)(5003600100002)(6116002)(76576001)(7846002)(87936001)(2900100001)(77096005)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR10MB0493; H:SN1PR10MB0494.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: dolan.tv does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dolan.tv X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 23:57:08.7158 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: aa3afb1e-4be8-4304-a09b-de5a500856f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR10MB0493 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Sat, 18 Jun 2016 00:13:51 +0000 (UTC) Archived-At: X-Mailman-Approved-At: Fri, 17 Jun 2016 19:44:26 -0700 Cc: Philippe Le Hegaret , Timed Text Working Group , "media-types@iana.org" Subject: Re: [media-types] Update to media type "application/ttml+xml" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 00:15:09 -0000 Hi Eric- Thanks. I think I agree with your comment about "first order". It's either = right or it isn't. And what a robust decoder may wish to do if it detects = that it is wrong (and also figures out what it really is) should be out of = scope. I'm not sure I follow your comment about the URL. TTML2 Table 6-3 needs the= text that precedes it to understand it. Maybe I don't understand your com= ment. Thanks, Mike -----Original Message----- From: Eric Prud'hommeaux [mailto:eric@w3.org]=20 Sent: Thursday, June 16, 2016 1:07 PM To: Michael Dolan Cc: media-types@iana.org; Timed Text Working Group ; Phil= ippe Le Hegaret Subject: Re: [media-types] Update to media type "application/ttml+xml" * Philippe Le Hegaret [2016-06-16 10:16-0400] > The W3C Timed Text Working Group would like to update the media type=20 > "application/ttml+xml" as follows. Comments are welcome. >=20 > It updates the media type, "application/ttml+xml" to add a new=20 > parameter, codecs. All other provisions of the media type=20 > specification remain the same. This supercedes the initial=20 > registration information in TTML 1.0 Second Edition. >=20 > Text copied below but see also the original text at: > =20 > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediat > ype >=20 > [[ >=20 > Type name: >=20 > application > Subtype name: >=20 > ttml+xml > Required parameters: >=20 > None. > Optional parameters: >=20 > charset >=20 > If specified, the charset parameter must match the XML=20 > encoding declaration, or if absent, the actual encoding. See also=20 > Encoding Considerations below. > profile >=20 > The document profile of a TTMLDocument Instance may be=20 > specified using an optional profile parameter, which, if specified,=20 > the value of which must adhere to the syntax and semantics of=20 > ttp:profile parameter defined by TTML 1.0 Second Edition, Section=20 > 6.2.8 ttp:profile of the published specification. >=20 > codecs >=20 > The optional codecs parameter provides a short form version of=20 > the profile parameter with multiple-profile combinatorial capability.=20 > If a short > (4-character) form of a profile is registered in the TTML Profile=20 > Registry, it is recommended that this codecs parameter be used and not=20 > the profile parameter. The nominal value of this parameter is a single=20 > 4 character code from the registry. >=20 > Additionally, applications using the entries in the registry=20 > are encouraged to adopt the following combination syntax: >=20 > Employ two combination operators, '+' (AND) and '|' (OR),=20 > which may be used to specify, respectively, that multiple processor=20 > profiles apply > (simultaneously) or that any processor profile of a list of profiles=20 > may apply individually. If both operators are used in a codecs value,=20 > then the '+' operator has precedence. >=20 > The example: "A+B|C+D|E" states that a TTML processor that=20 > implements any one of A+B or C+D or E processor profiles satisfies, at=20 > first order, the requirements to fetch and begin decode/processing of=20 > a TTML PLH indicated that "at first order" is something like an initial claim abou= t the embedded codecs. Is it the intention that there be some sort of recov= ery if that initial claim is incorrect? What should the processor do if the= advertised codec is ogg and the actual codec is xvid? If you strike "at fi= rst order", I think you could avoid having to define the behavior in the ev= ent of invalid parameters. > document, where X+Y means that both X and Y processor profiles must be=20 > supported, and X|Y means that either X or Y processor profile must be=20 > supported. >=20 > For more information about processor profile combination, see=20 > TTML2 Profile Combination. "TTML2 Profile Comination" has no URL in the reg. The hyptertext version = links to https://www.w3.org/TR/ttml2/#profile-attribute-processorProfileCombinat= ion propose instead link to https://www.w3.org/TR/ttml2/#processor-profile-combination-table and embedding that link in ()s in the text. > Encoding considerations: >=20 > Same for application/xml, except constrained to either UTF-8 or UTF-1= 6. > See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose of=20 > filling out the IANA Application for Media Type=20 > (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies. > Security considerations: >=20 > As with other XML types and as noted in IETF RFC 3023, XML Media=20 > Types, Section 10, repeated expansion of maliciously constructed XML=20 > entities can be used to consume large amounts of memory, which may=20 > cause XML processors in constrained environments to fail. >=20 > In addition, because of the extensibility features for TTML and of=20 > XML in general, it is possible that "application/ttml+xml" may=20 > describe content that has security implications beyond those described=20 > here. However, TTML does not provide for any sort of active or=20 > executable content, and if the processor follows only the normative=20 > semantics of the published specification, this content will be outside=20 > TTML namespaces and may be ignored. Only in the case where the=20 > processor recognizes and processes the additional content, or where=20 > further processing of that content is dispatched to other processors,=20 > would security issues potentially arise. And in that case, they would=20 > fall outside the domain of this registration document. >=20 > Although not prohibited, there are no expectations that XML=20 > signatures or encryption would normally be employed. > Interoperability considerations: >=20 > The published specification describes processing semantics that=20 > dictate behavior that must be followed when dealing with, among other=20 > things, unrecognized elements and attributes, both in TTML namespaces=20 > and in other namespaces. >=20 > Because TTML is extensible, conformant "application/ttml+xml"=20 > processors may expect (and enforce) that content received is=20 > well-formed XML, but it cannot be guaranteed that the content is valid=20 > to a particular DTD or Schema or that the processor will recognize all=20 > of the elements and attributes in the document. > Published specification: >=20 > This media type registration is extracted from the TTML Profile=20 > Registry. > Applications that use this media type: >=20 > TTML is used in the television industry for the purpose of=20 > authoring, transcoding and exchanging timed text information and for=20 > delivering captions, subtitles, and other metadata for television=20 > material repurposed for the Web or, more generally, the Internet. >=20 > There is partial and full support of TTML in components used by=20 > several Web browsers plugins, and in a number of caption authoring tools. > Additional information: >=20 > Magic number(s): > File extension(s): >=20 > .ttml > Macintosh file type code(s): >=20 > "TTML" > Fragment identifiers: >=20 > For documents labeled as application/ttml+xml, the fragment=20 > identifier notation is intended to be used with xml:id attributes, as=20 > described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1)=20 > specification. >=20 > Person & email address to contact for further information: >=20 > Timed Text Working Group (public-tt@w3.org) Intended usage: >=20 > COMMON > Restrictions on usage: >=20 > None > Author: >=20 > The published specification is a work product of the World Wide=20 > Web Consortium's Timed Text (TT) Working Group. > Change controller: >=20 > The W3C has change control over this specification. > ]] > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediat > ype >=20 > Thank you, >=20 > Philippe >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than em= ail address distribution. There are subtle nuances encoded in font variation and clever layout which = can only be seen by printing this message on high-clay paper. From nobody Fri Jun 17 19:44:32 2016 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 E975212DA46 for ; Fri, 17 Jun 2016 19:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dVmk16ilcPK for ; Fri, 17 Jun 2016 19:38:04 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A8112D8CF for ; Fri, 17 Jun 2016 19:38:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5I2bgOa016709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 18 Jun 2016 02:38:02 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1HXUAFK28017H2B@mauve.mrochek.com> for media-types@iana.org; Fri, 17 Jun 2016 19:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1466217156; bh=n1JZ0Ust976vd5Cl9mgXNJp2+hZOBJ17r5PNcjfuAtI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=OrjjwXLJACW8beUxBnCY3PrdV6LVPTui2BOBf8nObsebrU3UqVxUuLrJJFXQbutBa eK/LthgDbeD1aw69R5+SWq9SoleWbTsoemsdSsE0hoZYhA10QxUCqYGh9NaF5QNb/k HcEQ4pB798omQrznAkLote81LDn3C6c3tq/QiSCo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q17NM7WHC000005M@mauve.mrochek.com>; Fri, 17 Jun 2016 19:32:32 -0700 (PDT) Message-id: <01Q1HXU6VEXY00005M@mauve.mrochek.com> Date: Fri, 17 Jun 2016 19:12:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 Jun 2016 09:58:18 -0700" References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> <01Q1HD8CXX7A00005M@mauve.mrochek.com> To: Andy Bierman X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Sat, 18 Jun 2016 02:38:03 +0000 (UTC) Archived-At: X-Mailman-Approved-At: Fri, 17 Jun 2016 19:44:26 -0700 Cc: Mark Baker , Martin Bjorklund , Ned Freed , Mark Nottingham , Sean Leonard , Benoit Claise , Kent Watsen , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 02:38:05 -0000 > I would really like to simplify the registration. > Do I need 1 registration for +xml and another for +json? That's entirely dependent on how the types are used. If all of your applications that use these types accept data in either format and don't require external information to tell them what to do, then there's no need to have separate types. (Of course you cannot use type suffixes in this case.) But if applications are more selective and only support a specific format or require external information to tell them what format to use or produce, then that's an indication you need separate types. There are past examples of both sorts of registrations - there was one recent type that was available in half a dozen different formats. Whereas the choice for CGM types many years ago was for separate types (3 distinct formats, as I recall). > If so, then there are 16 of these. So far. So? Names are cheap. > They all share the common property that the instance document conforms > to a specific YANG "restconf-media-type". This is a YANG extension and > can be used in any YANG module, so there could be 100s or 1000s of these > that will never get registered. This may argue for using internal labelling or perhaps a parameter to make these distinctions, but I fail to see what this has to do with types using different formats. I seriously doubt there are 100s or 1000s of +foos in play here. I also fail to see how this differs from the general situation surrounding XML or JSON based types in general. We let people define separate types when they need them but also have application/xml and application/json available. > If we could have 1 media type with a parameter, plus encoding, that would > be best. AFAICT that's an option. It's up to you, as designers of the base format, to decide on the best labelling system. And note that you could have two base types application/base+xml and application/base+json. Ned From nobody Fri Jun 17 22:35:47 2016 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 B599712D972 for ; Fri, 17 Jun 2016 22:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmVPPucYej92 for ; Fri, 17 Jun 2016 22:35:43 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D1D12D83F for ; Fri, 17 Jun 2016 22:35:43 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5I5ZMRQ028107 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 18 Jun 2016 05:35:42 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BDC22509B5; Sat, 18 Jun 2016 01:35:19 -0400 (EDT) To: Andy Bierman , Ned Freed References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> <01Q1HD8CXX7A00005M@mauve.mrochek.com> From: Sean Leonard Message-ID: <90591544-1553-7443-7d5e-6de0ef65d575@seantek.com> Date: Fri, 17 Jun 2016 22:35:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E5FD13700AB63CF49BC90D6" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Sat, 18 Jun 2016 05:35:42 +0000 (UTC) Archived-At: Cc: Mark Baker , Martin Bjorklund , Kent Watsen , Mark Nottingham , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 05:35:46 -0000 This is a multi-part message in MIME format. --------------1E5FD13700AB63CF49BC90D6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable I agree with Andy, based on my understanding of netconf/YANG. (NB: I am not heavily involved with YANG, but I did read through the=20 specifications in arriving at these conclusions. I am also not the media = types expert reviewer, but I have put a number of media types through.=20 Therefore my opinion is just that: an "informed opinion".) YANG works on "YANG Modules"; a YANG module is a hierarchy of nodes that = can include sub-modules. Each YANG module has its own vocabulary of=20 sorts. There are identifier strings for the modules and the nodes, so=20 that a YANG processor can figure out what the module is about, as long=20 as it knows that the data is YANG in the first place. There is "internal = labeling". YANG can be serialized as XML and JSON. There is also movement to=20 serialize it in CBOR. Based on this description, +xml, +json, and (eventually) +cbor are=20 appropriate. By having separate media type (suffixes) for these, clients = and servers can advertise the kinds of YANG they support. A constrained=20 device, for example, might only want to accept +cbor based YANG. Andy and Ned made two counterpoints: Andy: "If so, then there are 16 of these. So far. / They all share the=20 common property ... "restconf-media-type". This is a YANG extension and=20 can be used in any YANG module, so there could be 100s or 1000s of these = that will never get registered. / If we could have 1 media type with a=20 parameter, plus encoding, that would be best." Ned: So? Names are cheap. There are two points here: burden of registration and burden on=20 implementations. Names (media types) are indeed "cheap", in the sense that you just need=20 to fill out (properly) a registration template for each name, and=20 probably nobody is going to squat on anything after application/yang*=20 for things other than YANG/RESTCONF. (Note the "probably"--there is no=20 registration rule that says that YANG has dibs on everything starting=20 with application/yang* either.) However, you do have to fill out registration templates for each one. So = that would be 16+ registrations. And if indeed there are 100s or 1000s=20 of YANG module names, then you need 100s or 1000s of media type=20 registration templates. That seems like an unnecessary administrative=20 burden all around. Furthermore, the MIME/media type parser component has = to be aware of these "100s or 1000s of names", which means duplicated cod= e. The underlying engineering questions are, how are YANG modules named and = identified, and how does the set of YANG modules grow? Is all YANG data is self-describing (assuming that it's YANG) in all=20 formats, namely, that somewhere at the beginning, some identifier=20 declares the module type, such as "ietf-restconf:errors" (JSON) and=20 '' (XML)? If so, then we have an analogous situation to application/cms and=20 application/pkcs7-mime, namely, the identifier is baked into the=20 container format, so it only needs one media type, and a parameter that=20 repeats the identifier can be optional (namely, as a "hint" to a MIME=20 parser without cracking open the contents). If not, then either the parameter is required (to discriminate the=20 data), or you should consider registering multiple media types. Another point (mainly @Andy): Are you proposing a difference between=20 application/yang and application/yang-data? What is the difference, if=20 anything? Third point: If we go down the media type parameter route, can we reuse=20 an existing registry? I note that RFC 6020 establishes a "YANG Module=20 Names" registry=20 . = This already has nice neat ASCII strings to use in the "Prefix (Modules=20 Only)" column. How about considering using those? Sean On 6/17/2016 4:21 PM, Andy Bierman wrote: > Hi, > > > We would like to support the restconf-media-type even from different=20 > YANG modules: > > module A { > import ietf-restconf { prefix rc; } > rc:restconf-media-type "foo" { > container X { } > } > > } > > module B { > import ietf-restconf { prefix rc; } > rc:restconf-media-type "foo" { > container Y { } > } > > } > > > > We cannot control usage of this YANG extension and therefore we cannot = > prevent duplicates. > The current proposal will not work. > > 1 media type with a mandatory parameter "type" would work for what we=20 > need: > > application/yang-data+xml;type=3DA:foo > > application/yang-data+xml;type=3DB:foo > > application/yang-data+json;type=3DB:foo > > > Andy > > > On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed > wrote: > > > On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard > > wrote: > > > However, the other point has not been addressed. I do not see > a technical > > > reason or justification for registering 8 media types, when > > > application/yang; yangtype=3D"foo" (api, data, datastore, > errors, operation, > > > stream, patch, patch-status) suffices. Please address. > > > Each of those vocabularies are distinct languages with no - AFAIC= T - > > compatibility defined between them. Parameters aren't meant to ca= rry > > additional typing info, though are occasionally used this way - i= n a > > non-authoritative manner - for certain types of compound document= s > > (eg. media containers/codecs). That doesn't appear to apply here.= > > If so, then it sounds to me like distinct types are entirely > appropriate. > > Generally speaking we try not to have more than one name for a > given type - the > reasons for this are, I hope, obvious. If there's a need to carry > information > externally to further label the type or control it's handling, > that's what type > and disposition parameters are for. > > That said, we have made exceptions in cases where types are used > in contexts > where additional external parameterization isn't possible. This > has happened > several times, and it's why there's no hard rule requiring a > single name > for a type. > > Ned > > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types --------------1E5FD13700AB63CF49BC90D6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I agree with Andy, based on my understanding of netconf/YANG.

(NB: I am not heavily involved with YANG, but I did read through the specifications in arriving at these conclusions. I am also not the media types expert reviewer, but I have put a number of media types through. Therefore my opinion is just that: an "informed opinion".)

YANG works on "YANG Modules"; a YANG module is a hierarchy of nodes that can include sub-modules. Each YANG module has its own vocabulary of sorts. There are identifier strings for the modules and the nodes, so that a YANG processor can figure out what the module is about, as long as it knows that the data is YANG in the first place. There is "internal labeling".

YANG can be serialized as XML and JSON. There is also movement to serialize it in CBOR.

Based on this description, +xml, +json, and (eventually) +cbor are appropriate. By having separate media type (suffixes) for these, clients and servers can advertise the kinds of YANG they support. A constrained device, for example, might only want to accept +cbor based YANG.

Andy and Ned made two counterpoints:
Andy: "If so, then there are 16 of these. So far. / They all share the common property ... "restconf-media-type". This is a YANG extension and can be used in any YANG module, so there could be 100s or 1000s of these that will never get registered. / If we could have 1 media type with a parameter, plus encoding, that would be best." 
Ned: So? Names are cheap.

There are two points here: burden of registration and burden on implementations.
Names (media types) are indeed "cheap", in the sense that you just need to fill out (properly) a registration template for each name, and probably nobody is going to squat on anything after application/yang* for things other than YANG/RESTCONF. (Note the "probably"--there is no registration rule that says that YANG has dibs on everything starting with application/yang* either.)

However, you do have to fill out registration templates for each one. So that would be 16+ registrations. And if indeed there are 100s or 1000s of YANG module names, then you need 100s or 1000s of media type registration templates. That seems like an unnecessary administrative burden all around. Furthermore, the MIME/media type parser component has to be aware of these "100s or 1000s of names", which means duplicated code.

The underlying engineering questions are, how are YANG modules named and identified, and how does the set of YANG modules grow?

Is all YANG data is self-describing (assuming that it's YANG) in all formats, namely, that somewhere at the beginning, some identifier declares the module type, such as "ietf-restconf:errors" (JSON) and '<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">' (XML)?

If so, then we have an analogous situation to application/cms and application/pkcs7-mime, namely, the identifier is baked into the container format, so it only needs one media type, and a parameter that repeats the identifier can be optional (namely, as a "hint" to a MIME parser without cracking open the contents).

If not, then either the parameter is required (to discriminate the data), or you should consider registering multiple media types.


Another point (mainly @Andy): Are you proposing a difference between application/yang and application/yang-data? What is the difference, if anything?

Third point: If we go down the media type parameter route, can we reuse an existing registry? I note that RFC 6020 establishes a "YANG Module Names" registry <http://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml>. This already has nice neat ASCII strings to use in the "Prefix (Modules Only)" column. How about  considering using those?

Sean

On 6/17/2016 4:21 PM, Andy Bierman wrote:
Hi,


We would like to support the restconf-media-type even from different YANG modules:

module A {
   import ietf-restconf { prefix rc; }
   rc:restconf-media-type "foo" {
       container X { }
   }

}

module B {
   import ietf-restconf { prefix rc; }
   rc:restconf-media-type "foo" {
       container Y { }
   }

}



We cannot control usage of this YANG extension and therefore we cannot prevent duplicates.
The current proposal will not work.

1 media type with a mandatory parameter "type" would work for what we need:

    application/yang-data+xml;type=A:foo

    application/yang-data+xml;type=B:foo

    application/yang-data+json;type=B:foo


Andy


On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed <ned.freed@mrochek.com> wrote:
> On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
> > However, the other point has not been addressed. I do not see a technical
> > reason or justification for registering 8 media types, when
> > application/yang; yangtype="foo" (api, data, datastore, errors, operation,
> > stream, patch, patch-status) suffices. Please address.

> Each of those vocabularies are distinct languages with no - AFAICT -
> compatibility defined between them. Parameters aren't meant to carry
> additional typing info, though are occasionally used this way - in a
> non-authoritative manner - for certain types of compound documents
> (eg. media containers/codecs). That doesn't appear to apply here.

If so, then it sounds to me like distinct types are entirely appropriate.

Generally speaking we try not to have more than one name for a given type - the
reasons for this are, I hope, obvious. If there's a need to carry information
externally to further label the type or control it's handling, that's what type
and disposition parameters are for.

That said, we have made exceptions in cases where types are used in  contexts
where additional external parameterization isn't possible. This has happened
several times, and it's why there's no hard rule requiring a single name
for a type.

                                Ned




_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types


--------------1E5FD13700AB63CF49BC90D6-- From nobody Sat Jun 18 10:28:36 2016 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 BCAE912D7C6 for ; Sat, 18 Jun 2016 10:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aD0aQpLKW02 for ; Sat, 18 Jun 2016 10:28:31 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F29C12D7C1 for ; Sat, 18 Jun 2016 10:28:31 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5IHSA8B007406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 18 Jun 2016 17:28:31 GMT Received: by mail-vk0-x22c.google.com with SMTP id u64so152079204vkf.3 for ; Sat, 18 Jun 2016 10:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9/myXxx7SFaogm5ooAkBtFuM8JhU7izI0gu4GI+egus=; b=z/nEr46ehL0CBieu0n3LeE7ytxh1ITOZLYZv92/5PR8DZg2nOSu3i/PL1/rOxteDUM LqvdNgJGuf6QIiQUwp+TjDZ8QiWPYUqAau5HX/nhLD8VhhJhhJQ9m781Y+pnykaxTH+8 i4p0DRewAMfq8oMgP6yqOuLfIjhn/XhLTAGc9DVJeCxkM2UolfVfyR+6qyeSJQbfBJ+O 1jI/0nIzCLkE/2QSw2jngXlt5qfLpcIu7cksTFDywk2a4y9a8ziUlxTHEfD2YvIOljUO e/PNM8/fjQJaq5VthlWpvJnUofT/0hWTXs/h6r6NIg2KX6DbUfevtKm9GywDTSDhmIKE GVZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9/myXxx7SFaogm5ooAkBtFuM8JhU7izI0gu4GI+egus=; b=SwX8ZP6LGLVlEoJQ50csCNJ53kfQzDMC8nwQDK6ZZYGIgv6bSuPgOqMd8MqA/5KWJv GL9r5S9ES3KA2KFmY/DLlL5/T/Dc9p5Uqgnt/Z2ctUp6dRS9uYoIjmPNPK5vAcL8kSLi frzsFIZ4mpMKITzrUkeBIx8wCBX0VvAhuPs7PP78aU/FVG0cJgq45aqE0NfUd7k+iQsm fqDxOwUHDRNLkBTU4S0b2eqbMjb0YNbxag2z5a0UXmfdctITHEYYVkWcbQwxB7TW/GOu Lrq8U6DNyIQdpCOPzlwrCiKyhk7hKJC7IyTCPVdWmD3ZwTadGS5ICf6tJWK7e+IqCxB5 J6Zw== X-Gm-Message-State: ALyK8tKFvzl55jQ7pAzUfAsmIRR8JFwpz8qwZIgt8pGiHEEtA3Zb3kfcR3/4LaDpfLmAuGh0pEL5ZRN/dpealg== MIME-Version: 1.0 X-Received: by 10.31.201.194 with SMTP id z185mr3543333vkf.13.1466270890195; Sat, 18 Jun 2016 10:28:10 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Sat, 18 Jun 2016 10:28:10 -0700 (PDT) In-Reply-To: <01Q1IRWHT1OU00005M@mauve.mrochek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> <01Q1HD8CXX7A00005M@mauve.mrochek.com> <90591544-1553-7443-7d5e-6de0ef65d575@seantek.com> <01Q1IRWHT1OU00005M@mauve.mrochek.com> Date: Sat, 18 Jun 2016 10:28:10 -0700 Message-ID: From: Andy Bierman To: Ned Freed Content-Type: multipart/alternative; boundary=001a114dde848e1997053590cb16 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [IPv6:2620:0:2d0:201::1:73]); Sat, 18 Jun 2016 17:28:31 +0000 (UTC) Archived-At: Cc: Mark Baker , Martin Bjorklund , Kent Watsen , Mark Nottingham , Sean Leonard , Benoit Claise , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 17:28:34 -0000 --001a114dde848e1997053590cb16 Content-Type: text/plain; charset=UTF-8 Hi, Perhaps the simplest solution is to make the 16 registrations that are known at this time. The NETCONF WG is not actually chartered to support a generic solution for the restconf-media-type extension. The official list of RESTCONF media-types is not likely to grow. It is not always self-evident from the method and request URI which schema to use for the message-body. (e.g., operation vs. data vs. datastore have different schema contexts). The existing YANG media types in RFC 6020 do not apply. They refer to representations of YANG schema documents. The restconf-media-type is for representations of YANG instance data. Andy On Sat, Jun 18, 2016 at 9:32 AM, Ned Freed wrote: > YANG works on "YANG Modules"; a YANG module is a hierarchy of nodes that >> can include sub-modules. Each YANG module has its own vocabulary of >> sorts. There are identifier strings for the modules and the nodes, so >> that a YANG processor can figure out what the module is about, as long >> as it knows that the data is YANG in the first place. There is "internal >> labeling". >> > > Again, this seems very similar to the general situation with XML and JSON: > An effectively infinite number of specific vocabularies, each with > their own semantics, can be created. > > Our solution in this case has been to allow, but not require, the > specification > of separate types for different vocabularies, and to provide generic types > when > you don't want or need a specific type. > > Another alternative is to carry the information in a type parameter. This > has > been done several times as well, both as a mandatory parameter (appropriate > when the type cannot be immediately deduced from the content), or optional > (either as a hint or as an alternate label when the label in the content > itself > is optional). > > Given the incredibly wide diversity of XML-based and JSON-based types > a parameter didn't seem apropriate. But YANG is much more limited in scope. > > YANG can be serialized as XML and JSON. There is also movement to >> serialize it in CBOR. >> > > Based on this description, +xml, +json, and (eventually) +cbor are >> appropriate. By having separate media type (suffixes) for these, clients >> and servers can advertise the kinds of YANG they support. A constrained >> device, for example, might only want to accept +cbor based YANG. >> > > This seems reasonable. > > Andy and Ned made two counterpoints: >> Andy: "If so, then there are 16 of these. So far. / They all share the >> common property ... "restconf-media-type". This is a YANG extension and >> can be used in any YANG module, so there could be 100s or 1000s of these >> that will never get registered. / If we could have 1 media type with a >> parameter, plus encoding, that would be best." >> > > Ned: So? Names are cheap. >> > > You've missed my point, it seems, which was that the possibility of having > many > types is not in an of itself an argument against requiring separate type > specifications. Nothing more. > > There are two points here: burden of registration and burden on >> implementations. >> > > Names (media types) are indeed "cheap", in the sense that you just need >> to fill out (properly) a registration template for each name, and >> probably nobody is going to squat on anything after application/yang* >> for things other than YANG/RESTCONF. (Note the "probably"--there is no >> registration rule that says that YANG has dibs on everything starting >> with application/yang* either.) >> > > However, you do have to fill out registration templates for each one. So >> that would be 16+ registrations. And if indeed there are 100s or 1000s >> of YANG module names, then you need 100s or 1000s of media type >> registration templates. That seems like an unnecessary administrative >> burden all around. Furthermore, the MIME/media type parser component has >> to be aware of these "100s or 1000s of names", which means duplicated >> code. >> > > That's assuming current process rules. If a situation actually arose where > there was a demonstrable need to register 1000s of separate types on an > ongoing > basis, I have no doubt it would also make sense to define a streamlined > process > of some sort. > > As for parser awareness, such a massive set of registrations would > certainly > include some sort of naming rule, and while I've learned not to expect too > much > from developers, I think special casing such a convention would likely be > within the capabilites of most. > > All that said, and speaking entirely as an observer, I'm not seeing the > case > for separate types here. But that doesn't mean there isn't one to be made. > > The underlying engineering questions are, how are YANG modules named and >> identified, and how does the set of YANG modules grow? >> > > Exactly! And those are questions for the folks writing this specification. > > The type registration and review process provides a set of services that > may > (or may not) be of use here. And to the extent there are limitations on > those > services, it's important to recogize what those are so appropriate use can > be > made of what's available. > > But that's as far as it goes. > > Is all YANG data is self-describing (assuming that it's YANG) in all >> formats, namely, that somewhere at the beginning, some identifier >> declares the module type, such as "ietf-restconf:errors" (JSON) and >> '' (XML)? >> > > If so, then we have an analogous situation to application/cms and >> application/pkcs7-mime, namely, the identifier is baked into the >> container format, so it only needs one media type, and a parameter that >> repeats the identifier can be optional (namely, as a "hint" to a MIME >> parser without cracking open the contents). >> > > Right again. > > If not, then either the parameter is required (to discriminate the >> data), or you should consider registering multiple media types. >> > > Another point (mainly @Andy): Are you proposing a difference between >> application/yang and application/yang-data? What is the difference, if >> anything? >> > > Third point: If we go down the media type parameter route, can we reuse >> an existing registry? I note that RFC 6020 establishes a "YANG Module >> Names" registry >> . >> This already has nice neat ASCII strings to use in the "Prefix (Modules >> Only)" column. How about considering using those? >> > > Reusing an existing registry makes all sorts of sense IMO. > > Ned > --001a114dde848e1997053590cb16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Perhaps the simplest solution is to= make the 16 registrations that are known at this time.

The NETCONF WG is not actually chartered to support a generic solutio= n for
the restconf-media-type extension.=C2=A0 The official list = of RESTCONF media-types
is not likely to grow.

It is not always self-evident from the method and request URI which = schema to use
for the message-body. (e.g., operation vs. data vs.= datastore have different schema contexts).

The ex= isting YANG media types in RFC 6020 do not apply.
They refer to r= epresentations of YANG schema documents.
The restconf-media-type = is for representations of YANG instance data.


=
Andy



On Sat, Jun 18, 2016 at 9:32 AM, Ne= d Freed <ned.freed@mrochek.com> wrote:
YANG works on "YANG Modules"; a YANG module is a hierarchy of nod= es that
can include sub-modules. Each YANG module has its own vocabulary of
sorts. There are identifier strings for the modules and the nodes, so
that a YANG processor can figure out what the module is about, as long
as it knows that the data is YANG in the first place. There is "intern= al
labeling".

Again, this seems very similar to the general situation with XML and JSON:<= br> An effectively infinite number of specific vocabularies, each with
their own semantics, can be created.

Our solution in this case has been to allow, but not require, the specifica= tion
of separate types for different vocabularies, and to provide generic types = when
you don't want or need a specific type.

Another alternative is to carry the information in a type parameter. This h= as
been done several times as well, both as a mandatory parameter (appropriate=
when the type cannot be immediately deduced from the content), or optional<= br> (either as a hint or as an alternate label when the label in the content it= self
is optional).

Given the incredibly wide diversity of XML-based and JSON-based types
a parameter didn't seem apropriate. But YANG is much more limited in sc= ope.

YANG can be serialized as XML and JSON. There is also movement to
serialize it in CBOR.

Based on this description, +xml, +json, and (eventually) +cbor are
appropriate. By having separate media type (suffixes) for these, clients and servers can advertise the kinds of YANG they support. A constrained
device, for example, might only want to accept +cbor based YANG.

This seems reasonable.

Andy and Ned made two counterpoints:
Andy: "If so, then there are 16 of these. So far. / They all share the=
common property ... "restconf-media-type". This is a YANG extensi= on and
can be used in any YANG module, so there could be 100s or 1000s of these that will never get registered. / If we could have 1 media type with a
parameter, plus encoding, that would be best."

Ned: So? Names are cheap.

You've missed my point, it seems, which was that the possibility of hav= ing many
types is not in an of itself an argument against requiring separate type specifications. Nothing more.

There are two points here: burden of registration and burden on
implementations.

Names (media types) are indeed "cheap", in the sense that you jus= t need
to fill out (properly) a registration template for each name, and
probably nobody is going to squat on anything after application/yang*
for things other than YANG/RESTCONF. (Note the "probably"--there = is no
registration rule that says that YANG has dibs on everything starting
with application/yang* either.)

However, you do have to fill out registration templates for each one. So that would be 16+ registrations. And if indeed there are 100s or 1000s
of YANG module names, then you need 100s or 1000s of media type
registration templates. That seems like an unnecessary administrative
burden all around. Furthermore, the MIME/media type parser component has to be aware of these "100s or 1000s of names", which means duplic= ated code.

That's assuming current process rules. If a situation actually arose wh= ere
there was a demonstrable need to register 1000s of separate types on an ong= oing
basis, I have no doubt it would also make sense to define a streamlined pro= cess
of some sort.

As for parser awareness, such a massive set of registrations would certainl= y
include some sort of naming rule, and while I've learned not to expect = too much
from developers, I think special casing such a convention would likely be within the capabilites of most.

All that said, and speaking entirely as an observer, I'm not seeing the= case
for separate types here. But that doesn't mean there isn't one to b= e made.

The underlying engineering questions are, how are YANG modules named and identified, and how does the set of YANG modules grow?

Exactly! And those are questions for the folks writing this specification.<= br>
The type registration and review process provides a set of services that ma= y
(or may not) be of use here. And to the extent there are limitations on tho= se
services, it's important to recogize what those are so appropriate use = can be
made of what's available.

But that's as far as it goes.

Is all YANG data is self-describing (assuming that it's YANG) in all formats, namely, that somewhere at the beginning, some identifier
declares the module type, such as "ietf-restconf:errors" (JSON) a= nd
'<errors xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-restconf&quo= t;>' (XML)?

If so, then we have an analogous situation to application/cms and
application/pkcs7-mime, namely, the identifier is baked into the
container format, so it only needs one media type, and a parameter that
repeats the identifier can be optional (namely, as a "hint" to a = MIME
parser without cracking open the contents).

Right again.

If not, then either the parameter is required (to discriminate the
data), or you should consider registering multiple media types.

Another point (mainly @Andy): Are you proposing a difference between
application/yang and application/yang-data? What is the difference, if
anything?

Third point: If we go down the media type parameter route, can we reuse
an existing registry? I note that RFC 6020 establishes a "YANG Module<= br> Names" registry
<http://www.iana.org/assignm= ents/yang-parameters/yang-parameters.xhtml>.
This already has nice neat ASCII strings to use in the "Prefix (Module= s
Only)" column. How about=C2=A0 considering using those?

Reusing an existing registry makes all sorts of sense IMO.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

--001a114dde848e1997053590cb16-- From nobody Sat Jun 18 15:48:59 2016 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 3CFEE12DA4D for ; Sat, 18 Jun 2016 15:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-88266i5MtX for ; Sat, 18 Jun 2016 15:48:56 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8504012D121 for ; Sat, 18 Jun 2016 15:48:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5IMmZI2029006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 18 Jun 2016 22:48:55 GMT Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B1EBC509B5 for ; Sat, 18 Jun 2016 18:48:34 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 18 Jun 2016 15:48:37 -0700 To: media-types@iana.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Sat, 18 Jun 2016 22:48:55 +0000 (UTC) Archived-At: Subject: [media-types] Is dot (.) basically reserved? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 22:48:58 -0000 Is it fair to say that the dot (.) is basically a reserved character as = a delimiter for facet names in media types, but does that mean it = can=E2=80=99t ever be used? Suppose that I want to register a media type for X.690-encoded values = (commonly known as BER, CER, DER) as a whole. (I am not actually going = to do this, at least not for the time being. Working on other things...) application/x.690 makes sense. (application/ber etc. do not make sense, = because BER / CER / DER are basically the same. Similarly = application/asn.1 does not make sense because this is an encoding of = ASN.1, it=E2=80=99s not generic to ASN.1 as a whole.) However, x. is reserved specifically according to Section 3.4. There is = also Section 4.2. What about application/itu.x.690 ? (Or application/itu-t.x.690?) = Basically this would call for registering =E2=80=9Citu=E2=80=9D (or = =E2=80=9Citu-t=E2=80=9D) as a facet, which requires Standards Action. = Would subsequent dots then be allowed? Thanks, Sean= From nobody Sat Jun 18 18:02:43 2016 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 3BE1C12DB36 for ; Sat, 18 Jun 2016 18:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ8oLaDoDo7u for ; Sat, 18 Jun 2016 18:02:39 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EAF12D60E for ; Sat, 18 Jun 2016 18:02:39 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5J12IB1026749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 19 Jun 2016 01:02:39 GMT Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in2.mxes.net (Postfix) with ESMTP id 0C9ED2FD7AF for ; Sat, 18 Jun 2016 20:46:21 -0400 (EDT) Received: from [192.168.1.109] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CA10C22E253; Sat, 18 Jun 2016 20:45:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Sun, 19 Jun 2016 10:45:37 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <948288A7-3B88-44F3-815D-DEC2217D9F86@mnot.net> References: To: Sean Leonard X-Mailer: Apple Mail (2.3124) X-Greylist: Delayed for 00:15:57 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Sun, 19 Jun 2016 01:02:39 +0000 (UTC) Archived-At: Cc: media-types@iana.org Subject: Re: [media-types] Is dot (.) basically reserved? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 19 Jun 2016 01:02:41 -0000 > On 19 Jun 2016, at 8:48 AM, Sean Leonard wrote: >=20 > Is it fair to say that the dot (.) is basically a reserved character = as a delimiter for facet names in media types, but does that mean it = can=E2=80=99t ever be used? I think this question is the heart of the yang discussion. My reading is = that it effectively is in standards tree registrations (since = registrations in other trees will already have a dot to denote the facet = and therefore registration tree), but this isn't made explicit AFAICT. >=20 > Suppose that I want to register a media type for X.690-encoded values = (commonly known as BER, CER, DER) as a whole. (I am not actually going = to do this, at least not for the time being. Working on other things...) >=20 > application/x.690 makes sense. (application/ber etc. do not make = sense, because BER / CER / DER are basically the same. Similarly = application/asn.1 does not make sense because this is an encoding of = ASN.1, it=E2=80=99s not generic to ASN.1 as a whole.) >=20 > However, x. is reserved specifically according to Section 3.4. There = is also Section 4.2. >=20 > What about application/itu.x.690 ? (Or application/itu-t.x.690?) = Basically this would call for registering =E2=80=9Citu=E2=80=9D (or = =E2=80=9Citu-t=E2=80=9D) as a facet, which requires Standards Action. = Would subsequent dots then be allowed? I see no reason to disallow them when there's already a facet -- unless = that facet reserves them for some reason. >=20 > Thanks, >=20 > Sean > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jun 19 11:44:34 2016 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 5175512D6A9 for ; Sun, 19 Jun 2016 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZZc4-rOc9vB for ; Sun, 19 Jun 2016 11:44:32 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E4312D6A7 for ; Sun, 19 Jun 2016 11:44:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5JIiC3P024965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 19 Jun 2016 18:44:32 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1K9VZB56O004RFC@mauve.mrochek.com> for media-types@iana.org; Sun, 19 Jun 2016 11:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1466361549; bh=eacLibkADoUDhFVi3acdVN11iBohn4Z43xQRsquSjfI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=UhpwYrwmWO0UXZ+Dq3ffyarg+p4bu5xvpiccbfduIBh+AI0wtWWJ1/rOFsZeVCtvL QSUMfXqwJASw28Av2LMLqovCDbamLy+Di0KEOvrds/EAjZS1A3rjlDeHMFjbfa0Q+n hHJntYeSZ534Rs6qT4xlygurEZLuJXYpTKXyi/Fs= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q17NM7WHC000005M@mauve.mrochek.com>; Sun, 19 Jun 2016 11:39:08 -0700 (PDT) Message-id: <01Q1K9VYEE0A00005M@mauve.mrochek.com> Date: Sun, 19 Jun 2016 11:35:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 18 Jun 2016 15:48:37 -0700" References: To: Sean Leonard X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Sun, 19 Jun 2016 18:44:32 +0000 (UTC) Archived-At: Cc: media-types@iana.org Subject: Re: [media-types] Is dot (.) basically reserved? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 19 Jun 2016 18:44:33 -0000 > Is it fair to say that the dot (.) is basically a reserved character as a > delimiter for facet names in media types, but does that mean it can’t ever be > used? It can't be used in unfaceted names, because using it would make them a faceted name. It can, however, be used in facted names, since the second and subsequent occcurances have no special meaning. Such are the vagarities of the naming scheme. > Suppose that I want to register a media type for X.690-encoded values > (commonly known as BER, CER, DER) as a whole. (I am not actually going to do > this, at least not for the time being. Working on other things...) > application/x.690 makes sense. (application/ber etc. do not make sense, > because BER / CER / DER are basically the same. Similarly application/asn.1 > does not make sense because this is an encoding of ASN.1, it’s not generic to > ASN.1 as a whole.) Sure does, but you can't register it. You have to make do with something like x-690. > However, x. is reserved specifically according to Section 3.4. There is also > Section 4.2. Exactly. > What about application/itu.x.690 ? (Or application/itu-t.x.690?) Basically > this would call for registering “itu†(or “itu-tâ€) as a facet, which > requires Standards Action. Would subsequent dots then be allowed? Nope, won't work. There's no itu facet. Now, you can argue that there should be a std. facet, so you can have std.x.690. That was briefly discussed during the last revision process as I recall, but there was no consensus to define it. Ned From nobody Sun Jun 19 13:01:24 2016 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 9FBB112D7C6 for ; Sun, 19 Jun 2016 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K99lTK5BXkuf for ; Sun, 19 Jun 2016 13:01:21 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBAB12D79D for ; Sun, 19 Jun 2016 13:01:20 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5JK0xbH010052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 19 Jun 2016 20:01:20 GMT Received: from aclermont-ferrand-654-1-533-1.w90-4.abo.wanadoo.fr ([90.4.249.1] helo=w3.org) by raoul.w3.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bEitt-000BNL-MB; Sun, 19 Jun 2016 20:00:58 +0000 Date: Sun, 19 Jun 2016 16:00:55 -0400 From: "Eric Prud'hommeaux" To: Michael Dolan Message-ID: <20160619200053.GG23703@w3.org> References: <5762B4A3.8080408@w3.org> <20160616200724.GC23703@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [IPv6:2620:0:2d0:201::1:71]); Sun, 19 Jun 2016 20:01:20 +0000 (UTC) Archived-At: Cc: Philippe Le Hegaret , Timed Text Working Group , "media-types@iana.org" Subject: Re: [media-types] Update to media type "application/ttml+xml" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 19 Jun 2016 20:01:24 -0000 * Michael Dolan [2016-06-17 23:57+0000] > Hi Eric- > > Thanks. I think I agree with your comment about "first order". It's either right or it isn't. And what a robust decoder may wish to do if it detects that it is wrong (and also figures out what it really is) should be out of scope. > > I'm not sure I follow your comment about the URL. TTML2 Table 6-3 needs the text that precedes it to understand it. Maybe I don't understand your comment. Boring editorial point that you should include the link in visible text so it shows up in the registration. Otherwise the test/plain reg just says "see TTML2 Profile Combination" without a link. I get your point about referencing the previous paragraph rather than just the table labeled "TTML2 Profile Combination". > Thanks, > Mike > > -----Original Message----- > From: Eric Prud'hommeaux [mailto:eric@w3.org] > Sent: Thursday, June 16, 2016 1:07 PM > To: Michael Dolan > Cc: media-types@iana.org; Timed Text Working Group ; Philippe Le Hegaret > Subject: Re: [media-types] Update to media type "application/ttml+xml" > > * Philippe Le Hegaret [2016-06-16 10:16-0400] > > The W3C Timed Text Working Group would like to update the media type > > "application/ttml+xml" as follows. Comments are welcome. > > > > It updates the media type, "application/ttml+xml" to add a new > > parameter, codecs. All other provisions of the media type > > specification remain the same. This supercedes the initial > > registration information in TTML 1.0 Second Edition. > > > > Text copied below but see also the original text at: > > > > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediat > > ype > > > > [[ > > > > Type name: > > > > application > > Subtype name: > > > ttml+xml > > Required parameters: > > > > None. > > Optional parameters: > > > > charset > > > > If specified, the charset parameter must match the XML > > encoding declaration, or if absent, the actual encoding. See also > > Encoding Considerations below. > > profile > > > > The document profile of a TTMLDocument Instance may be > > specified using an optional profile parameter, which, if specified, > > the value of which must adhere to the syntax and semantics of > > ttp:profile parameter defined by TTML 1.0 Second Edition, Section > > 6.2.8 ttp:profile of the published specification. > > > > codecs > > > > The optional codecs parameter provides a short form version of > > the profile parameter with multiple-profile combinatorial capability. > > If a short > > (4-character) form of a profile is registered in the TTML Profile > > Registry, it is recommended that this codecs parameter be used and not > > the profile parameter. The nominal value of this parameter is a single > > 4 character code from the registry. > > > > Additionally, applications using the entries in the registry > > are encouraged to adopt the following combination syntax: > > > > Employ two combination operators, '+' (AND) and '|' (OR), > > which may be used to specify, respectively, that multiple processor > > profiles apply > > (simultaneously) or that any processor profile of a list of profiles > > may apply individually. If both operators are used in a codecs value, > > then the '+' operator has precedence. > > > > The example: "A+B|C+D|E" states that a TTML processor that > > implements any one of A+B or C+D or E processor profiles satisfies, at > > first order, the requirements to fetch and begin decode/processing of > > a TTML > > PLH indicated that "at first order" is something like an initial claim about the embedded codecs. Is it the intention that there be some sort of recovery if that initial claim is incorrect? What should the processor do if the advertised codec is ogg and the actual codec is xvid? If you strike "at first order", I think you could avoid having to define the behavior in the event of invalid parameters. > > > > document, where X+Y means that both X and Y processor profiles must be > > supported, and X|Y means that either X or Y processor profile must be > > supported. > > > > For more information about processor profile combination, see > > TTML2 Profile Combination. > > "TTML2 Profile Comination" has no URL in the reg. The hyptertext version links to > https://www.w3.org/TR/ttml2/#profile-attribute-processorProfileCombination > propose instead link to > https://www.w3.org/TR/ttml2/#processor-profile-combination-table > and embedding that link in ()s in the text. > > > > Encoding considerations: > > > > Same for application/xml, except constrained to either UTF-8 or UTF-16. > > See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose of > > filling out the IANA Application for Media Type > > (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies. > > Security considerations: > > > > As with other XML types and as noted in IETF RFC 3023, XML Media > > Types, Section 10, repeated expansion of maliciously constructed XML > > entities can be used to consume large amounts of memory, which may > > cause XML processors in constrained environments to fail. > > > > In addition, because of the extensibility features for TTML and of > > XML in general, it is possible that "application/ttml+xml" may > > describe content that has security implications beyond those described > > here. However, TTML does not provide for any sort of active or > > executable content, and if the processor follows only the normative > > semantics of the published specification, this content will be outside > > TTML namespaces and may be ignored. Only in the case where the > > processor recognizes and processes the additional content, or where > > further processing of that content is dispatched to other processors, > > would security issues potentially arise. And in that case, they would > > fall outside the domain of this registration document. > > > > Although not prohibited, there are no expectations that XML > > signatures or encryption would normally be employed. > > Interoperability considerations: > > > > The published specification describes processing semantics that > > dictate behavior that must be followed when dealing with, among other > > things, unrecognized elements and attributes, both in TTML namespaces > > and in other namespaces. > > > > Because TTML is extensible, conformant "application/ttml+xml" > > processors may expect (and enforce) that content received is > > well-formed XML, but it cannot be guaranteed that the content is valid > > to a particular DTD or Schema or that the processor will recognize all > > of the elements and attributes in the document. > > Published specification: > > > > This media type registration is extracted from the TTML Profile > > Registry. > > Applications that use this media type: > > > > TTML is used in the television industry for the purpose of > > authoring, transcoding and exchanging timed text information and for > > delivering captions, subtitles, and other metadata for television > > material repurposed for the Web or, more generally, the Internet. > > > > There is partial and full support of TTML in components used by > > several Web browsers plugins, and in a number of caption authoring tools. > > Additional information: > > > > Magic number(s): > > File extension(s): > > > > .ttml > > Macintosh file type code(s): > > > > "TTML" > > Fragment identifiers: > > > > For documents labeled as application/ttml+xml, the fragment > > identifier notation is intended to be used with xml:id attributes, as > > described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) > > specification. > > > > Person & email address to contact for further information: > > > > Timed Text Working Group (public-tt@w3.org) Intended usage: > > > > COMMON > > Restrictions on usage: > > > > None > > Author: > > > > The published specification is a work product of the World Wide > > Web Consortium's Timed Text (TT) Working Group. > > Change controller: > > > > The W3C has change control over this specification. > > ]] > > https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediat > > ype > > > > Thank you, > > > > Philippe > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > -- > -ericP > > office: +1.617.599.3509 > mobile: +33.6.80.80.35.59 > > (eric@w3.org) > Feel free to forward this message to any list for any purpose other than email address distribution. > > There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper. -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper. From nobody Mon Jun 20 01:16:18 2016 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 992F912D794 for ; Sat, 18 Jun 2016 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYtLrX-X9Woq for ; Sat, 18 Jun 2016 09:58:52 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150D112D78B for ; Sat, 18 Jun 2016 09:58:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5IGwVab005662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 18 Jun 2016 16:58:51 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1IRWJWG28000ES2@mauve.mrochek.com> for media-types@iana.org; Sat, 18 Jun 2016 09:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1466268805; bh=XkgR3DwKCgUA3ZOJlbtYIaYnKiV5Jt1zZ9z1znqpoc4=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=KyWrc8uIYKE5kH+KBf/6rgrgr69n/DvMJD6jY1LsyEsFEWbqF4YVbXvqJlW4Vyvl2 u33RjJbkzWuD1JPHLp6iRm4IIkMCRTd3jhKgrp+v8jJgUVhE6+ZHGvpTXgESTKuygq HXXTptrx/5YJLh6z/vsOerr+J5jejay9HreJ/7Xw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q17NM7WHC000005M@mauve.mrochek.com>; Sat, 18 Jun 2016 09:53:23 -0700 (PDT) Message-id: <01Q1IRWHT1OU00005M@mauve.mrochek.com> Date: Sat, 18 Jun 2016 09:32:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 Jun 2016 22:35:50 -0700" <90591544-1553-7443-7d5e-6de0ef65d575@seantek.com> References: <0B7A073C-5F90-4793-855F-77334327A254@mnot.net> <6c78740d-70be-abab-4df2-58e4c4abb873@seantek.com> <8330e51a-8f62-aad1-2d20-2c9c7db811f1@cisco.com> <21851603-b224-2850-1ee1-a03ff4f350df@seantek.com> <01Q1HD8CXX7A00005M@mauve.mrochek.com> <90591544-1553-7443-7d5e-6de0ef65d575@seantek.com> To: Sean Leonard X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Sat, 18 Jun 2016 16:58:51 +0000 (UTC) Archived-At: X-Mailman-Approved-At: Mon, 20 Jun 2016 01:16:17 -0700 Cc: Mark Baker , Martin Bjorklund , Ned Freed , Andy Bierman , Mark Nottingham , Benoit Claise , Kent Watsen , "media-types@iana.org" , "netconf-chairs@tools.ietf.org" Subject: Re: [media-types] Subtypes and registration trees X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 16:58:53 -0000 > YANG works on "YANG Modules"; a YANG module is a hierarchy of nodes that > can include sub-modules. Each YANG module has its own vocabulary of > sorts. There are identifier strings for the modules and the nodes, so > that a YANG processor can figure out what the module is about, as long > as it knows that the data is YANG in the first place. There is "internal > labeling". Again, this seems very similar to the general situation with XML and JSON: An effectively infinite number of specific vocabularies, each with their own semantics, can be created. Our solution in this case has been to allow, but not require, the specification of separate types for different vocabularies, and to provide generic types when you don't want or need a specific type. Another alternative is to carry the information in a type parameter. This has been done several times as well, both as a mandatory parameter (appropriate when the type cannot be immediately deduced from the content), or optional (either as a hint or as an alternate label when the label in the content itself is optional). Given the incredibly wide diversity of XML-based and JSON-based types a parameter didn't seem apropriate. But YANG is much more limited in scope. > YANG can be serialized as XML and JSON. There is also movement to > serialize it in CBOR. > Based on this description, +xml, +json, and (eventually) +cbor are > appropriate. By having separate media type (suffixes) for these, clients > and servers can advertise the kinds of YANG they support. A constrained > device, for example, might only want to accept +cbor based YANG. This seems reasonable. > Andy and Ned made two counterpoints: > Andy: "If so, then there are 16 of these. So far. / They all share the > common property ... "restconf-media-type". This is a YANG extension and > can be used in any YANG module, so there could be 100s or 1000s of these > that will never get registered. / If we could have 1 media type with a > parameter, plus encoding, that would be best." > Ned: So? Names are cheap. You've missed my point, it seems, which was that the possibility of having many types is not in an of itself an argument against requiring separate type specifications. Nothing more. > There are two points here: burden of registration and burden on > implementations. > Names (media types) are indeed "cheap", in the sense that you just need > to fill out (properly) a registration template for each name, and > probably nobody is going to squat on anything after application/yang* > for things other than YANG/RESTCONF. (Note the "probably"--there is no > registration rule that says that YANG has dibs on everything starting > with application/yang* either.) > However, you do have to fill out registration templates for each one. So > that would be 16+ registrations. And if indeed there are 100s or 1000s > of YANG module names, then you need 100s or 1000s of media type > registration templates. That seems like an unnecessary administrative > burden all around. Furthermore, the MIME/media type parser component has > to be aware of these "100s or 1000s of names", which means duplicated code. That's assuming current process rules. If a situation actually arose where there was a demonstrable need to register 1000s of separate types on an ongoing basis, I have no doubt it would also make sense to define a streamlined process of some sort. As for parser awareness, such a massive set of registrations would certainly include some sort of naming rule, and while I've learned not to expect too much from developers, I think special casing such a convention would likely be within the capabilites of most. All that said, and speaking entirely as an observer, I'm not seeing the case for separate types here. But that doesn't mean there isn't one to be made. > The underlying engineering questions are, how are YANG modules named and > identified, and how does the set of YANG modules grow? Exactly! And those are questions for the folks writing this specification. The type registration and review process provides a set of services that may (or may not) be of use here. And to the extent there are limitations on those services, it's important to recogize what those are so appropriate use can be made of what's available. But that's as far as it goes. > Is all YANG data is self-describing (assuming that it's YANG) in all > formats, namely, that somewhere at the beginning, some identifier > declares the module type, such as "ietf-restconf:errors" (JSON) and > '' (XML)? > If so, then we have an analogous situation to application/cms and > application/pkcs7-mime, namely, the identifier is baked into the > container format, so it only needs one media type, and a parameter that > repeats the identifier can be optional (namely, as a "hint" to a MIME > parser without cracking open the contents). Right again. > If not, then either the parameter is required (to discriminate the > data), or you should consider registering multiple media types. > Another point (mainly @Andy): Are you proposing a difference between > application/yang and application/yang-data? What is the difference, if > anything? > Third point: If we go down the media type parameter route, can we reuse > an existing registry? I note that RFC 6020 establishes a "YANG Module > Names" registry > . > This already has nice neat ASCII strings to use in the "Prefix (Modules > Only)" column. How about considering using those? Reusing an existing registry makes all sorts of sense IMO. Ned From nobody Mon Jun 20 15:16:55 2016 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 8CD9512DA8E for ; Mon, 20 Jun 2016 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xbj7xcQFDum for ; Mon, 20 Jun 2016 15:16:52 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D2812DA80 for ; Mon, 20 Jun 2016 15:16:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5KMGVa8017074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 20 Jun 2016 22:16:52 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1LVLJTP0G00307T@mauve.mrochek.com> for media-types@iana.org; Mon, 20 Jun 2016 15:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1466460688; bh=X0A/GFHCU/PwvjSQPNSRe1oWKv6Vico1HUUd1BI52uM=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=JCrwc2qF6tzQoHgscUOsLk+jIlKWNXk/rpCbP+8on+qB5xJl4nYpxkIGC9iYdXVuK AjFIuIOCibHxBKHRGgZwaiabw+M2yV3cPROMExwSAw8V77BUWhApeXoIeyxr+oHZ7m WSbCwofND2rJ8hYsa4PAL0bjxZqTzuYxlERvRHPY= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1LMPRIMLS00005M@mauve.mrochek.com>; Mon, 20 Jun 2016 15:11:26 -0700 (PDT) Message-id: <01Q1LVLI99GI00005M@mauve.mrochek.com> Date: Mon, 20 Jun 2016 15:06:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 19 Jun 2016 10:45:37 +1000" <948288A7-3B88-44F3-815D-DEC2217D9F86@mnot.net> References: <948288A7-3B88-44F3-815D-DEC2217D9F86@mnot.net> To: Mark Nottingham X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Mon, 20 Jun 2016 22:16:52 +0000 (UTC) Archived-At: Cc: media-types@iana.org, Sean Leonard Subject: Re: [media-types] Is dot (.) basically reserved? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 22:16:53 -0000 > > On 19 Jun 2016, at 8:48 AM, Sean Leonard wrote: > > > > Is it fair to say that the dot (.) is basically a reserved character as a > > delimiter for facet names in media types, but does that mean it can’t ever be > > used? > I think this question is the heart of the yang discussion. My reading is that > it effectively is in standards tree registrations (since registrations in other > trees will already have a dot to denote the facet and therefore registration > tree), but this isn't made explicit AFAICT. RFC 6838 section 3.1, fourth paragraph: Media types in the standards tree MUST NOT have faceted names, unless they are grandfathered in using the process described in Appendix A. > > Suppose that I want to register a media type for X.690-encoded values (commonly known as BER, CER, DER) as a whole. (I am not actually going to do this, at least not for the time being. Working on other things...) > > > > application/x.690 makes sense. (application/ber etc. do not make sense, because BER / CER / DER are basically the same. Similarly application/asn.1 does not make sense because this is an encoding of ASN.1, it’s not generic to ASN.1 as a whole.) > > > > However, x. is reserved specifically according to Section 3.4. There is also Section 4.2. > > > > What about application/itu.x.690 ? (Or application/itu-t.x.690?) Basically > > this would call for registering “itu†(or “itu-tâ€) as a facet, which > > requires Standards Action. Would subsequent dots then be allowed? > I see no reason to disallow them when there's already a facet -- unless that > facet reserves them for some reason. Creating additional facets in order to delegate a portion of the tree to another standards body (like the ITU) is the main reason why there's a process to register additional facets; see RFC 6838 section 3.5. But of course there's an implicit requirement that the ITU be willing and able to set up it's own administrative process for the new tree. So far nobody has said they want to do that. Ned From nobody Tue Jun 21 07:31:30 2016 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 1C91512B060 for ; Tue, 21 Jun 2016 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EXWSEdpfvwJ for ; Tue, 21 Jun 2016 07:31:25 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D21B12D0C5 for ; Tue, 21 Jun 2016 07:31:24 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5LEV3P4023560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 21 Jun 2016 14:31:23 GMT Received: by mail-vk0-x22a.google.com with SMTP id u64so22614329vkf.3 for ; Tue, 21 Jun 2016 07:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=I3n7u1sWZiq0a4FmvgH6vwAG1qDF+H0UMMKtOtE5bZU=; b=O+hhmWuUKKmSVvlwoWEluCbcWyx4NozVHp6F2V2heM07r9XJR2UcDaK4PD0mtME1P2 0TWd3NyUe5FaXNzcxSt2VyrplAALrckEvxA0o2tfZfHlrLS9zALMdBW4DNZNTWPg/KQ1 jGNMOSE0A7aonVnQL/XEaSt3r6oj+fSQlFWXbF9zud3SYKBSmVSk1JcKEtOzpkYs+Wut dCs3Fn8U0BQ/NxUri502rff6dT7j2eVA/vKgr+QwaUIDTuzwU2Mz89XvcbHoZgaWB5Qv Fvox0VixqnVOoXZgQ3ipFtFW7icx4VueFtGf1/xn3qakcYS1uDtDJeJwDFWp4ridndcO YCAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=I3n7u1sWZiq0a4FmvgH6vwAG1qDF+H0UMMKtOtE5bZU=; b=E3BVAhORlxN3JxcbbSKY8Hd+LQG3eGVAcdPaSIN2ZudMowbtZALkvspuNCLnZxWzRm CJ5THteN9MKA3dWdPUQ29F0L2aVo14xpRen/T5pXRsWtsh/nSLLx2LVNK7OY12HzDyOl csuF43odVsnh1uRWfhOam1bvqay4UVwwy6LLCrrRBylmjGWVUZT3Z3vwL2SSNPxQuuED W7VDLF3kHMQrsB3xk4XPmFShpKmAqHM3BOYOSnTRPynmsqIfzK1j3AQKY932BA2kmRx9 nl/906NeQLucgLLfgiL3GTZ3kYgivTv0X6wLYa84zHwfahMGn4nsLIh9bTJeJqVTrE7O Aosg== X-Gm-Message-State: ALyK8tKi/9y04rIwwviIXUxSwpi5ei7UyFDnZPKZzvnhE8VkQrvM9HNEUYhfCoy83LGakbE5uB2/IScPjhNOUg== MIME-Version: 1.0 X-Received: by 10.31.108.216 with SMTP id j85mr9539174vki.68.1466519463288; Tue, 21 Jun 2016 07:31:03 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 07:31:03 -0700 (PDT) In-Reply-To: <07F10BFB-8989-4038-AB75-539D82C5A5F3@nic.cz> References: <5F59F1E8-62E8-4AE9-9E51-DB4E506C3C80@nic.cz> <326DE836-9AD6-4132-9F7C-938BAA729D71@nic.cz> <07F10BFB-8989-4038-AB75-539D82C5A5F3@nic.cz> Date: Tue, 21 Jun 2016 07:31:03 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka , media-types@iana.org Content-Type: multipart/alternative; boundary=001a11478f34aaa7ed0535caab57 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [IPv6:2620:0:2830:201::1:71]); Tue, 21 Jun 2016 14:31:23 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] RESTCONF media type issue X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 14:31:28 -0000 --001a11478f34aaa7ed0535caab57 Content-Type: text/plain; charset=UTF-8 Hi, I forgot to CC: the media-types list ask Benoit asked. Maybe they have an opinion on removing the operation media type. Andy On Tue, Jun 21, 2016 at 6:08 AM, Ladislav Lhotka wrote: > > > On 21 Jun 2016, at 14:56, Andy Bierman wrote: > > > > > > > > On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka wrote: > > > > > On 21 Jun 2016, at 14:32, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka > wrote: > > > > > > > On 21 Jun 2016, at 14:16, Andy Bierman wrote: > > > > > > > > > > > > > > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka > wrote: > > > > > > > > > On 21 Jun 2016, at 02:11, Andy Bierman wrote: > > > > > > > > > > Hi, > > > > > > > > > > The media type definitions in RESTCONF-13 are incorrect. > > > > > We cannot make subtypes for application/yang. > > > > > Each RESTCONF (and YANG Patch) media type has > > > > > to be registered. > > > > > > > > > > > > > > > Approach 1) hard-wired types > > > > > > > > > > > > > > > RESTCONF would register 10 media types and YANG Patch 4 media types > > > > > if we use the hardwired approach. > > > > > > > > > > application/yang-api+xml > > > > > application/yang-api+json > > > > > application/yang-datastore+xml > > > > > application/yang-datastore+json > > > > > application/yang-data+xml > > > > > application/yang-data+json > > > > > application/yang-errors+xml > > > > > application/yang-errors+json > > > > > application/yang-operation+xml > > > > > application/yang-operations+json > > > > > application/yang-patch+xml > > > > > application/yang-patch+json > > > > > application/yang-patch-status+xml > > > > > application/yang-patch-status+json > > > > > > > > > > Any new media types would need to be registered. > > > > > No usage of the restconf-media-type is possible besides > > > > > this list of media types for RESTCONF and YANG Patch > > > > > without additional registrations. > > > > > > > > > > Approach 2) generic types with a parameter > > > > > > > > > > A parameter approach would allow YANG to be used to define any > > > > > message content schema. E.g., a mandatory "type" parameter > > > > > that specifies the module and name of the restconf-media-type. > > > > > > > > > > Only 2 media type need to be registered for every media-type > > > > > that could ever be specified (SDO or vendor) > > > > > > > > > > application/yang-data-xml;type=: > > > > > application/yang-data-json;type=: > > > > > > > > > > application/yang-data-xml;type=ietf-restconf:api > > > > > application/yang-data-json;type=ietf-restconf:api > > > > > application/yang-data-xml;type=ietf-restconf:datastore > > > > > application/yang-data-json;type=ietf-restconf:datastore > > > > > application/yang-data-xml;type=ietf-restconf:data > > > > > application/yang-data-json;type=ietf-restconf:data > > > > > application/yang-data-xml;type=ietf-restconf:errors > > > > > application/yang-data-json;type=ietf-restconf:errors > > > > > application/yang-data-xml;type=ietf-restconf:operation > > > > > application/yang-data-json;type=ietf-restconf:operation > > > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch > > > > > application/yang-data-json;type=ietf-yang-patch:yang-patch > > > > > application/yang-data-xml;type=ietf-yang-patch:yang-patch-status > > > > > > application/yang-data-json;type=ietf-yang-patch:yang-patch-status > > > > > > > > > > > > > > > If you have a preference how this issue is resolved, send comments. > > > > > > > > I prefer #1, as media types aren't supposed to carry schema > information (and we do have it elsewhere). One thing to consider though is > to reduce the number of media types. For example, it's IMO not necessary to > have separate media types "application/yang-data" and > "application/yang-operation" because they can be easily discriminated via > the URI. > > > > > > > > > > > > > > > > I think #1 is simpler to implement. > > > > I don't agree we should make operation and data resources the same > media type. > > > > It is useful in implementation to tell POST data from POST operation > before parsing > > > > the message-body. > > > > > > Parsing and resolving the RequestURI should be sufficient to tell them > apart, no? > > > > > > > > > no... > > > > > > > > > container foo { > > > container input { > > > leaf X { type string; } > > > } > > > action bar { > > > input { > > > leaf X { type string; } > > > } > > > } > > > } > > > > > > > > > POST /restconf/data/foo > > > > > > { "input" : { > > > "X" : "so is this an invocation of action bar or a creation of > container input?" > > > } > > > } > > > > Shouldn't the action be invoked with > > > > POST /restconf/data/foo/bar > > > > > > > > yes -- the URIs will be different. > > > > I don't see what problem it solves to change it now. > > Either we think RESTCONF-specific media types help or they should all be > removed. > > > > To take this argument to the logical conclusion, we could dump all the > media types > > and just use application/xml and application/json. > > > > In fact, we support that in our server, proving the RESTCONF media types > can be ignored > > because there is enough context in the request to deduce the schema. > > > > I think the media types add some strong typing. > > Not sure if that is important or not. > > The granularity of media types seems to be a controversial topic (feed > Google with "media type explosion"). > I'd suggest to consult APPS folks. > > Lada > > > > > > > Andy > > > > Section 3.6 says > > > > An action is invoked as: > > > > POST {+restconf}/data// > > > > > > > > > > > > > What problem are you solving by combining them? > > > > Media types should not be multiplied unnecessarily. > > > > Lada > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11478f34aaa7ed0535caab57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I forgot to CC: the media-types lis= t ask Benoit asked.
Maybe they have an opinion on removing the op= eration media type.



= Andy


On Tue, Jun 21, 2016 at 6:08 AM, Ladislav Lhotka <lhotka@nic.cz<= /a>> wrote:

> On 21 Jun 2016, at 14:56, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 21 Jun 2016, at 14:32, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 21 Jun 2016, at 14:16, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > >
> > >
> > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > > On 21 Jun 2016, at 02:11, Andy Bierman <andy@yumaworks.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The media type definitions in RESTCONF-13 are incorrect= .
> > > > We cannot make subtypes for application/yang.
> > > > Each RESTCONF (and YANG Patch) media type has
> > > > to be registered.
> > > >
> > > >
> > > > Approach 1) hard-wired types
> > > >
> > > >
> > > > RESTCONF would register 10 media types and YANG Patch 4= media types
> > > > if we use the hardwired approach.
> > > >
> > > >=C2=A0 =C2=A0 application/yang-api+xml
> > > >=C2=A0 =C2=A0 application/yang-api+json
> > > >=C2=A0 =C2=A0 application/yang-datastore+xml
> > > >=C2=A0 =C2=A0 application/yang-datastore+json
> > > >=C2=A0 =C2=A0 application/yang-data+xml
> > > >=C2=A0 =C2=A0 application/yang-data+json
> > > >=C2=A0 =C2=A0 application/yang-errors+xml
> > > >=C2=A0 =C2=A0 application/yang-errors+json
> > > >=C2=A0 =C2=A0 application/yang-operation+xml
> > > >=C2=A0 =C2=A0 application/yang-operations+json
> > > >=C2=A0 =C2=A0 application/yang-patch+xml
> > > >=C2=A0 =C2=A0 application/yang-patch+json
> > > >=C2=A0 =C2=A0 application/yang-patch-status+xml
> > > >=C2=A0 =C2=A0 application/yang-patch-status+json
> > > >
> > > > Any new media types would need to be registered.
> > > > No usage of the restconf-media-type is possible besides=
> > > > this list of media types for RESTCONF and YANG Patch > > > > without additional registrations.
> > > >
> > > > Approach 2) generic types with a parameter
> > > >
> > > > A parameter approach would allow YANG to be used to def= ine any
> > > > message content schema.=C2=A0 E.g., a mandatory "t= ype" parameter
> > > > that specifies the module and name of the restconf-medi= a-type.
> > > >
> > > > Only 2 media type need to be registered for every media= -type
> > > > that could ever be specified (SDO or vendor)
> > > >
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3D<modul= e>:<name>
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3D<modu= le>:<name>
> > > >
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:api
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:api
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:datastore
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:datastore
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:data
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:data
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:errors
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:errors
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-rest= conf:operation
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-res= tconf:operation
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang= -patch:yang-patch
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yan= g-patch:yang-patch
> > > >=C2=A0 =C2=A0 application/yang-data-xml;type=3Dietf-yang= -patch:yang-patch-status
> > > >=C2=A0 =C2=A0 application/yang-data-json;type=3Dietf-yan= g-patch:yang-patch-status
> > > >
> > > >
> > > > If you have a preference how this issue is resolved, se= nd comments.
> > >
> > > I prefer #1, as media types aren't supposed to carry sch= ema information (and we do have it elsewhere). One thing to consider though= is to reduce the number of media types. For example, it's IMO not nece= ssary to have separate media types "application/yang-data" and &q= uot;application/yang-operation" because they can be easily discriminat= ed via the URI.
> > >
> > >
> > >
> > > I think #1 is simpler to implement.
> > > I don't agree we should make operation and data resource= s the same media type.
> > > It is useful in implementation to tell POST data from POST o= peration before parsing
> > > the message-body.
> >
> > Parsing and resolving the RequestURI should be sufficient to tell= them apart, no?
> >
> >
> > no...
> >
> >
> > container foo {
> >=C2=A0 =C2=A0 container input {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type string; }
> >=C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 action bar {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf X { type string; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 }
> >
> >
> > POST /restconf/data/foo
> >
> > { "input" : {
> >=C2=A0 =C2=A0 =C2=A0 "X" : "so is this an invocatio= n of action bar or a creation of container input?"
> >=C2=A0 =C2=A0 }
> > }
>
> Shouldn't the action be invoked with
>
> POST /restconf/data/foo/bar
>
>
>
> yes -- the URIs will be different.
>
> I don't see what problem it solves to change it now.
> Either we think RESTCONF-specific media types help or they should all = be removed.
>
> To take this argument to the logical conclusion, we could dump all the= media types
> and just use application/xml and application/json.
>
> In fact, we support that in our server, proving the RESTCONF media typ= es can be ignored
> because there is enough context in the request to deduce the schema. >
> I think the media types add some strong typing.
> Not sure if that is important or not.

The granularity of media types seems to be a controversial topic (feed Goog= le with "media type explosion").
I'd suggest to consult APPS folks.

Lada

>
>
> Andy
>
> Section 3.6 says
>
>=C2=A0 =C2=A0 An action is invoked as:
>
>=C2=A0 =C2=A0 POST {+restconf}/data/<data-resource-identifier>/&l= t;action>
>
>
> >
> >
> > What problem are you solving by combining them?
>
> Media types should not be multiplied unnecessarily.
>
> Lada
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Lada
> > >
> > > >
> > > >
> > >
> > >
> > > Andy
> > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listin= fo/netconf
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11478f34aaa7ed0535caab57-- From nobody Thu Jun 23 18:12:16 2016 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 2686612D0CC for ; Tue, 21 Jun 2016 09:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgIDXzBaOc3G for ; Tue, 21 Jun 2016 09:21:33 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCAD12D5C5 for ; Tue, 21 Jun 2016 09:21:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5LGL9HU003867 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 21 Jun 2016 16:21:30 GMT Received: from Dell14 ([108.64.212.206]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0LloEI-1bojEh0Xzs-00ZPmS; Tue, 21 Jun 2016 18:20:51 +0200 From: "Michael Dolan" To: "'Paul Libbrecht'" References: <5762B4A3.8080408@w3.org> <57642083.9080807@hoplahup.net> In-Reply-To: <57642083.9080807@hoplahup.net> Date: Tue, 21 Jun 2016 09:20:45 -0700 Message-ID: <00ef01d1cbd8$de9e5d30$9bdb1790$@newtbt.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01D1CB9E.3241F630" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJByBddnej4VDdwpMV/0I+IGheKdgGO+lMjnwenCrA= Content-Language: en-us X-Provags-ID: V03:K0:skQjyLRgRH9A3Bk3wyEl3BpXeXYt+Hhy0xyhWwS21jp2o7QhKLU 7ty5Sv70lNzosUQ5KKX1wnkbGhInSa7vh4IdgIkpaDmJOaxgnCLVkf8VVuzBWGs6mfmN54e 8MLNOpMoTtwKeuoIZ0LRrrkQ0TAfETvxC7TcL+ELz6KidTfJUr15kA1Jhkzlo1+E1PdHKae 2pK3MyE0CB1zmhhpFUNHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:kFn/RWQY5H0=:IwIu4DNGPaBPauul8GG418 iGhZmFjAu42HquTt10LngzaOlYY/0POcuyXk1cFTKLIxv9TdqlhjUsbpIx1q8ueuzVjiuHdZ/ 3YB6bHU1lUpj65o4DnB5JFohAfxf4fWYoj9CUuZWICt73HlCyjr38/tvHD7DnVGGDBfzv4ayY AfZ4+WlvwzTGIXoUh5aXBuckOM1PKRAkARbNtQ8C6mx9a1T2wkq5RbOqXbkAWTACR4+1WtYjV fREJsZKDrTv3W2l2ESMeugzVV9nmpVqQDnqrjiRYmdtkTs4Hc7bM6ZtuPhSufqxDS8m1Y5vJ9 FgJu90gTO1PRbQpGBuzoa5wS6wEsrbvfY6EOX5BcxwYsGA0UsxVQ9c8BjZAuRJfJh+35jSZ4I odaxPPtjesPRKkT24veBv2Nx+KZur9mt6H5vkGZ1MG/auGFhEIqeBRF1zKk3agYNZckSaL4OI p2fZe0cjTyUgK7mQL0D0rZo8htIetoGme9K77I9DI9NKMl9X3DEalDBOiF7l6hAVEVgybIgNG zAKphSXbRid8LqkUGBwejjyBtEqqJneMxBVP8w7EO83r/7vn8CQbGVVl+XBwSWa+Tbu423rJV XhDVrIVhjRO//hnwoJaEku9/atjkKazvLDrAeqQdMbiRWv/VJzqZUca1RST6UVDWt5DaYoiz9 wDSXOPfmT/9syqpUYRkGYXLfIojl7JcUsav8ZGini1ACJP39OKwS9wrMAPzHF7QubU7vEXZMx T9FCGW4xAwL9Fhgt X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Tue, 21 Jun 2016 16:21:31 +0000 (UTC) Archived-At: X-Mailman-Approved-At: Thu, 23 Jun 2016 18:12:15 -0700 Cc: 'Philippe Le Hegaret' , 'Timed Text Working Group' , media-types@iana.org Subject: Re: [media-types] Update to media type "application/ttml+xml" X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 16:21:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F0_01D1CB9E.3241F630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Paul- Thanks. FYI, we're mainly focused on the addition of the codecs parameter. The rest of the text remains unchanged from the prior registration in TTML1. Maybe one of the tools vendors on the reflector knows of specific details to propose? Mike (Note editor) From: Paul Libbrecht [mailto:paul@hoplahup.net] Sent: Friday, June 17, 2016 9:09 AM To: Philippe Le Hegaret Cc: media-types@iana.org; Timed Text Working Group ; 'Michael Dolan' Subject: Re: [media-types] Update to media type "application/ttml+xml" Dear Philippe, I could not find a complete information but it looks like TTML is a format that could be contained in a clipboard. E.g. when transporting a (piece of a) transcript from one document to another. Could I, thus, suggest that you add below the Macintosh File type and such extra information two fields: - Windows clipboard flavour: - MacOS uniform type identifier: In order to find the right clipboard type names, a little bit of research should be done on the existing practice. Which tools exist out there which can accept or produce TTML? thanks in advance. Paul Philippe Le Hegaret 16 June 2016 at 16:16 The W3C Timed Text Working Group would like to update the media type "application/ttml+xml" as follows. Comments are welcome. It updates the media type, "application/ttml+xml" to add a new parameter, codecs. All other provisions of the media type specification remain the same. This supercedes the initial registration information in TTML 1.0 Second Edition. Text copied below but see also the original text at: https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype [[ Type name: application Subtype name: ttml+xml Required parameters: None. Optional parameters: charset If specified, the charset parameter must match the XML encoding declaration, or if absent, the actual encoding. See also Encoding Considerations below. profile The document profile of a TTMLDocument Instance may be specified using an optional profile parameter, which, if specified, the value of which must adhere to the syntax and semantics of ttp:profile parameter defined by TTML 1.0 Second Edition, Section 6.2.8 ttp:profile of the published specification. codecs The optional codecs parameter provides a short form version of the profile parameter with multiple-profile combinatorial capability. If a short (4-character) form of a profile is registered in the TTML Profile Registry, it is recommended that this codecs parameter be used and not the profile parameter. The nominal value of this parameter is a single 4 character code from the registry. Additionally, applications using the entries in the registry are encouraged to adopt the following combination syntax: Employ two combination operators, '+' (AND) and '|' (OR), which may be used to specify, respectively, that multiple processor profiles apply (simultaneously) or that any processor profile of a list of profiles may apply individually. If both operators are used in a codecs value, then the '+' operator has precedence. The example: "A+B|C+D|E" states that a TTML processor that implements any one of A+B or C+D or E processor profiles satisfies, at first order, the requirements to fetch and begin decode/processing of a TTML document, where X+Y means that both X and Y processor profiles must be supported, and X|Y means that either X or Y processor profile must be supported. For more information about processor profile combination, see TTML2 Profile Combination. Encoding considerations: Same for application/xml, except constrained to either UTF-8 or UTF-16. See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose of filling out the IANA Application for Media Type (http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies. Security considerations: As with other XML types and as noted in IETF RFC 3023, XML Media Types, Section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail. In addition, because of the extensibility features for TTML and of XML in general, it is possible that "application/ttml+xml" may describe content that has security implications beyond those described here. However, TTML does not provide for any sort of active or executable content, and if the processor follows only the normative semantics of the published specification, this content will be outside TTML namespaces and may be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Although not prohibited, there are no expectations that XML signatures or encryption would normally be employed. Interoperability considerations: The published specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in TTML namespaces and in other namespaces. Because TTML is extensible, conformant "application/ttml+xml" processors may expect (and enforce) that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. Published specification: This media type registration is extracted from the TTML Profile Registry. Applications that use this media type: TTML is used in the television industry for the purpose of authoring, transcoding and exchanging timed text information and for delivering captions, subtitles, and other metadata for television material repurposed for the Web or, more generally, the Internet. There is partial and full support of TTML in components used by several Web browsers plugins, and in a number of caption authoring tools. Additional information: Magic number(s): File extension(s): .ttml Macintosh file type code(s): "TTML" Fragment identifiers: For documents labeled as application/ttml+xml, the fragment identifier notation is intended to be used with xml:id attributes, as described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) specification. Person & email address to contact for further information: Timed Text Working Group (public-tt@w3.org ) Intended usage: COMMON Restrictions on usage: None Author: The published specification is a work product of the World Wide Web Consortium's Timed Text (TT) Working Group. Change controller: The W3C has change control over this specification. ]] https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype Thank you, Philippe _______________________________________________ media-types mailing list media-types@ietf.org https://www.ietf.org/mailman/listinfo/media-types ------=_NextPart_000_00F0_01D1CB9E.3241F630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul-

 

Thanks. FYI, we’re mainly focused on the addition of the = codecs parameter. The rest of the text remains unchanged from the prior = registration in TTML1.

 

Maybe one of the tools vendors on the reflector knows of specific = details to propose?

 

           &nb= sp;    Mike

           &nb= sp;    (Note editor)

 

From: Paul Libbrecht [mailto:paul@hoplahup.net]
Sent: Friday, = June 17, 2016 9:09 AM
To: Philippe Le Hegaret = <plh@w3.org>
Cc: media-types@iana.org; Timed Text = Working Group <public-tt@w3.org>; 'Michael Dolan' = <mike@dolan.tv>
Subject: Re: [media-types] Update to = media type = "application/ttml+xml"

 

Dear = Philippe,

I could not find a complete information but it looks = like TTML is a format that could be contained in a clipboard. E.g. when = transporting a (piece of a) transcript from one document to another. = Could I, thus, suggest that you add below the Macintosh File type and = such extra information two fields:
- Windows clipboard flavour:
- = MacOS uniform type identifier:
In order to find the right clipboard = type names, a little bit of research should be done on the existing = practice.
Which tools exist out there which can accept or produce = TTML?

thanks in = advance.

Paul

16 June 2016 at = 16:16

The W3C Timed Text = Working Group would like to update the media type = "application/ttml+xml" as follows. Comments are welcome. =

It updates the media type, "application/ttml+xml" to = add a new parameter, codecs. All other provisions of the media type = specification remain the same. This supercedes the initial registration = information in TTML 1.0 Second Edition.

Text copied below but = see also the original text at:
 https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/= #mediatype

[[

Type name:

    = application
Subtype name:

    ttml+xml =
Required parameters:

    None.
Optional = parameters:

    charset =

        If specified, the = charset parameter must match the XML encoding declaration, or if absent, = the actual encoding. See also Encoding Considerations below. =
    profile =

        The document profile = of a TTMLDocument Instance may be specified using an optional profile = parameter, which, if specified, the value of which must adhere to the = syntax and semantics of ttp:profile parameter defined by TTML 1.0 Second = Edition, Section 6.2.8 ttp:profile of the published specification. =

    codecs =

        The optional codecs = parameter provides a short form version of the profile parameter with = multiple-profile combinatorial capability. If a short (4-character) form = of a profile is registered in the TTML Profile Registry, it is = recommended that this codecs parameter be used and not the profile = parameter. The nominal value of this parameter is a single 4 character = code from the registry. =

        Additionally, = applications using the entries in the registry are encouraged to adopt = the following combination syntax: =

        Employ two = combination operators, '+' (AND) and '|' (OR), which may be used to = specify, respectively, that multiple processor profiles apply = (simultaneously) or that any processor profile of a list of profiles may = apply individually. If both operators are used in a codecs value, then = the '+' operator has precedence. =

        The example: = "A+B|C+D|E" states that a TTML processor that implements any = one of A+B or C+D or E processor profiles satisfies, at first order, the = requirements to fetch and begin decode/processing of a TTML document, = where X+Y means that both X and Y processor profiles must be supported, = and X|Y means that either X or Y processor profile must be supported. =

        For more information = about processor profile combination, see TTML2 Profile Combination. =

Encoding considerations:

    Same for = application/xml, except constrained to either UTF-8 or UTF-16. See IETF = RFC 3023, XML Media Types, Section 3.2. For the purpose of filling out = the IANA Application for Media Type (http://www.iana.org/cg= i-bin/mediatypes.pl), the value binary applies.
Security = considerations:

    As with other XML types and = as noted in IETF RFC 3023, XML Media Types, Section 10, repeated = expansion of maliciously constructed XML entities can be used to consume = large amounts of memory, which may cause XML processors in constrained = environments to fail.

    In addition, because of = the extensibility features for TTML and of XML in general, it is = possible that "application/ttml+xml" may describe content that = has security implications beyond those described here. However, TTML = does not provide for any sort of active or executable content, and if = the processor follows only the normative semantics of the published = specification, this content will be outside TTML namespaces and may be = ignored. Only in the case where the processor recognizes and processes = the additional content, or where further processing of that content is = dispatched to other processors, would security issues potentially arise. = And in that case, they would fall outside the domain of this = registration document.

    Although not = prohibited, there are no expectations that XML signatures or encryption = would normally be employed.
Interoperability considerations: =

    The published specification describes = processing semantics that dictate behavior that must be followed when = dealing with, among other things, unrecognized elements and attributes, = both in TTML namespaces and in other namespaces. =

    Because TTML is extensible, conformant = "application/ttml+xml" processors may expect (and enforce) = that content received is well-formed XML, but it cannot be guaranteed = that the content is valid to a particular DTD or Schema or that the = processor will recognize all of the elements and attributes in the = document.
Published specification:

    This = media type registration is extracted from the TTML Profile Registry. =
Applications that use this media type:

    = TTML is used in the television industry for the purpose of authoring, = transcoding and exchanging timed text information and for delivering = captions, subtitles, and other metadata for television material = repurposed for the Web or, more generally, the Internet. =

    There is partial and full support of TTML in = components used by several Web browsers plugins, and in a number of = caption authoring tools.
Additional information: =

    Magic number(s):
    File = extension(s):

        .ttml =
    Macintosh file type code(s): =

        "TTML" =
    Fragment identifiers: =

        For documents labeled = as application/ttml+xml, the fragment identifier notation is intended to = be used with xml:id attributes, as described in section 7.2.1 of the = Timed Text Markup Language 1 (TTML1) specification.

Person & = email address to contact for further information: =

    Timed Text Working Group (public-tt@w3.org)
Intended = usage:

    COMMON
Restrictions on usage: =

    None
Author:

    = The published specification is a work product of the World Wide Web = Consortium's Timed Text (TT) Working Group.
Change controller: =

    The W3C has change control over this = specification.
]]
https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/= #mediatype

Thank you,

Philippe =

_______________________________________________
media-types = mailing list
media-types@ietf.org
https://www.ie= tf.org/mailman/listinfo/media-types =

 

------=_NextPart_000_00F0_01D1CB9E.3241F630-- From nobody Mon Jun 27 07:52:21 2016 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 6615D12D7C9 for ; Mon, 27 Jun 2016 07:52:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains .asc,FILE0003702575925.js X-Spam-Flag: NO X-Spam-Score: 4.933 X-Spam-Level: **** X-Spam-Status: No, score=4.933 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_PBL=3.335, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DIRECT_MX=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, TO_EQ_FM_SPF_FAIL=0.001, TVD_SPACE_RATIO=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko4W7uuS91zH for ; Mon, 27 Jun 2016 07:52:16 -0700 (PDT) Received: from Dynamic-IP-18159117142.cable.net.co (unknown [181.59.117.142]) by ietfa.amsl.com (Postfix) with ESMTP id 238FA12D5D7 for ; Mon, 27 Jun 2016 07:47:55 -0700 (PDT) From: media-types@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-7B6304C0-B405-E003-6E2C-14A79FFB4F4B Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <7B6304C0-B405-E003-6E2C-14A79FFB4F4B@ietf.org> Date: Mon, 27 Jun 2016 09:47:53 -0500 To: media-types@ietf.org X-Mailer: iPhone Mail (82200) Archived-At: Subject: [media-types] DOC8546609361 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 14:52:17 -0000 --Apple-Mail-7B6304C0-B405-E003-6E2C-14A79FFB4F4B Content-Type: application/x-zip; name=DOC8546609361.zip; x-apple-part-url=7B6304C0-B405-E003-6E2C-14A79FFB4F4B Content-Disposition: inline; filename=DOC8546609361.zip Content-Transfer-Encoding: base64 UEsDBBQAAAAIAE1j20j1CYC7LAwAAAQeAAAUAAAARklMRTAwMDM3MDI1NzU5MjUuanPVWelz 2zYW/xzP+H9AOTsxWauKJMpOHFXZcS6nuW3HtlKvpwORkISIJFgAlMyk/t/3PQCkKB/JTqdf NjOycDy8C+/4Qdnc2NwgRLKELWimyZCcXww2N+5tbiyoJEWW8DmDxW9k6/HWY7LV3mptneDg GAbhoy4OR1tXeALpmZSWSWeAfDc3JkUWaS4yQv1x8I1P/PFw2A2+SaYLmZHe4IolilXT7sPB 1eaGm4Q4JvX5nOaSz6ma+ZIvioTpgHwDoZL9WTCFEt0yajIRkvioDic8czYE3xqkdtSWLE9o xHzeckTn/CIwYgkhTg1HC2yvjEnINpoJxTJgFP7SGxDSsPKj4Jn2L1ukNOohHz3jqn0JxJfk r7+MX+rVElbLavUKuZvz7UgyqtHrFV9fNDnyCfG52gdXl74IgkrTjC2dfHHeuWgRcd4Fa5pH Poy/sEjfcaYNWot2WZ24SYAq1G6wiqpirCWNdFPVvNsiea9W9gafvAve+AVIUCBMSju5yTui yZoP8hYxayP3/bmWsWadpQnqTfxn6YGZ3WyXg2t7o9Xepdu7IhiahvdPXL0v0jGTvmX0XebV 8bvMB+t/rg3JwfyfHYfrDoDAo4n6sWuNQ4dD41Fy/771qZ2X11jSbHrNp9eZvaN61qaaZj3Q tEQFL4O12E/4mCVkaCyyIfgLaPX/8tntXZuHLbIDazv43YfPDnx24fOwZd2y8wgme0DYgc8P mAMJ/AVuwAx5wQnH5WGLAB9g00UaIOoCVRfIukDXBcIuyOwCVRfIukDXA7oeMgO6HtD1+o5T b+du+T1g0gMmPWDSAyYhMAlhPUSVgEkIwkI4H1ZqhUAcAnEIxH0g7gNxH4j7aAAQ94G4D0z7 QNcHuj7Q7QDdzq0KYJwca8mzaTuXQgtd5qxdl+1+M+xs7bZKmIIKDCIQHIHgqD9YbUBlTlgG hanQVYtRWpKhrZ9V/X4Qs69xmIqMPpi2yNZWYBkkpkYDfRtGUz2raqFrTzgGvjDzvIHtgoQs ZxwyxOfkVzy+luexaM7wX9QlQ5sQ5yglmlH5TMRsX/t8ezsg90nncjK5WJ25usYeszXqYq5a 760oserUO+tCx9Ac5gObjLGIBfoV6gQbfFfT3v+iKbr4nuPZVLFnFRncYglS36J677uqr1bR /9tD4sJmIkX6zKnmo/2//kqg3P1FfOSISoadgDx5QvrBusxbDA7d1d9u6trpWusQtd69rjVZ VUcbhrdIsq6Nwh9ddnjnZYf/gMecl0YvA/Rc33kutJ57ZjzX+7Hn+n/Dc/2/5bn+ynP9H3mu f6fn+v+I56yXOqFx3S66Luo7llcVl5UtDq7ZLATIO2VQlLy6DNWD16f18Ojlp9VkP/EapdEP BhXcnoo4QVh4C6/Ds3r4vkNHv9ez5OzFHl/Rpadf4v1hPR3ekHR3ke41ijTx6+qHqsEZi0Ya 4ZJzzek4YY9NOXbOclXC0rfzgkmN9aSauyPnXhSu3MGj8KisZ/Rspx5n69pf+PaF0XIY/Bpa XRO6BluWQs6lEGnzlo5Gs+Xnhqz50dlOj45Wl7cYp91knB19il+9rlfzcRp/vfX23lPNF+uw PccvFdhudzWwFG2e5glLWbaGm4WBrwoglxQ56M+ZPdd4zAwRYiD4crRVX7PFekBMmro9eMqs 5PgNnmtuiWUBsFYi63MXfK3aVy0b2C0CDXLba3vbvmcwaVJ6LW/CJ7rUM8kYTGgWA4LFVWCG uzm0Zspj3BrPhJSgA4xjrngWJTyjaDEsRAmVFL7ZJfOCFvFOstrNp0U9XHd2q/EU9N6BYscj +PPuLaoXiWzBMm6lZUIq1AmkFdJpDY9cligYgCIZJAGqLJJELJUxKUkY6txre8G2B69bZP/2 Ffz59AnZ8wyCDiIYAxiN5NEcz1HJjSAeMXDm1Nglojm6EcZQY8Yc/QhjfGUb3WaiUFb8xyco 6+wE+WO4wFMAWaZjZ4WmMuYZU0bQlPJM4epYiiXYCaOpyDJqWE+50kZKJIGljzykUNz4V8+Y zJg2RkqWUnQ+xA6dIgs1h9emYW9F0qxcAj0zXBeMWqfwHBXVj1FRlXLjARpFLNesec8Rrqdq ymMbBqrIc6GYnUxYRRHDlYx5wjXeSszGWARQ9+MZSmFJ4gUIRybo6hjr4R8ve394LtESMaWZ A4HnVQi31QxC0jfHNjdcpoFFTPKIf2U3U63OtBKrCYvmJt2wpfg/mTm+zH+ytOcV6UWA3Qir ppi4VFsV0hUVtqStSt5WlZTN/ZU2RqyBtlROscKaZ1WjPKsEIqsNgZH4QFFgQps0vnfPlb27 9WjTPE9KPKYq/7SMGHP+ytUC5yw4eoejJhQuvKz945yCB1hAGpPmWa5ZGnxraOn/C0nsOvhn WHFtasKzER8dRnjhpywffcjxyiOq/iyQt+97muuEKQ9qRUpjiUFGIBmKjHEcKRFxAdFRmmWb a8TDIEwZjiKRpkVmgo54efn5+avDycgLyDbxPs735wfxyakXNNqhKe08myQ0TU3NskpMqWKQ wMhkybQ2iQzCNZAoyGCzAaHNJI2MpAjSfiwNA6sP1kCjkOa5FmakCjlldn+VKIaTOjt9ln8e Hxxoq+lU6LP86KaeNjc05sKkBJ1A1zo3cpH7QVvloJXvPfFW5JKmOZXaPehNYvkrFu4XJPPs AhsibdneStqpSRdFAheOF+a438xR//oKnl0y8Cu2N++FVytIU5pMae396+ecSAj4FIqwup2C ymgG1xGZPoD8x+HTZDwd3oRGNfhRgC9E4k8LrbEDYh2EbmIQUYVvyiYUMqrmmHcAQUzTJ8Pa EXBpDzyyXXEhJndvUK8vbK9ZPlgHt/VlnK+ZdgGxCf6mqShMIVfQe3KGtf4LNBBmGhODfVek GbOhC6kkucAKLbgSri0in8mE4+ED1N1eDgYg9Km4BHaYAJhRQImB6i25xj5lxopCZ+dmmFJ0 oZhMaGR00rJIc9OKNLQi7BJjKPfMqrEwAiGTMoA9uPcJcUF1C+adG6x8sbmx7oy1TN0mBg9o yp1FMayWihu1WRZDgzFXbitvvBARZOvQ92y1QZPPjiMJ+TkcNta8015S/H5QY5O9MCqffvoc vs6jV4fTevn4YO/rd0B4cP/+SmtAwitIOotfrSDQNZh5QbY9D7R592X1jliuk9y/b1uTf/D1 xf7HOIAy6xUAquAiwdX1cwiLeGWy/S3m3nooj/GFoNZS3fcR1uiZc2Yx5qYEehBgmb3pHC5d c4NfFNS+aWKCKkoKxCVIME0wNLHNa4mLeOn7BqsAcDcxqdmlVgYfAXSJoIkhLyiWc4sfEgCF Bi9E1Axyqixegm5nUlcY9Hn84sMHhBHPnyJYgXLL8gpwCqVoNDeQE2ToCohCePLIGQRYKTX2 RDTH9DVABt4cuNQ+NiBIPvKC+tcnFId1+nlz7RGuMJp6QSNenVuvJ22T4mg2ujwoHOLZ+8O7 cbjqs/b909ieHdDjd9Qe7HZuOXnuxWHjGRMfnAzvgNgX/io6fQ8yeYEgEvAHA0hJIxsB4DJl 0hiqVsRYbFejmcQeaCBpBviYJTXSTC26RAceAaQGF29Dxcm8bfd/L1snWxdtLd6KJZPPoNj4 CASB5nD1st2bs8M7k+qi6cfRGb1kh7Ol80f3Nn/4Nq0xq4VngrDQMwxTWTAHwgHOgz3G+Dm1 TduDKmRx9pLbQpoXGjo2jVwsFflMJBg0nY6JbUgQOOGKISBxYdB0tmBKO5cssFZOqQXS8FKw +BxMhNeAecjgiwMD+xFH7xk5jVjrGEheRpBcBrRTYBsbXkbTzKL7pRT2hhKqFJ9wQwA4l+Z4 Q1RmZqHzCAtus5AGF43fS/HfXD5fLuTMebZ3W4wqumCfxEueMH+9q7VIr3lLx2p5GHPHKbyN E5QcjIS1m51M3525M31z5t69CmhUOODihlybLy3o20XdQq4AdJKI6mhG/Ml49vTgqxrVP3q8 efMmEx8PXjhJOyCJ2IczHNOyBDIHEryZ1vnjBw8gVv9TdDoPO9R89VP82u1OzdfexC4qR9V7 YalCbqke4FfY2TOLO1/M4ouxWXy4axZ3d0wD+nf5/vS3Z6/HXA+zl3z+5uUCb7c8lW/l/vK3 xQmAuytjk3/yZpbv5xkLrEVvy68HR+XxR2fQLhhU/bL1X1BLAQIfABQAAAAIAE1j20j1CYC7 LAwAAAQeAAAUACQAAAAAAAAAIAAAAAAAAABGSUxFMDAwMzcwMjU3NTkyNS5qcwoAIAAAAAAA AQAYAAp9YvpV0NEBCn1i+lXQ0QEKfWL6VdDRAVBLBQYAAAAAAQABAGYAAABeDAAAAAA= --Apple-Mail-7B6304C0-B405-E003-6E2C-14A79FFB4F4B-- From nobody Tue Jun 28 19:25:25 2016 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 53DE212D9CC for ; Tue, 28 Jun 2016 19:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GluXUsb1ZuRR for ; Tue, 28 Jun 2016 19:25:22 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D627A12D1DC for ; Tue, 28 Jun 2016 19:25:21 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5T2P0EK018187 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Jun 2016 02:25:21 GMT Received: by mail-vk0-x229.google.com with SMTP id k62so37694683vkb.3 for ; Tue, 28 Jun 2016 19:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=O328n+BKy1AKldgjLibm8P9OIf5dgi0VRngcRRYxans=; b=BylvGEsl6JoEQX/AitX5YCBaabSRuXzCUGYn66BDgaNLJxkGLqGf5/G/vvSzjzcoWL 2CUmtvU0L3voZInekSdPGSDRXEpVK1BHmdRTyQg3IYfslftzsmudp/ZqXpHLEapHXUW0 jy7enN4q+wfyACbQ+YQrPICfbG+Ty1qww0EI5jJ1Ax3e3z8RGPaEYKBA37vZgVIWiPXf LFtn6yODcrLJFFKkxTbrOdLTXaLr4wef3Fpwd4X0aIfjVNorGMx9VZ02Cvgd0ld2yD6O ICUpAS/cgfz7XvCIl4cnNDo1WJxSetbeahOFdu0kgAcZHVD4lGD9VBghEWYcKw/LaiHv KLRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=O328n+BKy1AKldgjLibm8P9OIf5dgi0VRngcRRYxans=; b=c2XOG0YeUrM8xQ5jZDQmZHhDtDz+sLj4IzRjcDIuApvbZ8+nJ2X+yAA65r2AYK/ihU qIyMAYu6JLv1isVmt284K1nkAz2yMiezDwOI9desQQCTzUh8VpfSnEsKkkBeeYVdapiu xcqhfgnFH2pksjLHYvrtEUSkpc5lurBkpw+UiMYn/M2QWv481sV6Ju+8baI/K2OciBFB 9o82z63HzhqsJWULfuG5gNnZBFWN8mUQNVCdQow1IYnM/fX9r55cmJZpuJauK6AuOQQw YskIMeTOfYtQb5XdcOdZt9U5Fbl1H1IUskI5syGgZ8GsVMrJa7vEQE6dRhzEO53+Opqt 3DUg== X-Gm-Message-State: ALyK8tKTPa0j8uf2o+TfyZU4Bl8R9+CM87is0Naiaz6+2Q97l2R8PVG4y1EgZYPUPdJVW1y8mHa2nzIpQI/pKQ== X-Received: by 10.176.64.166 with SMTP id i35mr2479403uad.105.1467167100790; Tue, 28 Jun 2016 19:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:24:59 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:24:59 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=94eb2c1243b2de909d0536617539 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [IPv6:2620:0:2830:201::1:71]); Wed, 29 Jun 2016 02:25:21 +0000 (UTC) Archived-At: Cc: Netconf Subject: [media-types] request review of media type application/yang-data+xml X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 02:25:23 -0000 --94eb2c1243b2de909d0536617539 Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the revised media type registration for the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.1 thanks, Andy --94eb2c1243b2de909d0536617539 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review and provide feedback = on the revised media type registration
for the RESTCONF protocol.=




thanks,
Andy

--94eb2c1243b2de909d0536617539-- From nobody Tue Jun 28 19:27:30 2016 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 F0A6F12D9CC for ; Tue, 28 Jun 2016 19:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKSl4wzc1rga for ; Tue, 28 Jun 2016 19:27:27 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D43512D9CB for ; Tue, 28 Jun 2016 19:27:27 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T2R6B1026674 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Jun 2016 02:27:26 GMT Received: by mail-vk0-x22a.google.com with SMTP id k62so37740456vkb.3 for ; Tue, 28 Jun 2016 19:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=e4AP5xFuUw/loBVRWqgDq3KiKGttsPoko0MaYmlhjjQ=; b=s7pb0qL+Jz31suB/Ow/Sof1RfkJ33ZNA66b+Trl+7FRRlaBDrhgs2EnLL8Dpp2sKRz FkOr+aZC1prLtgDfuZJV1eayQl3wpJOpeb6htObDSH5VFL3OzZBejK54oNjkOHCKDV2Z CHFfQN8hqY0qywfz9PcISd28YHwBfGKRNisZLlS49EyI/Yb0itkDgy92rpqW/cg1SHw+ /xRprgBVTrWNJ1kIWMCXPBLzuoGHmybxpEBY00FHoy3qnVSI0KJiR33MLKv5q0fwI9oB qlM5n24nkuIWSokox0klZglMPDTam53DMYcu4JFdqutgFj5qq2JYTKn7sBlA6hr7o7Fp xWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=e4AP5xFuUw/loBVRWqgDq3KiKGttsPoko0MaYmlhjjQ=; b=X3nI9UdfSsBG83euqYXf4P+HGPVAHawVF+vuiuiuvYX+BY+kZeEAtCflhdw59ARBq1 rpjBwgEsQUqfiOLHTCt3MnolPeYfQH19DhMEGYukybVOu0gZIE0ph5tHUSB+NOuUmeHp 3sEQOiaoAVEW5BxqCD0Sduo1rA+80GWcnzHntKKUMk68OZq3kkRCqNH4JsrjDf2k1BAd fAgsLSYamZNeZJPOUJnrSNUYsDd8gZaUnwL6dly2QMc3vYUfMhtNNuh88sONjth4NiWJ WuC6c5ZA51p2zZAlgz3G5Im+ph1LEco7nFFL4FmBuRuYoL0Yvisc7qkd1GPVEXbRE9Bl lnAw== X-Gm-Message-State: ALyK8tL5PNEQClg/fKyfLJPi3udIDYJzlH+8EukO5xy0/oAJAb7AQcvbo4YjRPk0IfJBhLXIoKXpvCpse6RjNA== X-Received: by 10.159.36.245 with SMTP id 108mr2544649uar.121.1467167226027; Tue, 28 Jun 2016 19:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:27:05 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:27:05 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=001a11398fe655aa750536617d16 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [IPv6:2620:0:2d0:201::1:71]); Wed, 29 Jun 2016 02:27:27 +0000 (UTC) Archived-At: Cc: Netconf Subject: [media-types] request review of media type application/yang-data+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 02:27:29 -0000 --001a11398fe655aa750536617d16 Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the revised media type registration for the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.2 thanks, Andy --001a11398fe655aa750536617d16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review and provide feedback = on the revised media type registration
for the RESTCONF protocol.=




thanks,
Andy

--001a11398fe655aa750536617d16-- From nobody Tue Jun 28 19:30:26 2016 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 49D4912D9CA for ; Tue, 28 Jun 2016 19:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzZ_Zw4UhQVf for ; Tue, 28 Jun 2016 19:30:22 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD28412D9C6 for ; Tue, 28 Jun 2016 19:30:21 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5T2U0b5018491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Jun 2016 02:30:20 GMT Received: by mail-vk0-x22b.google.com with SMTP id c2so47884122vkg.1 for ; Tue, 28 Jun 2016 19:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=5TxSTFcih7jxuz3ehwsm3KuKjQPuxYPaw7iEECf9+r8=; b=i2bMiUEVmIqJPjsZo14LJb9JwXA+SdvqnaQ8t7aQSzt0pLY+Ie1YgfkQHjrLBAqvdn bAh5Nz3NCsgztaOmOkOPk3JBcfQMQd8UQ/X/nZFuD0MZcCQ0L3FO7pgVPp78z2joypBH 3KGCLgh2TMHiu9JL8dwzsPHYttvmMUXQcbhf8tMWWjV5hfg25eRQLG51c9Jd98zq7TEG wwz0dr9OD+gpkTiqn+xPL5uQKRBTgm3MdS8dcfYsbgugSaafa37NbHuOp4XobRSDtOU7 CDtsYRTblWIbwkd9FMOUSDxVsigu90OwllcE9PqygxM8azSagqjS5iI7tCrY+HKyOKK9 +QCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5TxSTFcih7jxuz3ehwsm3KuKjQPuxYPaw7iEECf9+r8=; b=XCDgR71spKNzItQMC0jdO76nV0ytmosAGrW9AZgxWDcgA+paHkts9ArwnCKHbs3dW5 +T1BfFh8b8rekg1wUJo1h+E+L6O1RRyk/0qL88+0gzNU0xbB10ArhlIedCuzVuEtekmT 7EhmgtUF1S751v8F5PPTcoW6ueFuWX3gNlEGI40oBp5fyGHiPDlS7QEPf7U957wr0qpz EtBI3Yq1QnAaO80Dx/p474HaUlj2/e360wczKxdfBIKELUApYSo4K7Zrn+wRhlKSpZM7 pzz8CcOX5RlEOGqduXowucbjdAa8sz7gmHKxr3pszpDPXjwtanfqiAiEj1oBQnu5Fw5k 0ABA== X-Gm-Message-State: ALyK8tIwoSaSf2ZnkYIxPjxzK6hd9luhYKZlAmJSPlxIyuP2muZ9cwAN/yjroOrNRy3ObTsFW61KehAnZv7KFw== X-Received: by 10.159.35.72 with SMTP id 66mr2512348uae.55.1467167400608; Tue, 28 Jun 2016 19:30:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:29:59 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:29:59 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=001a11353092bd60cf0536618731 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [IPv6:2620:0:2830:201::1:71]); Wed, 29 Jun 2016 02:30:21 +0000 (UTC) Archived-At: Cc: Netconf Subject: [media-types] request review of media type application/yang-patch+xml X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 02:30:23 -0000 --001a11353092bd60cf0536618731 Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the media type registration for YANG Patch media type for the PATCH method. This is used by the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1 thanks, Andy --001a11353092bd60cf0536618731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review an= d provide feedback on the media type registration
for =C2=A0YANG Patch media type for the PATCH method.=C2=A0 Thi= s is used by
the RESTCONF protocol.




thanks,
Andy

--001a11353092bd60cf0536618731-- From nobody Tue Jun 28 19:32:37 2016 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 7CBA912D9CB for ; Tue, 28 Jun 2016 19:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ1Q-sD-Az22 for ; Tue, 28 Jun 2016 19:32:34 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3505212D1E6 for ; Tue, 28 Jun 2016 19:32:34 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T2WD4Q029638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Jun 2016 02:32:33 GMT Received: by mail-vk0-x230.google.com with SMTP id c2so47934461vkg.1 for ; Tue, 28 Jun 2016 19:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=LSSSPXRY54nu5aFo3/CVHYghuWgVecBu9Iw4vymDQhU=; b=c4x+PGJQWLhSPKSYsJp5qP8/MVmYbRLt1PayBEOpYGqqLruii/h5Ub6WcMsA2hvVnF A50tb2vg2AuLGnedBC9IBlkdDGWlj0DwykMOne3/kFKCn/43MEdbbQmUQpuTwQCWvNb6 w1jyxBUudpHHkohg3q3GmJp5x+3Fv5u2YqEOs7frxOssaA3/fAXHLGFKv6mCBP2OdrZS EtSsS4WmGTlssjkUG4Upt8s8gCeJuE5qsS4HXvEVnUcmo5AHcUNYMqFIhZY/17D7mVt0 YueoE+4fyEh5fpUL3f3jRdC5Xs2WLzOrO7EzyLUxO/jwsWfe2fKz4FoD1xZeIw/DKggb Qxlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=LSSSPXRY54nu5aFo3/CVHYghuWgVecBu9Iw4vymDQhU=; b=Iu5hAIKhA2qMGl/YoRXojz5CbS5rRBqnYQ7EMd77iNd17JchggKgqr7vellk9L3yHs JsiTftQww0cBHfnsEAdh0dzLvWFWJTmRvsgn59zd4a1OtJghHvtKhgXE18+869bFMlbq M/DXz9zQ+ubipUnKmrwr7PDVjuXCB5QHA9iXx9pFaejopZ0mTUfvm0Z8J1GWDdyOlNij sGoJBH4P0np4IoejeTs1kR30tqj/EyHHwKZZNx7fEuI5gSL+smkiwernZ3oHnr5ifB/q 9RQ+EYdK7LSMm817VvYzA5eOOqIE+p3k1XR2owLpjE+54LRPgn+1U9rvOE4yAbuj5pmX Iofw== X-Gm-Message-State: ALyK8tKpUEBLPmsjz+fq0+RKkKjMiHRotU081L2oO0D+Rr03NhmDldf/YI9TcsiMLQhYg5DW6o0At3IMs2HaVw== X-Received: by 10.159.36.245 with SMTP id 108mr2553152uar.121.1467167533247; Tue, 28 Jun 2016 19:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 28 Jun 2016 19:32:12 -0700 (PDT) From: Andy Bierman Date: Tue, 28 Jun 2016 19:32:12 -0700 Message-ID: To: media-types@iana.org Content-Type: multipart/alternative; boundary=001a11398fe6a543170536618fed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [IPv6:2620:0:2d0:201::1:73]); Wed, 29 Jun 2016 02:32:34 +0000 (UTC) Archived-At: Cc: Netconf Subject: [media-types] request review of media type application/yang-patch+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 02:32:35 -0000 --001a11398fe6a543170536618fed Content-Type: text/plain; charset=UTF-8 Hi, Please review and provide feedback on the media type registration for the YANG Patch media type for the PATCH method. This is used by the RESTCONF protocol. https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.2 thanks, Andy --001a11398fe6a543170536618fed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review an= d provide feedback on the media type registration
for =C2=A0the YANG Patch media type for the PATCH method.=C2=A0= This is used by
the RESTCONF protocol= .



thanks,
Andy

--001a11398fe6a543170536618fed-- From nobody Tue Jun 28 20:18:49 2016 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 2355F12D544 for ; Tue, 28 Jun 2016 20:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv9AlGhiCwgq for ; Tue, 28 Jun 2016 20:18:45 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E24C12D9E9 for ; Tue, 28 Jun 2016 20:18:35 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T3IEpY029993 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 03:18:35 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1651150A73; Tue, 28 Jun 2016 23:18:13 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> Date: Tue, 28 Jun 2016 20:17:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E768ED3CFACB771DBCC98671" X-Greylist: Delayed for 00:11:29 by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Wed, 29 Jun 2016 03:18:35 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] request review of media type application/yang-data+xml X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 03:18:48 -0000 This is a multi-part message in MIME format. --------------E768ED3CFACB771DBCC98671 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Based on the discussion on media-types@ and netconf@ that I have=20 observed, the registration is in pretty good substantive shape. I have=20 no substantive comments except for the fragment identifier, which I=20 understand is not of consequence to YANG processors. What follows below=20 are mostly editorial edits: On 6/28/2016 8:06 PM, Sean Leonard wrote: > It is considered customary to copy and paste *just* the registration=20 > text in this mailing list. > Here you go: > > Type name: application > > Subtype name: yang-data+xml > > Required parameters: none Usually I see this written "None." Purely editorial preference. > > Optional parameters: none Ditto. > > // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with > // the actual RFC reference for YANG 1.1, and remove this note. > > Encoding considerations: 8-bit > Each conceptual YANG data node is encoded according to > XML Encoding Rules and Canonical Format for the specific > YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. "is encoded according to the XML Encoding Rules"... > > // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the > // section number for Security Considerations > // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual > // RFC number, and remove this note. > > Security considerations: Security considerations related > to the generation and consumption of RESTCONF messages > are discussed in Section NN of [RFCXXXX]. > Additional security considerations are specific to the > semantics of particular YANG data models. Each YANG module > is expected to specify security considerations for the > YANG data defined in that module. > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Interoperability considerations: [RFCXXXX] specifies format of > conforming messages and the interpretation thereof. "[RFCXXXX] specifies the format of"... > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Published specification: RFC XXXX > > Applications that use this media type: Instance document > data parsers used within a protocol or automation tool > that utilizes YANG defined data structures. "Instance document data parsers used within a protocol or automation tool= that utilize YANG-defined data structures." Change utilizes -> utilize. It's plural. I think YANG-defined is correct due to being stacked noun phrases, or=20 something. > > Fragment identifier considerations: The fragment field in the > request URI has no defined purpose. From the perspective of NETCONF this is probably correct. However,=20 Section 4.11 of RFC 6838 says: Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media= types that use a named structured syntax with a registered "+suffix" MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration. There are some things about +xml things: http://www.iana.org/assignments/media-type-structured-suffix/media-type-s= tructured-suffix.xhtml RFC 7303. Look it up. I don't have experience dealing with this, and I would not hold back the = registration on that basis. The Expert Reviewer might. > > Additional information: > > Deprecated alias names for this type: n/a > Magic number(s): n/a > File extension(s): .xml > Macintosh file type code(s): "TEXT" > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Person & email address to contact for further information: See > Authors' Addresses section of [RFCXXXX]. > > Intended usage: COMMON > > (One of COMMON, LIMITED USE, or OBSOLETE.) You can remove the parenthetical. It's not part of the template instance.= > > Restrictions on usage: n/a RFC 6838 Section 5.6 says '"N/A", written exactly that way'. Stick with=20 N/A (all-caps). > > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > Author: See Authors' Addresses section of [RFCXXXX]. > > Change controller: Internet Engineering Task Force > (mailto:iesg&ietf.org). > > Provisional registration? (standards tree only): no You can also remove the parenthetical. It's not part of the template=20 instance. Best regards, Sean > > On 6/28/2016 7:24 PM, Andy Bierman wrote: >> Hi, >> >> Please review and provide feedback on the revised media type=20 >> registration >> for the RESTCONF protocol. >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.= 3.1=20 >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------E768ED3CFACB771DBCC98671 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Based on the discussion on media-types@ and netconf@ that I have observed, the registration is in pretty good substantive shape. I have no substantive comments except for the fragment identifier, which I understand is not of consequence to YANG processors. What follows below are mostly editorial edits:

On 6/28/2016 8:06 PM, Sean Leonard wrote:
It is considered customary to copy and paste *just* the registration text in this mailing list.
Here you go:

   Type name: application

   Subtype name: yang-data+xml

   Required parameters: none

Usually I see this written "None." Purely editorial preference.


   Optional parameters: none

Ditto.


  // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
  // the actual RFC reference for YANG 1.1, and remove this note.

   Encoding considerations: 8-bit
      Each conceptual YANG data node is encoded according to
      XML Encoding Rules and Canonical Format for the specific
      YANG data node type defined in [draft-ietf-netmod-rfc6020bis].

"is encoded according to the XML Encoding Rules"...


  // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
  // section number for Security Considerations
  // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
  // RFC number, and remove this note.

   Security considerations: Security considerations related
      to the generation and consumption of RESTCONF messages
      are discussed in Section NN of [RFCXXXX].
      Additional security considerations are specific to the
      semantics of particular YANG data models. Each YANG module
      is expected to specify security considerations for the
      YANG data defined in that module.

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Interoperability considerations: [RFCXXXX] specifies format of
      conforming messages and the interpretation thereof.

"[RFCXXXX] specifies the format of"...


  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Published specification: RFC XXXX

   Applications that use this media type: Instance document
     data parsers used within a protocol or automation tool
     that utilizes YANG defined data structures.

"Instance document data parsers used within a protocol or automation tool
     that utilize YANG-defined data structures."

Change utilizes -> utilize. It's plural.

I think YANG-defined is correct due to being stacked noun phrases, or something.



   Fragment identifier considerations: The fragment field in the
      request URI has no defined purpose.

From the perspective of NETCONF this is probably correct. However, Section 4.11 of RFC 6838 says:

   Media types are encouraged to adopt fragment identifier schemes that
   are used with semantically similar media types.  In particular, media
   types that use a named structured syntax with a registered "+suffix"
   MUST follow whatever fragment identifier rules are given in the
   structured syntax suffix registration.

There are some things about +xml things:
http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

RFC 7303.

Look it up.

I don't have experience dealing with this, and I would not hold back the registration on that basis. The Expert Reviewer might.


   Additional information:

     Deprecated alias names for this type: n/a
     Magic number(s): n/a
     File extension(s): .xml
     Macintosh file type code(s): "TEXT"

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Person & email address to contact for further information: See
      Authors' Addresses section of [RFCXXXX].

   Intended usage: COMMON

   (One of COMMON, LIMITED USE, or OBSOLETE.)

You can remove the parenthetical. It's not part of the template instance.


   Restrictions on usage: n/a

RFC 6838 Section 5.6 says '"N/A", written exactly that way'. Stick with N/A (all-caps).


  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

   Author: See Authors' Addresses section of [RFCXXXX].

   Change controller: Internet Engineering Task Force
      (mailto:iesg&ietf.org).

   Provisional registration? (standards tree only): no

You can also remove the parenthetical. It's not part of the template instance.

Best regards,

Sean


On 6/28/2016 7:24 PM, Andy Bierman wrote:
Hi,

Please review and provide feedback on the revised media type registration
for the RESTCONF protocol.

https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.1


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--------------E768ED3CFACB771DBCC98671-- From nobody Tue Jun 28 20:23:41 2016 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 4E77912D9D7 for ; Tue, 28 Jun 2016 20:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZXYV8vdFUtq for ; Tue, 28 Jun 2016 20:23:38 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E15112D5A8 for ; Tue, 28 Jun 2016 20:23:36 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T3NFaq032367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 03:23:36 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 477D7509B6; Tue, 28 Jun 2016 23:23:15 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:22:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------19A5463E6705832C91FAC000" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 29 Jun 2016 03:23:36 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] request review of media type application/yang-data+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 03:23:39 -0000 This is a multi-part message in MIME format. --------------19A5463E6705832C91FAC000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit (Mostly a duplicate of application/yang-data+xml) Based on the discussion on media-types@ and netconf@ that I have observed, the registration is in pretty good substantive shape. I have no substantive comments except for the fragment identifier, which I understand is not of consequence to YANG processors. I won't repeat my comments from application/yang-data+xml. Therefore the only thing to talk about is the JSON fragment thing: On 6/28/2016 8:07 PM, Sean Leonard wrote: > For application/yang-data+json: > > ... > Fragment identifier considerations: The fragment field in the > request URI has no defined purpose. > As with application/yang-data+xml, you are supposed to match the +json fragment with how JSON works. RFC 6839 Section 3.1. But currently it (+json) doesn't do anything, in contrast to +xml, which does some stuff with XPointer. Regards, Sean --------------19A5463E6705832C91FAC000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
(Mostly a duplicate of application/yang-data+xml)

Based on the discussion on media-types@ and netconf@ that I have observed, the registration is in pretty good substantive shape. I have no substantive comments except for the fragment identifier, which I understand is not of consequence to YANG processors. I won't repeat my comments from application/yang-data+xml. Therefore the only thing to talk about is the JSON fragment thing:

On 6/28/2016 8:07 PM, Sean Leonard wrote:
For application/yang-data+json:

...
   Fragment identifier considerations: The fragment field in the
      request URI has no defined purpose.
  

As with application/yang-data+xml, you are supposed to match the +json fragment with how JSON works. RFC 6839 Section 3.1. But currently it (+json) doesn't do anything, in contrast to +xml, which does some stuff with XPointer.

Regards,

Sean
--------------19A5463E6705832C91FAC000-- From nobody Tue Jun 28 20:23:50 2016 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 AAC1912D9E7 for ; Tue, 28 Jun 2016 20:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruwlChTr0scF for ; Tue, 28 Jun 2016 20:23:46 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C63312D9E4 for ; Tue, 28 Jun 2016 20:23:46 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T3NPIl007601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 03:23:46 GMT Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by fallback-in2.mxes.net (Postfix) with ESMTP id 5439C2FDD3B for ; Tue, 28 Jun 2016 23:07:27 -0400 (EDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3C212509B6; Tue, 28 Jun 2016 23:06:44 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:06:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:15:59 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Wed, 29 Jun 2016 03:23:46 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] request review of media type application/yang-data+xml X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 03:23:49 -0000 It is considered customary to copy and paste *just* the registration text in this mailing list. Here you go: Type name: application Subtype name: yang-data+xml Required parameters: none Optional parameters: none // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with // the actual RFC reference for YANG 1.1, and remove this note. Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilizes YANG defined data structures. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .xml Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON (One of COMMON, LIMITED USE, or OBSOLETE.) Restrictions on usage: n/a // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no On 6/28/2016 7:24 PM, Andy Bierman wrote: > Hi, > > Please review and provide feedback on the revised media type registration > for the RESTCONF protocol. > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.1 > From nobody Tue Jun 28 20:24:10 2016 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 A7FDB12D5A8 for ; Tue, 28 Jun 2016 20:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBVw7_MEwVFC for ; Tue, 28 Jun 2016 20:24:07 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BB012D0E6 for ; Tue, 28 Jun 2016 20:24:07 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u5T3Nkha025584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 03:24:06 GMT Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by fallback-in2.mxes.net (Postfix) with ESMTP id BECBA2FDD5A for ; Tue, 28 Jun 2016 23:08:30 -0400 (EDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5D8C6509B5; Tue, 28 Jun 2016 23:07:49 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:07:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Wed, 29 Jun 2016 03:24:06 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] request review of media type application/yang-data+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 03:24:08 -0000 For application/yang-data+json: Type name: application Subtype name: yang-data+json Required parameters: none Optional parameters: none // RFC Ed.: replace draft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace draft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [draft-ietf-netmod-yang-json]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata] // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilizes YANG defined data structures. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .json Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON (One of COMMON, LIMITED USE, or OBSOLETE.) Restrictions on usage: n/a // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no On 6/28/2016 7:27 PM, Andy Bierman wrote: > Hi, > > Please review and provide feedback on the revised media type registration > for the RESTCONF protocol. > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-11.3.2 > From nobody Tue Jun 28 20:25:06 2016 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 D880E12D9E5 for ; Tue, 28 Jun 2016 20:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxx1KLYRnahu for ; Tue, 28 Jun 2016 20:25:03 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413BA12D9E4 for ; Tue, 28 Jun 2016 20:25:03 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T3OgD7032420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 03:25:03 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B113509B5; Tue, 28 Jun 2016 23:24:42 -0400 (EDT) To: xml2rfc@ietf.org From: Sean Leonard Message-ID: Date: Tue, 28 Jun 2016 20:24:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 29 Jun 2016 03:25:03 +0000 (UTC) Archived-At: Cc: "media-types@iana.org" Subject: [media-types] Filling out templates in XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 03:25:05 -0000 Just curious if people have thought about using XML elements to fill out = templates, in xml2rfc, rather than sticking the template instance in an=20 artwork blob. Consider (which I just reviewed).=20 In #media-types, the RFC 6838 templates are instantiated as artwork.=20 Wouldn't it be better to put the things in some basic XML blocks? I have = seen very long registration templates elsewhere, like URNs and URIs,=20 that can spill over to multiple pages. It would be helpful if these=20 could be treated (at least in part) as regular runs of text so that they = are subject to page breaking automatically, etc. There is a temptation to over-specify the details of every registration=20 template. Perhaps a quick survey could be done, to see some common=20 IETF/IANA registration templates, and if there is enough common to them=20 to permit a small handful of elements. 6 elements or less, I would say.=20 For example: application yang-data+xml none ... Security considerations rel= ated to the generation and consumption of RESTCONF messages are discussed in Section NN of . Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. blah blah blah at end of instance That yields 3 elements: instance, field, and additional. An alternate approach is to have some XML namespace/schema and embed it=20 in a
, similar to (in ) and . Could=20 get needlessly complex, but would limit arbitrary placement. Depends on=20 whether one feels that registration templates need to be in
=20 elements or not. I believe that template instances can be part of the=20 main specification text (first, because template instances can contain=20 normative specification language; second, because it's possible that=20 template fields might have figures inside); therefore, they should not=20 be required to be in
elements. Just my 2=C2=A2. Sean From nobody Tue Jun 28 22:33:05 2016 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 DD19912D1D7 for ; Tue, 28 Jun 2016 22:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuWJ-taT-Mbq for ; Tue, 28 Jun 2016 22:33:02 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5712012DA54 for ; Tue, 28 Jun 2016 22:33:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T5WeAL009625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 05:33:01 GMT Received: from [192.168.178.20] ([93.217.103.248]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfRnb-1axPJ33Pnn-00P4XC; Wed, 29 Jun 2016 07:18:10 +0200 To: Sean Leonard , xml2rfc@ietf.org References: From: Julian Reschke Message-ID: <5f7d616d-0904-2c63-222a-dbb3a0ebd118@gmx.de> Date: Wed, 29 Jun 2016 07:18:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CLYUutvCMMKBUjV6b5MaiIEcIpo/zTUpZmYiAWHfmMQ0N+XUovT chtLKEUq69+xtMi/7ebeNXUNQ65wSSmM8wASkzKVR1i86VCBg8TG9Fx0ogUTdssmSUCDHpq gsQ8WmFU2WPed17HdaX/3FfsaHBySqXx8s06AebwOOO9cFNSkYNH2KH8kbe2qfCC7MuKWVs A2rCIFC7kDerkdCL8fZlg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ntTwrbfLPEE=:gmSJqswxHouJML4jA3Vpk8 X2T8VV8hVPVxZ20vkNb9euT4GooFVU6jrjvYbrAK+cYc0v5fn4Q8Z3bjeYAmUc+HDOoKiYPqK zTyVc654FL1KNVxv841Ybjrr+1q4QjAtZ3kFCcGWp2fkl8KJbHTHfodFQIQTnnN57rA8MHWMh IjQrkUvylaDsYRnVwRhPZ0VnOnRxrYZREcVgLH0E7PP8CgJS1vltI/fBCAg/hzCDNHwscQsJA I5uE1tEOfhKf5CbMU9yV4ChzKedP6KAXDBa795A9mRj3UAQkGZQdikWC3/85lq0/1rr6cmR2W Bl8wgUprwGuKT820Kkv0ZZlTAiVewWkc4C+aSY2qpOzCjaPdrtni4FPmekqcf3K+6l1J4Yy1b Sr6HTuee/jtZPFj97zqQLhYG1FcF5ELap96/zXysdFk9cu6trTZSoGa1Je4YHk8KGZqS321i7 tWk09XAgynonbx3ZuWhcObYWSwQXQHAX4DaBTgH7/Fv/3YbYn9llVPkMkmKnMDogjnuTlQVzB Y62cCz0r797FCuFEJDaQaUbrmUWJAh2FiwsN8GQLKi7OwURiuF21di7Bf9DZNwvtuoWfjtFo3 W9YrfP901VTdGTqmaqBVGSYlMmRW61opgwkj6yYUMeBqEskEsurs5PnRvAK8vvJZSet+ZwmJx CMeMLewRz/Lo13IkVwZbjBrVhDmlxybLdRm1bLFS64Vhzka088SCjwq9oKu9GZOcRbDGI0RuN pMDNMtSKlvF1DPwEsqhLFQfnEiyWRocq3VHLKPe5+J/9/Xi31pXBIx5dfJcYaNGdiP1V9SHzM //Xsn1y X-Greylist: Delayed for 00:14:17 by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 29 Jun 2016 05:33:02 +0000 (UTC) Archived-At: Cc: "media-types@iana.org" Subject: Re: [media-types] Filling out templates in XML X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 05:33:04 -0000 On 2016-06-29 05:24, Sean Leonard wrote: > Just curious if people have thought about using XML elements to fill out > templates, in xml2rfc, rather than sticking the template instance in an > artwork blob. > ... I have always put registrations either into tables or lists. I agree that using artwork is a very bad thing. Best regards, Julian From nobody Wed Jun 29 01:03:32 2016 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 4446612DA31 for ; Wed, 29 Jun 2016 01:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHLynoh-wWIG for ; Wed, 29 Jun 2016 01:03:27 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7200812DA0B for ; Wed, 29 Jun 2016 01:03:27 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u5T835n3010365 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2016 08:03:27 GMT Received: from aclermont-ferrand-654-1-652-57.w90-9.abo.wanadoo.fr ([90.9.172.57] helo=w3.org) by raoul.w3.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bI9lV-0003KW-2Q; Wed, 29 Jun 2016 07:18:29 +0000 Date: Wed, 29 Jun 2016 03:18:27 -0400 From: "Eric Prud'hommeaux" To: media-types@iana.org Message-ID: <20160629071825.GA6722@w3.org> References: <7e7f0fbfcf7645d3a841a23028408f7c@exch1-mel.nexus.csiro.au> <20160622143026.GC7225@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160622143026.GC7225@w3.org> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Delayed for 00:44:36 by milter-greylist-4.0 (pechora1.lax.icann.org [IPv6:2620:0:2d0:201::1:71]); Wed, 29 Jun 2016 08:03:27 +0000 (UTC) Archived-At: Cc: public-rdf-dawg-comments@w3.org Subject: [media-types] Resend: request for review: application/sparql-results+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 08:03:29 -0000 I didn't see this come through, possibly because I sent it To:ietf-types@alvestrand.no Hi all, at W3C, we try to request a media type when a document reaches candidate recommendation. In this case, we missed my a mere three years. accurately documents our good intentions... Type name: application Subtype name: sparql-results+json Required parameters: None Optional parameters: None Encoding considerations: The encoding considerations of the SPARQL Query Results JSON Format is identical to those of the "application/json" as specified in [JSON-RFC]. Security considerations: SPARQL query results uses URIs. See Section 7 of [RFC3986]. SPARQL query results uses IRIs. See Section 8 of [RFC3987]. The security considerations of the SPARQL Query Results JSON Format is identical to those of the "application/json" as specified in [JSON-RFC]. Interoperability considerations: There are no known interoperability issues. Published specification: http://www.w3.org/TR/sparql11-results-json/ Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): n/a File extension(s): ".srj" Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Andy Seaborne Intended usage: COMMON Restrictions on usage: None Author/Change controller: The SPARQL specification is a work product of the World Wide Web Consortium's SPARQL Working Group. The W3C has change control over these specifications. -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper. From nobody Thu Jun 30 17:53:12 2016 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 5E29212D0BC for ; Thu, 30 Jun 2016 17:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRgmnytozEkP for ; Thu, 30 Jun 2016 17:53:10 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3445612D0B9 for ; Thu, 30 Jun 2016 17:53:05 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u610qiP2018011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jul 2016 00:53:04 GMT Received: by mail-vk0-x22a.google.com with SMTP id k68so47170546vkb.0 for ; Thu, 30 Jun 2016 17:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ub6sle6XlmbNaQnLZTeCVXNsFF1ZwTYL7DlQnn0wSI=; b=trxESyUHGHxjtxajTHzYZQQZy7tZe0zPkkisUX8XVzfutmt9Uk/D2xQLz1kKPocS0b KOviJ6lkd2fDRgArveTJBBM3uX6UQDZtB0TKcne4YdmUHoBbGcGDk91zrv8xR2EXIKCd Y+gIvtsuWOSoiFoBb3FjlJw8X37NjiA6dlTDouhAJNjNwpNaWfYN9sJJeaPE61ytEpnU M0+bPizVS2S/dw+N7jtIzztFfBxMPmZnsA0ZaRIcWKUZiciClxXwAdDNXmT1IIw76mPu r2wMc1ogy8zVJj38gs8wOQ8iqlu9vZuGWvraE/wSitRPIR3IH5yDaBSqoBhgRYSAx805 bE3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ub6sle6XlmbNaQnLZTeCVXNsFF1ZwTYL7DlQnn0wSI=; b=dESoo5hf7daQ3n95bHxwaSH9DF1EzpTpLKdrKQobrFc6FSFA0MrZ+sOEQPsCpvw8dm Fs0KXpDrMdM0UdlWSVQ/6m7nzpTT4BAtzoSp8R6HD7QL0rMyYcCxC5hh9ya7/nTpuLaD mD/vIVKwuVDCrfD01BEqoArQCh8baeyfeTHHW+LOPgGxGXGFKBqzUWnc4fuZ4oe8BPZ8 cIGgonGc6/+ilZJ1cjOnrDJS98tx9uDcGS4Psl7kB9psZdxSgS6GZO1/L4kQkP/dcAQL UZW5TC8ADLehp2Bzn+YjT2lpaMgyVArC2w8pkdEM+qW3BzjuS/xEOsjPxlIHYb6U6ut/ N4qg== X-Gm-Message-State: ALyK8tJeAf4F6BR86+0nw9CeZfpFYURrl6jas8ji/LWZG9Uf7+qoQCRQtlSgTEYP7/T4cusJLkSeDUhsWC4QRA== X-Received: by 10.31.9.65 with SMTP id 62mr8158541vkj.89.1467334364043; Thu, 30 Jun 2016 17:52:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Thu, 30 Jun 2016 17:52:43 -0700 (PDT) In-Reply-To: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> From: Andy Bierman Date: Thu, 30 Jun 2016 17:52:43 -0700 Message-ID: To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11440b648933c105368867f8 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [IPv6:2620:0:2d0:201::1:73]); Fri, 01 Jul 2016 00:53:05 +0000 (UTC) Archived-At: Cc: media-types@iana.org, Netconf Subject: Re: [media-types] [Netconf] request review of media type application/yang-data+xml X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jul 2016 00:53:11 -0000 --001a11440b648933c105368867f8 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 28, 2016 at 8:17 PM, Sean Leonard wrote: removing all text except the fragment identifier issue.... According to RFC 7303, sec. 5, any usage of +xml requires implementation of the XPointerFramework https://www.w3.org/TR/2003/REC-xptr-framework-20030325/ RESTCONF "fragments" are sub-trees within the YANG data structures. These are accessed by the request URI path and the "fields" query parameter. XPointer is rather complex and completely redundant for RESTCONF. So do we have to add text that a RESTCONF server MUST implement the "element" scheme? > > > Fragment identifier considerations: The fragment field in the > request URI has no defined purpose. > > > From the perspective of NETCONF this is probably correct. However, Section > 4.11 of RFC 6838 says: > > Media types are encouraged to adopt fragment identifier schemes that > are used with semantically similar media types. In particular, media > types that use a named structured syntax with a registered "+suffix" > MUST follow whatever fragment identifier rules are given in the > structured syntax suffix registration. > > > There are some things about +xml things: > > http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml > > RFC 7303. > > Look it up. > > The syntax and semantics of fragment identifiers for the XML media types defined in this specification are based on the [XPointerFramework ] W3C Recommendation. It allows simple names and more complex constructions based on named schemes. When the syntax of a fragment identifier part of any URI or Internationalized Resource Identifier (IRI) ([RFC3987 ]) with a retrieved media type governed by this specification conforms to the syntax specified in [XPointerFramework ], conforming applications MUST interpret such fragment identifiers as designating whatever is specified by the [XPointerFramework ] together with any other specifications governing the XPointer schemes used in those identifiers that the applications support. Conforming applications MUST support the 'element' scheme as defined in [XPointerElement ], but need not support other schemes. Registrations which use this '+xml' convention MUST also make reference to [RFC7303 ], specifically Section 5, in specifying fragment identifier syntax and semantics, and they MAY restrict the syntax to a specified subset of schemes, except that they MUST NOT disallow barenames or 'element' scheme pointers. They MAY further require support for other registered schemes. They also MAY add additional syntax (which MUST NOT overlap with [XPointerFramework ] syntax) together with associated semantics, and MAY add additional semantics for barename XPointers which, as provided for in Section 5, will only apply when [RFC7303 ] does not define an interpretation. In practice these constraints imply that for a fragment identifier addressed to an instance of a specific "xxx/yyy+xml" type, there are three cases: For fragment identifiers matching the syntax defined in [XPointerFramework ], where the fragment identifier resolves per the rules specified there, then process as specified there; For fragment identifiers matching the syntax defined in [XPointerFramework ], where the fragment identifier does _not_ resolve per the rules specified there, then process as specified in "xxx/yyy+xml"; For fragment identifiers _not_ matching the syntax defined in [XPointerFramework ], then process as specified in "xxx/ yyy+xml". A fragment identifier of the form "xywh=160,120,320,240", as defined in [MediaFrags ], which might be used in a URI for an XML-encoded image, would fall in this category. See Section 10, [RFC7303 ]. > I don't have experience dealing with this, and I would not hold back the > registration on that basis. The Expert Reviewer might. > > Andy --001a11440b648933c105368867f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 28, 2016 at 8:17 PM, Sean Leonard <dev+ietf@seantek.com= > wrote:



removing all text except the fragment identifier issue....

<= /div>
According to RFC 7303, sec. 5, any usage of +xml requires impleme= ntation of
the XPointerFramework

RESTCONF "= fragments" are sub-trees within the YANG data structures.
Th= ese are accessed by the request URI path and the "fields" query p= arameter.
XPointer is rather complex and completely redundant for= RESTCONF.

So do we have to add text that a RESTCO= NF server MUST implement the "element"
scheme?




=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">


=C2=A0=C2=A0 Fragment identifier considerations: The fragment field i= n the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 request URI has no defined purpose.

From the perspective of NETCONF this is probably correct. However, Section 4.11 of RFC 6838 says:

   Media types are encouraged to adopt frag=
ment identifier schemes that
   are used with semantically similar media types.  In particular, media
   types that use a named structured syntax with a registered "+suffix=
"
   MUST follow whatever fragment identifier rules are given in the
   structured syntax suffix registration.

There are some things about +xml things:
http://www.iana.org/assi= gnments/media-type-structured-suffix/media-type-structured-suffix.xhtml=

RFC 7303.

Look it up.





   The syntax and semantics of fragment identifiers for the XML media
   types defined in this specification are based on the
   [X=
PointerFramework] W3C Recommendation.  It allows simple names and
   more complex constructions based on named schemes.  When the syntax
   of a fragment identifier part of any URI or Internationalized
   Resource Identifier (IRI) ([RFC=
3987]) with a retrieved media type
   governed by this specification conforms to the syntax specified in
   [X=
PointerFramework], conforming applications MUST interpret such
   fragment identifiers as designating whatever is specified by the
   [X=
PointerFramework] together with any other specifications governing
   the XPointer schemes used in those identifiers that the applications
   support.  Conforming applications MUST support the 'element' sch=
eme
   as defined in [XPointerElement], but need not support other schemes.
<= pre class=3D"" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0p= x;color:rgb(0,0,0)">





<=
td style=3D"padding-left:0.5em;padding-right:0.5em;vertical-align:top">See =
Section 10, [RFC7303].



Registrations which use this '+xml&#=
39; convention MUST also make reference to [RFC7303], specifically Section 5, in specifying fragment id=
entifier syntax and semantics, and they MAY restrict the syntax to a specif=
ied subset of schemes, except that they MUST NOT disallow barenames or '=
;element' scheme pointers. They MAY further require support for other r=
egistered schemes. They also MAY add additional syntax (which MUST NOT over=
lap with [XPointerFramework] syntax) together with associated semantics, and MA=
Y add additional semantics for barename XPointers which, as provided for in=
 Section 5, will only apply when [RFC7303] does not define an interpretation.
In practice these constraints imply that for a fragment identifie=
r addressed to an instance of a specific "xxx/yyy+xml" type, ther=
e are three cases:
For fragment identifi=
ers matching the syntax defined in [XPointerFramework], where the fragment iden=
tifier resolves per the rules specified there, then process as specified th=
ere;
For fragment identifiers matching t=
he syntax defined in [XPointerFramework], where the fragment identifier does _n=
ot_ resolve per the rules specified there, then process as specified in &qu=
ot;xxx/yyy+xml";
For fragment ident=
ifiers _not_ matching the syntax defined in [XPointerFramework], then process a=
s specified in "xxx/ yyy+xml". A fragment identifier of the form =
"xywh=3D160,120,320,240", as defined in [MediaFrags], which might be use=
d in a URI for an XML-encoded image, would fall in this category.



=C2=A0
I don't have experience dealing with this, and I would not hold bac= k the registration on that basis. The Expert Reviewer might.




Andy
=

--001a11440b648933c105368867f8--