From nobody Fri Jul 1 01:31: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 E488112D1F0 for ; Fri, 1 Jul 2016 01:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cnT3TyehgsIS for ; Fri, 1 Jul 2016 01:31: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 6AD3012B009 for ; Fri, 1 Jul 2016 01:31:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u618Uo8E024400 for ; Fri, 1 Jul 2016 08:31:11 GMT Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 47D5F1AE0398; Fri, 1 Jul 2016 10:30:48 +0200 (CEST) Date: Fri, 01 Jul 2016 10:31:13 +0200 (CEST) Message-Id: <20160701.103113.301947010745595267.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 01 Jul 2016 08:31:11 +0000 (UTC) Archived-At: Cc: media-types@iana.org, dev+ietf@seantek.com, netconf@ietf.org 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 08:31:13 -0000 Andy Bierman 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/ Actually, it says SHOULD: If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, it SHOULD NOT follow the naming convention '+xml'. > 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. I'm not sure the "element()" scheme is complex to implement. The "fields" query parameter probably takes more effort to implement. Note though that the "fields" query parameter is more expressive than the "element()" scheme, and it works with other encodings than XML. *if* we were to use XPointer instead of "fields", what would we do for JSON? > So do we have to add text that a RESTCONF server MUST implement the > "element" > scheme? If this indeed is to be interpreted as a requirement, I'd rather not use the "+xml" name. /martin From nobody Tue Jul 5 08:28: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 8E26412D11F for ; Tue, 5 Jul 2016 08:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 mtls9LBUp12Z for ; Tue, 5 Jul 2016 08:28: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 18F6712D11B for ; Tue, 5 Jul 2016 08:28:52 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u65FSV2T018897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jul 2016 15:28:51 GMT Received: by mail-pa0-x22e.google.com with SMTP id b13so68365691pat.0 for ; Tue, 05 Jul 2016 08:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=53jIqXMIGEN9bZ3VBPuKJ0eHazKD1RGJ8vCioUa2bfM=; b=Buje4QQxp5hQcgJVn5TzVVKa00oEOKAJqY8hPQJmwpJ6rkzVAfWTAhcsSxFLNWBNxB ZNiDMq2fXtroIFH+lc9RNKhmbzQ6XgpDnMkKi38/IAZsKQih5XuuuKe23RT4F0npCQGe Sr+vHcgP5xoO9GBmjokm8j13TYps2fFXMMtjCStQycc/4vPIOretTj1syZzmum25MI4w J+JPfszBRIHLBNLbIhj0xBW8PyU94+DrTif0fIwlQDuUOomIyxNtPag6uAN+6nPGkXBr Pm2Vp4zpYylRo/Oqf400z3OiZBFQ2YjFt8dbDoMbfSmhpIp9yR2szePB+/9I4waDivaD zB+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=53jIqXMIGEN9bZ3VBPuKJ0eHazKD1RGJ8vCioUa2bfM=; b=bCAbOFAbBcwMg2mHb+cwyXivqWfoV8tn16XOjBD7CTODQeAcYjmURJIYf5EKnq1/Ni CvgiH0/K5FHXlWxfE/7W9tZJ/wCKq+UwU9O8CAzw0IOQrZjfHD3i/VNaYpYuh0mjt0qF iNowozuFHOBVMYbLfOvwdtWPf55a+kXehgPQISHyTf/aWmdH88fDTPy2vfKnXJNkVsVz iv+n5TW9Ls5759wQWj6QKSagdIvRg300KPK9+LV4+FGmQXyZY7QkuRPkM8pf7AaJvCPh 9CTibiPm06p6tuec04SZJXPc2vsFsUpdWgSXYnCNH31N8pfiRJPc21PzcJ2aDWc84OL3 yi3A== X-Gm-Message-State: ALyK8tIfFd7T63lZ5XebBpB9QCdBEbyFNeBJf+QGlCrQCZnt9dtXMEYgiUOd732BiO6Udw== X-Received: by 10.66.233.103 with SMTP id tv7mr33005215pac.46.1467732511372; Tue, 05 Jul 2016 08:28:31 -0700 (PDT) Received: from [10.24.36.136] ([128.107.241.171]) by smtp.gmail.com with ESMTPSA id d2sm5846407pfk.36.2016.07.05.08.28.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jul 2016 08:28:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Tue, 5 Jul 2016 08:28:25 -0700 Message-Id: References: To: Netconf , media-types@iana.org X-Mailer: Apple Mail (2.3124) 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]); Tue, 05 Jul 2016 15:28:52 +0000 (UTC) Archived-At: Cc: Andy Bierman Subject: Re: [media-types] [Netconf] 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: Tue, 05 Jul 2016 15:28:53 -0000 --Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andy requested a review on the update to media type registration for = YANG patch. Note, there are two reviews, one for XML and another one for = JSON. Unless we hear otherwise by end of this week, we will go ahead with the = suggested changes. Thanks. > On Jun 28, 2016, at 7:29 PM, Andy Bierman wrote: >=20 > Hi, >=20 > 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. >=20 >=20 > = https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1= = >=20 >=20 > thanks, > Andy Mahesh & Mehmet --Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Andy requested a review on the update to media type = registration for YANG patch. Note, there are two reviews, one for XML = and another one for JSON.

Unless we hear otherwise by end of this week, we will go = ahead with the suggested changes.

Thanks.
On = Jun 28, 2016, at 7:29 PM, Andy Bierman <andy@yumaworks.com> = wrote:

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#se= ction-4.2.1


thanks,
Andy

Mahesh & Mehmet





= --Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945-- From nobody Tue Jul 5 09:58:08 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 797AE12D128 for ; Tue, 5 Jul 2016 09:58:06 -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 5EQp2qMC1Tug for ; Tue, 5 Jul 2016 09:58:04 -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 C4A6212D16F for ; Tue, 5 Jul 2016 09:58:04 -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 u65GviOA019112 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jul 2016 16:58:04 GMT Received: by mail-vk0-x230.google.com with SMTP id m127so212888767vkb.3 for ; Tue, 05 Jul 2016 09:58: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=8zW7yRijyJzhku/hHyQjFeOCWtm1ByB4aSO84WHT9Og=; b=zM74Xwix1weFhlwmmps0e+bPxw5+YgqnOyKY6/IZZ4VK6oaJWRicb7wCEpUnxpMuwW xFKneVhFe2v9Cmh/iiN8lF+0rr3ICvUMojGg2WKT+ksMwnnK1XTdQoqpILZzQJjfktAN je85NJoOhscDcwREPXx6zs9D8YqF91p/Kd2zGRJoeEueOQdtCVoJb6NF2kqaggqet6rs WrcXvI4nkF5Sc+lSv1JjWf9tfR3Hv6Xbk/kMsMbO+68aAQee2qN03EBU4fGWrnhCQgPs MfhYzbjXe45Gq5b5eaKie6mQJTohxoYXYVhC5RLYUbRSoc0TRKlITqcmTbjzmx/h97mK 5jmg== 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=8zW7yRijyJzhku/hHyQjFeOCWtm1ByB4aSO84WHT9Og=; b=Coj4LOvCLS9ELTuRmAc1PjLVkBz0d+6WirTLhjaDhIQ74bKOtMpTNz9USyn4os93Yn fOpUXYfoCgTezHouR1PPQG0hcgImP3ZSvjm6iCHYBUTSSNEuj1G5CzCjXETaqP+zkJku 2pvNR0wOXEmY/uKB/cyYeLKUPEw10+JuN49Ex3Yj9BP1YAyir7odeIymM1A5RfENDAzP UGHkxz+Ire46/1am7YZC98PqSYOIAAHUd4HQ9WISdND99aL7JSa4CC1d11xSwMx50tYn qlVt+fHKZ+hGLod1YfAJh7U0UK4LmJtSyyWbiW769owssYQ/inzdRmgeQGS14ejkn6kR kmpQ== X-Gm-Message-State: ALyK8tKMgSLf7RfdOr4//yuyz+01iyyNBLBX6agXZ7arm8848ZJiYCzrB5Ma5CIwYyrIfToAgp3rg3Gvxn9kRQ== X-Received: by 10.31.60.204 with SMTP id j195mr7766855vka.132.1467737863619; Tue, 05 Jul 2016 09:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 5 Jul 2016 09:57:42 -0700 (PDT) In-Reply-To: <20160701.103113.301947010745595267.mbj@tail-f.com> References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> <20160701.103113.301947010745595267.mbj@tail-f.com> From: Andy Bierman Date: Tue, 5 Jul 2016 09:57:42 -0700 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1142fff0fc477b0536e659e1 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, 05 Jul 2016 16:58:04 +0000 (UTC) Archived-At: Cc: media-types@iana.org, Sean Leonard , 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: Tue, 05 Jul 2016 16:58:06 -0000 --001a1142fff0fc477b0536e659e1 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 1, 2016 at 1:31 AM, Martin Bjorklund wrote: > Andy Bierman 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/ > > Actually, it says SHOULD: > > If [XPointerFramework] and [XPointerElement] are inappropriate for > some XML-based media type, it SHOULD NOT follow the naming convention > '+xml'. > > > 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. > > I'm not sure the "element()" scheme is complex to implement. The > "fields" query parameter probably takes more effort to implement. > > Note though that the "fields" query parameter is more expressive than > the "element()" scheme, and it works with other encodings than XML. > *if* we were to use XPointer instead of "fields", what would we do for > JSON? > IMO it would be a bad idea to have media-specific filtering. YANG provides an abstraction of datastore contents which we want to be independent of the various query response representations found in protocol messages. We are filtering on the datastore contents, not on the XML representation of individual query responses. > > So do we have to add text that a RESTCONF server MUST implement the > > "element" > > scheme? > > If this indeed is to be interpreted as a requirement, I'd rather not > use the "+xml" name. > > Are there any objections to dropping the +xml? What about dropping +json as well? http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml This page implies our "fields" parameter MUST NOT overlap with XPointer. > /martin > Andy --001a1142fff0fc477b0536e659e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 1, 2016 at 1:31 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> removing all text except the fragment identifier issue....
>
> According to RFC 7303, sec. 5, any usage of +xml requires implementati= on of
> the XPointerFramework
> https://www.w3.org/TR/2003/REC-xptr-fram= ework-20030325/

Actually, it says SHOULD:

=C2=A0 =C2=A0If [XPointerFramework] and [XPointerElement] are inappropriate= for
=C2=A0 =C2=A0some XML-based media type, it SHOULD NOT follow the naming con= vention
=C2=A0 =C2=A0'+xml'.

> RESTCONF "fragments" are sub-trees within the YANG data stru= ctures.
> These are accessed by the request URI path and the "fields" = query parameter.
> XPointer is rather complex and completely redundant for RESTCONF.

I'm not sure the "element()" scheme is complex to implement.= =C2=A0 The
"fields" query parameter probably takes more effort to implement.=

Note though that the "fields" query parameter is more expressive = than
the "element()" scheme, and it works with other encodings than XM= L.
*if* we were to use XPointer instead of "fields", what would we d= o for
JSON?


IMO it would be a = bad idea to have media-specific filtering.
YANG provides an abstr= action of datastore contents which we want to be independent
of t= he various query response representations found in protocol messages.
=

We are filtering on the datastore contents, not on the = XML representation
of individual query responses.

<= /div>


> So do we have to add text that a RESTCONF server MUST implement the > "element"
> scheme?

If this indeed is to be interpreted as a requirement, I'd rather not use the "+xml" name.



Are there any objections to dropping the +x= ml?

What about dropping +json as well?
<= br>

This page implies our "fields" paramete= r MUST NOT overlap with XPointer.



/martin


<= /div>
Andy

--001a1142fff0fc477b0536e659e1-- From nobody Tue Jul 5 20: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 4C31A12D155 for ; Tue, 5 Jul 2016 20:35: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 uttrFOMBwhse for ; Tue, 5 Jul 2016 20:35:46 -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 DADC912D12E for ; Tue, 5 Jul 2016 20:35:45 -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 u663ZONB023512 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2016 03:35:45 GMT Received: from [192.168.123.110] (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 2EB11509B6; Tue, 5 Jul 2016 23:35:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <5f7d616d-0904-2c63-222a-dbb3a0ebd118@gmx.de> Date: Tue, 5 Jul 2016 20:35:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36838BD3-74DA-4990-BE02-6088B5C3BCEE@seantek.com> References: <5f7d616d-0904-2c63-222a-dbb3a0ebd118@gmx.de> To: Julian Reschke 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]); Wed, 06 Jul 2016 03:35:45 +0000 (UTC) Archived-At: Cc: xml2rfc@ietf.org, "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, 06 Jul 2016 03:35:47 -0000 > On Jun 28, 2016, at 10:18 PM, Julian Reschke = wrote: >=20 > 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. >> ... >=20 >=20 > I have always put registrations either into tables or lists. I agree = that using artwork is a very bad thing. >=20 Okay. How can we move forward on a proposal? * figure out what features we want (suggested: kind of like
in HTML, in that it=E2=80=99s embedded = in the source text. The idea is that the style of the or whatever could be put together by tools so = that it looks appropriate for the data.) * figure out what elements needed * new sections in xml2rfc v3 about elements * update Relax NG schema Main thing at a high level is: is it preferable to embed elements from = another namespace (like does) or make elements in xml2rfc? I think = the latter because the text inside template instances should be treated = like specification text (searchable, etc.). Best regards, Sean= From nobody Tue Jul 5 23:54:08 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 D01B312D67F for ; Tue, 5 Jul 2016 23:54:06 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bwMEJn7TRzN7 for ; Tue, 5 Jul 2016 23:54:05 -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 D013B12D67E for ; Tue, 5 Jul 2016 23:54:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u666rhFI009961 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2016 06:54:05 GMT Received: from [192.168.178.20] ([93.217.107.87]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8e5P-1bYetj06Rn-00wGYS; Wed, 06 Jul 2016 08:53:32 +0200 To: Sean Leonard References: <5f7d616d-0904-2c63-222a-dbb3a0ebd118@gmx.de> <36838BD3-74DA-4990-BE02-6088B5C3BCEE@seantek.com> From: Julian Reschke Message-ID: <9344f489-528b-6963-ebd8-f18cccac7ca7@gmx.de> Date: Wed, 6 Jul 2016 08:53:37 +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: <36838BD3-74DA-4990-BE02-6088B5C3BCEE@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZgOE11g5iXDw6b2uZtq4UtKoYxpsmSHSU1xmuPsZERnyhX2j3Ml 6jOXlhWDtBIgYOMNHgpAeB7oUc5+YGv3esM1qkvliMVkZOKuQq8sgDqO5XiEcTyR2uDJfxh O5nHsZfufzom/QNIAzcxBat/760t09mFasv21hWb7P5wODJlRqI+nDsHnQ67hif3M4LV+2t WUGekNXTv0xdVvmOtNLBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:kArHOYd+c+A=:/jqxW9kHKJY+0ugAgkp3Qc jVE8QAUPrnxRWzU83uE8rPnNfPv43a/7DhY05JvqhwquY6tUAPynRkMP4/ikTBQSokyF69r++ ALc8MmCwfNmV+cGRdi8PnNWZ9hSYBAeIYMABp4ZfBQjb4Nvx+WiZD/UhyjfV9YIw0v0PdpUx2 9pUw+F5n+FdF3u7LrpFYh6PJuV6pJmTy/tJsvwUXSdMgWP2cxzRky998KmgqBNhyf4DOicqqT 9Dlo8/T14Ossn6iZvAlpKxFtzdj/iKk5EcKrDX6yC1H7WX4PT+TYULiPkx3P2eoY/WvRSqC1O s+QMlNNTSFrrSY2YVSEAYsdMOrTkukX9qgp1y53ZDiRZ5ewQFnCjy22QUQ3RhWCtSHzXHizUQ IkkLmiu+rAHlEX1E07PnE/JbM3B5fH0oRpYEEf9r5QpNG98spsJ1tbxYbiNJfrDEU5apPrt5a zzgwMVPIG08SdelFnruN+8Ab9AM7zV6yIdhODE3FaNJydicAdN4+rT4WzcJfoephCtJJsO4i+ kiRAswPwOA/5Ep3nlrQ9FGCIU81YO0J5yTBb+yXkxSOC6Uwbn4atRDT84qNUMwEzCFVtkMHly 6/B30COswUvoBAcWfZOsnBGfGZUMfI0Lw0/S3lpGhVA7qGvLf9V+XkdAyOvUQ/tb39vtYCBJS xm4BALRU0VIfldX1MV/zH0GGanMQLWsuVgBz6f/q3p5PpUzjN0gzWpnnvVXr+/MFVb+pvvV3B 7UaODnGvdMR9k7+0x0reu6zyswTWXbOFjMuyas+v0Jka2kqYgYBjnWDW65cRqxsm73K2vkMBZ qFnd21s X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Wed, 06 Jul 2016 06:54:05 +0000 (UTC) Archived-At: Cc: xml2rfc@ietf.org, "media-types@iana.org" Subject: Re: [media-types] [xml2rfc] 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, 06 Jul 2016 06:54:07 -0000 On 2016-07-06 05:35, Sean Leonard wrote: > >> On Jun 28, 2016, at 10:18 PM, Julian Reschke wrote: >> >> 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. >> > > Okay. How can we move forward on a proposal? > ... My point being that no new elements are needed. Could you explain why what's there (or is in v3) isn't sufficient? Best regards, Julian From nobody Wed Jul 6 11:54: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 6DED612D5AA for ; Wed, 6 Jul 2016 11:54:42 -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 qkpdhgi6QNtD for ; Wed, 6 Jul 2016 11:54: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 15C4712D5D2 for ; Wed, 6 Jul 2016 11:54:33 -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 u66IsCx8008280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2016 18:54:32 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 3D751509B6; Wed, 6 Jul 2016 14:54:10 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Wed, 6 Jul 2016 11:53:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------49BC0C13FAE1326A50751AC5" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 06 Jul 2016 18:54:32 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] 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, 06 Jul 2016 18:54:42 -0000 This is a multi-part message in MIME format. --------------49BC0C13FAE1326A50751AC5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry I did not respond to this before. Looks good. Same comments as application/yang-data+xml. The template is copied and pasted below for mailing list reference. Sean On 6/28/2016 7:29 PM, Andy Bierman wrote: > 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 Type name: application Subtype name: yang-patch+xml Required parameters: none Optional parameters: none // RFC Ed.: replacedraft-ietf-netmod-rfc6020bis with // the actual RFC reference for YANG 1.1, and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // 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 ]. In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // 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 the YANG Patch data structure. 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 --------------49BC0C13FAE1326A50751AC5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry I did not respond to this before.

Looks good. Same comments as application/yang-data+xml. The template is copied and pasted below for mailing list reference.

Sean

On 6/28/2016 7:29 PM, Andy Bierman wrote:
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.




thanks,
Andy

      Type name: application

      Subtype name: yang-patch+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.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // 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].
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // 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 the YANG Patch data structure.

      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


--------------49BC0C13FAE1326A50751AC5-- From nobody Wed Jul 6 11:55: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 A7BFB12D5AD for ; Wed, 6 Jul 2016 11:55: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, 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 lqEyi3fa8VDh for ; Wed, 6 Jul 2016 11:55: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 304B912D5AA for ; Wed, 6 Jul 2016 11:55:32 -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 u66ItBIt008392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2016 18:55:31 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 A83E2509B5; Wed, 6 Jul 2016 14:55:10 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: <9137e33c-0b42-92f8-d55d-461617edc98a@seantek.com> Date: Wed, 6 Jul 2016 11:54:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F7B927A0AABDB91957280512" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 06 Jul 2016 18:55:32 +0000 (UTC) Archived-At: Cc: Netconf Subject: Re: [media-types] [Netconf] 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, 06 Jul 2016 18:55:36 -0000 This is a multi-part message in MIME format. --------------F7B927A0AABDB91957280512 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry I did not respond to this before. Looks good. Same comments as application/yang-data+json. The template is copied and pasted below for mailing list reference. Sean On 6/28/2016 7:32 PM, Andy Bierman wrote: > 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 > Type name: application Subtype name: yang-patch+json Required parameters: none Optional parameters: none // RFC Ed.: replacedraft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replacedraft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // 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 ] In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // 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 the YANG Patch data structure. 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 --------------F7B927A0AABDB91957280512 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry I did not respond to this before.

Looks good. Same comments as application/yang-data+json. The template is copied and pasted below for mailing list reference.

Sean

On 6/28/2016 7:32 PM, Andy Bierman wrote:
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.




      Type name: application

      Subtype name: yang-patch+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.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // 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]
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // 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 the YANG Patch data structure.

      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


--------------F7B927A0AABDB91957280512-- From nobody Wed Jul 6 12:07: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 E589412D58A for ; Wed, 6 Jul 2016 12:07:43 -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 Q1mLkkBPblT3 for ; Wed, 6 Jul 2016 12:07:42 -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 49A7B12D576 for ; Wed, 6 Jul 2016 12:07:42 -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 u66J7LDt006784 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2016 19:07:41 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 61E32509B6; Wed, 6 Jul 2016 15:07:20 -0400 (EDT) To: Andy Bierman , Martin Bjorklund References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> <20160701.103113.301947010745595267.mbj@tail-f.com> From: Sean Leonard Message-ID: <25a8fc58-3f3e-72ee-6d8f-672b2ef53434@seantek.com> Date: Wed, 6 Jul 2016 12:06:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D84EB749CE4BBD121E27DEAB" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Wed, 06 Jul 2016 19:07:42 +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: Wed, 06 Jul 2016 19:07:44 -0000 This is a multi-part message in MIME format. --------------D84EB749CE4BBD121E27DEAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 7/5/2016 9:57 AM, Andy Bierman wrote: > [...] > > IMO it would be a bad idea to have media-specific filtering. > YANG provides an abstraction of datastore contents which we want to be = > independent > of the various query response representations found in protocol message= s. > > We are filtering on the datastore contents, not on the XML representati= on > of individual query responses. > > > > > So do we have to add text that a RESTCONF server MUST implement t= he > > "element" > > scheme? > > If this indeed is to be interpreted as a requirement, I'd rather no= t > use the "+xml" name. > > > Are there any objections to dropping the +xml? > > What about dropping +json as well? > > http://www.iana.org/assignments/media-type-structured-suffix/media-type= -structured-suffix.xhtml > > This page implies our "fields" parameter MUST NOT overlap with XPointer= =2E I believe that +xml and +json should stay on. I have not seen the XPointer issue actually trip up a registration.=20 (However, the XPointer thing is kind of new, being in RFC 7303...) The=20 +xml is important because it signals to intermediaries that they can do=20 XML analysis. This strikes me as more important than the fragment stuff, = and would in any event be a justification to override the "SHOULD NOT=20 +xml" language. The media type reviewer should say something about this..= =2E I guess the bottom line for me is: are applications actually going to=20 use fragment identifiers--is there a commercial use case? Or is this=20 just pontificating about stuff that won't actually get implemented? If it's a real use case, do you want a uniform fragment identifier=20 syntax across data syntaxes, so that #foo refers to the same semantic=20 construct across +xml, +json, +cbor, etc.? And if so, why? (I get that=20 "YANG provides an abstraction of datastore contents which we want to be=20 independent of the various query response representations"; but, the=20 YANG processors are representation-aware...so the mere fact that=20 #xpointer-fragment-form and #json-fragment-form are different from each=20 other, does not strike me as a big deal. The YANG processors know about=20 XML vs. JSON so they have to do XML vs. JSON-specific things anyway.) Sean --------------D84EB749CE4BBD121E27DEAB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 7/5/2016 9:57 AM, Andy Bierman wrote:
[...]

IMO it would be a bad idea to have media-specific filtering.
YANG provides an abstraction of datastore contents which we want to be independent
of the various query response representations found in protocol messages.

We are filtering on the datastore contents, not on the XML representation
of individual query responses.



> So do we have to add text that a RESTCONF server MUST implement the
> "element"
> scheme?

If this indeed is to be interpreted as a requirement, I'd rather not
use the "+xml" name.


Are there any objections to dropping the +xml?

What about dropping +json as well?


This page implies our "fields" parameter MUST NOT overlap with XPointer.

I believe that +xml and +json should stay on.

I have not seen the XPointer issue actually trip up a registration. (However, the XPointer thing is kind of new, being in RFC 7303...) The +xml is important because it signals to intermediaries that they can do XML analysis. This strikes me as more important than the fragment stuff, and would in any event be a justification to override the "SHOULD NOT +xml" language. The media type reviewer should say something about this...

I guess the bottom line for me is: are applications actually going to use fragment identifiers--is there a commercial use case? Or is this just pontificating about stuff that won't actually get implemented?

If it's a real use case, do you want a uniform fragment identifier syntax across data syntaxes, so that #foo refers to the same semantic construct across +xml, +json, +cbor, etc.? And if so, why? (I get that "YANG provides an abstraction of datastore contents which we want to be independent of the various query response representations"; but, the YANG processors are representation-aware...so the mere fact that #xpointer-fragment-form and #json-fragment-form are different from each other, does not strike me as a big deal. The YANG processors know about XML vs. JSON so they have to do XML vs. JSON-specific things anyway.)

Sean

--------------D84EB749CE4BBD121E27DEAB-- From nobody Fri Jul 8 16:11: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 5D4B212D945 for ; Fri, 8 Jul 2016 16:11:06 -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 OcUuidXbNpGX for ; Fri, 8 Jul 2016 16:11:00 -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 F3B6812D916 for ; Fri, 8 Jul 2016 16:10:59 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u68NAdQn027357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Jul 2016 23:10:59 GMT Received: by mail-vk0-x22b.google.com with SMTP id v6so73440792vkb.2 for ; Fri, 08 Jul 2016 16:10:59 -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; bh=+WdgZEGIOHldnl8u6SKjysW33K+Qww/UfmbfGCvjFBQ=; b=FF7tVNhnn1qPY3JpJ2nV2K1MX2S48+AssdzXW70xNGJK5BSVSBbprTH1LA6qwS3kkC UAPau9XPECIi/w3Yckx9MYMqnjre4XTG29zAGkc92CGIDQZOhtcFEHY32OMhxPeZKL+f l2MRS6AipIK3Ff7kCrJTpEy46WdddSoGlmDxhclpXKLY9UtwKXvPzGyN75G8+sbnZKYZ x5VViBQX2sgX0WOd18eP1VUciA8PI5WmegoYh86B1bqq0R3rfaJU+CzdBK88EYvVDFxL xudtf85rNgt0Ta2w8Co67Z7zJRGYGlMrKJv0p1EImeLAUkyZ4BKzKm/BpwM2pDDbg8YO HcjQ== 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; bh=+WdgZEGIOHldnl8u6SKjysW33K+Qww/UfmbfGCvjFBQ=; b=EyS3PEgWbfW7tbhjhj/1Fek7EK2+uI27DlgHDJcsg1W5g1u2dN2kuWLbsWG4RkRx2N w3XGFpWsNbYu1/ijrZJXpg2sHaqc8Ym5jKR8AYj4X3AgWGCz6GqltVQgo/LxxDRUX1D9 mxyJPBBNXcszVgKnAIUNVKdbNLabZMt5Lmy+pXPkdOVKcHeW/SQrVb15mtdoqOhI7z5m 2EkHFbyUO93RtmRf6nYuUEnTjmRDo/DDxnkuzQXWSaCRmYorKh7nUQO0ncZIkKWs+StG KSfcd3kHGlmMKiirJu0jfsVJUnq0RSbXoIxIfuNuyKKHPwO0RUEhWmebTzEWJOAKL5Mx V1Wg== X-Gm-Message-State: ALyK8tKxp253rUP7nrEA38BPYQSYjG0LRyIOFiygEyY7VrsVI5IRA5IRvRlsGcN1SmHlzP7zbRH0+DU5wHGpeQ== X-Received: by 10.159.35.112 with SMTP id 103mr3945437uae.55.1468019438744; Fri, 08 Jul 2016 16:10:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:38 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:38 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=001a113ab81a2b89f4053727e972 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, 08 Jul 2016 23:10:59 +0000 (UTC) Archived-At: Subject: [media-types] review request for media type application/yang-data 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, 08 Jul 2016 23:11:07 -0000 --001a113ab81a2b89f4053727e972 Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-data media type registration request (was application/yang-data+xml) Type name: application Subtype name: yang-data 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 the 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 the 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 utilize 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 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 --001a113ab81a2b89f4053727e972 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised appl= ication/yang-data media type registration request
(was applicatio= n/yang-data+xml)
      Type name: application

      Subtype name: yang-data

      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 the
         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 the
         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 utilize 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

      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&=
amp;ietf.org).

      Provisional registration? (standards tree only): no

--001a113ab81a2b89f4053727e972-- From nobody Fri Jul 8 16:11: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 BDD9312D945 for ; Fri, 8 Jul 2016 16:11:07 -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 r893WZpnOqxe for ; Fri, 8 Jul 2016 16:11:06 -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 0087812D925 for ; Fri, 8 Jul 2016 16:11:05 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u68NAiij012311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Jul 2016 23:11:05 GMT Received: by mail-vk0-x230.google.com with SMTP id b192so73392616vke.0 for ; Fri, 08 Jul 2016 16:11:05 -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; bh=8DkUvmyWzb0WeJXM17dp5K7dT2H9DoUOCwD5c+xowA8=; b=ST+i3fLozcItD7jXEIkIQenIljagkL2wvGcvIM+oZG/JWSx6XTTdx+FQJEQLPCvjM1 8k4kXA7zvumfABKqSHZTTtH9xMceoCipR/JLfsXJf317nvASn9heTrtqnqqnLI3kmpns 6Nm9nPszFF78ooDtNqWEhnk1vYR//LOdu7LOsMSt6JCsfTVf3i7jSqV7wZcDCNqoK360 BCoi/oFiNfbDoDqBhuzlCGvUMCEltpwy1SOzzhOk1NpkbbSPLKRYgqpFYsl1UjbigzUt SyuO222xVLwwXphdXIswh6a7tcof91OKRP7ic4Mp72vjVXHVx+Gk1TiA/WuEt937JYWZ m77g== 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; bh=8DkUvmyWzb0WeJXM17dp5K7dT2H9DoUOCwD5c+xowA8=; b=RoE3rMHrjoDlo2rqjTHOHcsXsj8D+LzdvSdd1EXlRudWKHImpZnAIfbB0fEioPF6zs vmQ6dBxdjFMv/u1hqPtvq9CwTVf8BD60tG92Eo0SC/jbrR0PCYrDCgV9FaCVzwfj9EGw +6jtTswKY3XBg78xi3xMOLEgWl/5UkSdJmWvPO0uFCTCXrKhhISLZQ+xJ1JLtUv4+eJM DNBNt0AMwdQXMzT34soG3b0tNJo9OogaaEdautiI10+0exvU2LCbIx4Et8nsddWwf9s1 j9xCMt6SqQeADG+LMzLe3EKVdSJ/Y7dGGn2KfR9eUrjfO9kZ9y23xjLrejxVf4jnUU/7 610Q== X-Gm-Message-State: ALyK8tIrx86MJQjjOlM3s0FP3NOs+6SZWZj2PKP9oe9fyR37pBDDemBz2Y4iDnqKV88Gz+a7Y0BnxlfwDPnnkw== X-Received: by 10.31.232.67 with SMTP id f64mr3353543vkh.44.1468019444536; Fri, 08 Jul 2016 16:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:43 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:43 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=94eb2c09493a83f969053727e92d 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, 08 Jul 2016 23:11:05 +0000 (UTC) Archived-At: Subject: [media-types] review request for 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: Fri, 08 Jul 2016 23:11:08 -0000 --94eb2c09493a83f969053727e92d Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-data+json media type registration request 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 the 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 utilize YANG defined data structures. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. 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 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 --94eb2c09493a83f969053727e92d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised appl= ication/yang-data+json media type registration request

      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 the 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 utilize YANG defined data structures.

      Fragment identifier considerations: The syntax and semantics
         of fragment identifiers are the same as specified for the
        "application/json" media type.

      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

      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&=
amp;ietf.org).

      Provisional registration? (standards tree only): no
--94eb2c09493a83f969053727e92d-- From nobody Fri Jul 8 16:11: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 6659512D905 for ; Fri, 8 Jul 2016 16:11:19 -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 OxZwpbjs-Xe9 for ; Fri, 8 Jul 2016 16:11:15 -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 5248012D981 for ; Fri, 8 Jul 2016 16:11:10 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id u68NAnbt020579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Jul 2016 23:11:10 GMT Received: by mail-vk0-x236.google.com with SMTP id b192so73394141vke.0 for ; Fri, 08 Jul 2016 16:11:09 -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; bh=1Skkum1Z3g81Mbggm8iy3dNnOc0MJkuTBOZ9eUj6aHM=; b=unDunxfZq6BAJzxu5nTS75BMvuHIsx71AvjempXuKesExksxNewIR6sdJwEKcTopr8 HXtbUDQ42Rdu9wb+wc7iVmXMw/7ReEbb3DeHG7owM/DvRNmI4yWhQfZXRdJjSCR2GrVj 9HjWeeTarbPi1LeJBygTugCtb+k930PfN7C2Qfs2zH7gotMATT8J18btX27s9o0fLIA/ 68VtBrXXemwzO9vLYW/7Q6LDFfVtv32NObg9Z+LfRgAIbRUmfSjXPz08hli2y8/PdCn7 l1CbYJM74gwLdhOwZ0w0EfDdOcXmHxMk9Hx47F2zMBV4+2RVvrh2gw/OZteXTUpznTS1 Ntxw== 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; bh=1Skkum1Z3g81Mbggm8iy3dNnOc0MJkuTBOZ9eUj6aHM=; b=HBySJLuJt6YS/5+IKV0z0nDzawJtgl8/Nzy/x1KzQ0DzC0cyER65BSby9pMA4HwxF+ R2O+UNHDoC5tA8kBitR3QmjM1l13wmR6WB6uGfyzFAT1cm8ri77eyznEyInOKWUp1bTr Y6A/HdFJK4ngCn9MGq4TSxAz7zxu/8rPJ2aOOv7OgzwMkHMPe30UICBZ+pn/nuFc+8rJ grBVD/j2/61dG9MRAwdvcLmgHb2fwzPIQaFM0/ibP27QpqSRn0ghU+3KiK+Bymf5LIte VpaWG0jQF+dyPj12ydBJxnBIsZ/NFVi+F1YE3Mh9xXBY68a+iRDmHobhEiLgmuEETW+7 He6A== X-Gm-Message-State: ALyK8tJr0Mh0Qf4C1vuabyMPRIJsCB8FWqwNG2yCsG6n4+ySLa1mDT8BdDlCGq483wqpM1+lgML23YKU+J3XWA== X-Received: by 10.159.36.22 with SMTP id 22mr64637uaq.105.1468019449131; Fri, 08 Jul 2016 16:10:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:48 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:48 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=001a11352aaaca08cb053727e945 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]); Fri, 08 Jul 2016 23:11:10 +0000 (UTC) Archived-At: Subject: [media-types] review request for media type application/yang-patch 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, 08 Jul 2016 23:11:19 -0000 --001a11352aaaca08cb053727e945 Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-patch media type registration request (was application/yang-patch+xml) Type name: application Subtype name: yang-patch 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. // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // 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 the 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 utilize the YANG Patch data structure. 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 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 --001a11352aaaca08cb053727e945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised applic= ation/yang-patch media type registration request
(was application= /yang-patch+xml)
      Type name: application

      Subtype name: yang-patch

      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.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // and remove this note

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to the
         XML Encoding Rules and Canonical Format for the specific
         YANG data node type defined in [draft-ietf-netmod-rfc6020bis].
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // 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
<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"> = // note Interoperability considerations: [RFCXXXX] specifies the 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 utilize the YANG Patch data structure. 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 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

--001a11352aaaca08cb053727e945-- From nobody Fri Jul 8 16:11: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 92FFA12D986 for ; Fri, 8 Jul 2016 16:11:26 -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 NsV--2ZLespg for ; Fri, 8 Jul 2016 16:11:19 -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 0466112D7EF for ; Fri, 8 Jul 2016 16:11:14 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u68NAs1p016780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Jul 2016 23:11:14 GMT Received: by mail-vk0-x235.google.com with SMTP id d67so73621406vkh.1 for ; Fri, 08 Jul 2016 16:11:14 -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; bh=rFppfsO/+g1mVsCO7ms+9a/glq6etmWSKPhxQ2HmbCA=; b=GPPhXdh3L///OTLDtnmbqDlV1i7H+yHN24wQL/C+OXp6moL3g39JGr7qRtzRrDLjiK 21PrMrnnGBWP46ksNrbvKvbynZnjTyA3f1aRaR9cTx/gNdWQCaw1P0eyj3E2KuKiqSBi TSwyu15NH4RAqjiUUTa2QvaplwuYRvEFTsROcZsi1fpn8X1hLTCNxx48kYse2XBnDvqX SXeW5y36B/MjxhwNpDety99fxocfiJv0iuXl/7AfLtkGLN123k/WbtvF3k6VAtSB5EBM rLG+dbb7Ffq8bIJnAdy+oJKek6IC1vGSWthwEo5/l7B2J20I5MMOIssab5Md0ux9x06u Nc7w== 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; bh=rFppfsO/+g1mVsCO7ms+9a/glq6etmWSKPhxQ2HmbCA=; b=MwalrnN7NLH4quak8XhWEg0oTq25wCXZjR2kTaYOyFcE/JWMgVJ9jxDSXG4M/8yWKh UbcfNuBRSHQGDuTsKBGC5ArrJwdKDFaq+ft4+HI2vwjiAEWLcQKNwoadpQaLk7DGZ6ms fHpG4lyQKFmMmZkJ6nOURIBpV0Wc1OyIBgA450Stvi5QW1GlzIOTYf5DELk1NanGSluR 3Fyqor84r4W67eFkLKjMJOj6OA98H0QV/QNAd/tvU/kEvHEPyfy0waSFWt7mQYsKikRO d7K6ILcv9v3tA5ohO92OzTVByFYHd5c8Wu6t9Qc7MwquXJNbqu3U3ZAaU4ctlIEtEdqJ xD9Q== X-Gm-Message-State: ALyK8tJxy4Fgdh3SIpugbVqvV4aNTbiCfnoUB6gwMrnoNIoyDHMV756ZoZKs67J5kxtY7kXC4cXh0z0rosIQwA== X-Received: by 10.31.9.65 with SMTP id 62mr3890582vkj.89.1468019453736; Fri, 08 Jul 2016 16:10:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:53 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:53 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=001a11440b64104ba1053727ea78 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, 08 Jul 2016 23:11:14 +0000 (UTC) Archived-At: Subject: [media-types] review request for 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: Fri, 08 Jul 2016 23:11:26 -0000 --001a11440b64104ba1053727ea78 Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-patch+json media type registration request Type name: application Subtype name: yang-patch+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. // RFC Ed.: replace 'XXXX' with the real RFC number, // 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] In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // 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 the 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 utilize the YANG Patch data structure. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. 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 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 --001a11440b64104ba1053727ea78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised appl= ication/yang-patch+json media type registration request


=
= Type name: application
      Subtype name: yang=
-patch+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.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // 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]
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // 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 the 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 utilize the YANG Patch data structure.

      Fragment identifier considerations: The syntax and semantics
         of fragment identifiers are the same as specified for the
        "application/json" media type.

      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

      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

--001a11440b64104ba1053727ea78-- From nobody Thu Jul 14 17:09: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 E58D012D52C for ; Thu, 14 Jul 2016 17:09:45 -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 Q6WF5b7QFcsv for ; Thu, 14 Jul 2016 17:09:43 -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 7403812D643 for ; Thu, 14 Jul 2016 17:09:43 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id u6F09Mkn012364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jul 2016 00:09:43 GMT X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=WYROUApX c=1 sm=1 tr=0 a=xJnH0TjSJs1RdLaQaq4zsA==:117 a=xJnH0TjSJs1RdLaQaq4zsA==:17 a=IkcTkHD0fZMA:10 a=JH1ryHwkAAAA:8 a=Trb1D-6kmj9GXv21IqoA:9 a=DBYRKNfLT0MA:10 a=EjxKlVCzCgcA:10 a=u639gV5tA_3KWspupztj:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: Y2hvd2Jva0ByY24uY29t Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=lists@unknown.nu; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=lists@unknown.nu; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=chowbok; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 207.181.247.115 is neither permitted nor denied by domain of unknown.nu) Received: from [207.181.247.115] ([207.181.247.115:54910] helo=[192.168.1.88]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPA id 57/1D-24934-2B928875; Thu, 14 Jul 2016 20:09:22 -0400 From: Kim Scarborough To: "media-types@iana.org" Message-ID: <060fc0e9-d87c-7f1a-9f79-750622f13a19@unknown.nu> Date: Thu, 14 Jul 2016 19:09:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [media-types] Review request for structured syntax suffix registration: rar 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, 15 Jul 2016 00:09:46 -0000 Hello folks, This is a review request for a Registration Request for Structured Syntax Suffix "rar". Name: RAR compression and archive format +suffix: rar References: “RAR 5.0 archive format", Encoding considerations: RAR is a binary format. Interoperability considerations: As this is not an open standard, interoperability is left up to the discretion of the developer. Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for rar SHOULD be as specified for "application/vnd.rar". (At publication of this document, there is no fragment identification syntax defined for "application/vnd.rar".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+rar" SHOULD be processed as follows: For cases defined in +rar, where the fragment identifier resolves per the +rar rules, then process as specified in +rar. For cases defined in +rar, where the fragment identifier does not resolve per the +rar rules, then process as specified in "xxx/yyy+rar". For cases not defined in +rar, then process as specified in "xxx/yyy+rar". Security considerations: The security issues associated with this type have not been assessed. Contact: Kim Scarborough Author/Change controller: win.rar GmbH Marienstrasse 12 10117 Berlin Germany HRB 109885 B Amtsgericht Charlottenburg Ust-ID Nr. DE255974207 From nobody Sat Jul 16 23:26:27 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 5EE6412D0E0 for ; Sat, 16 Jul 2016 23:26:26 -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=itaoyama.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 qE0PETCCl_up for ; Sat, 16 Jul 2016 23:26: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 E9C5012B00C for ; Sat, 16 Jul 2016 23:26:23 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0126.outbound.protection.outlook.com [104.47.92.126]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u6H6Q1ah032318 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 17 Jul 2016 06:26:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3loujtV1wZEuv+wBiBmJH6yCg+eo812SKyWSUTAdUng=; b=a65PRFi7119sQaU/ESP5855nQzDYkhM+r4ZEHH+ppw70IkuOOGLE+mQh8SjVXzTfGDx7JQCEMx46sBKz7RYwLuTDfUoOEZc52BB/rIwX0PGxQyqa7Q9JOP427q8eulnH9yvD/d6n5DKgPqfnvv1F+0JaXFz1ycZIhbYZsbj6uEw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Sun, 17 Jul 2016 06:25:58 +0000 To: Kim Scarborough , "media-types@iana.org" References: <060fc0e9-d87c-7f1a-9f79-750622f13a19@unknown.nu> From: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" Organization: Aoyama Gakuin University Message-ID: Date: Sun, 17 Jul 2016 15:25:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <060fc0e9-d87c-7f1a-9f79-750622f13a19@unknown.nu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0045.jpnprd01.prod.outlook.com (10.164.161.155) To TYXPR01MB0927.jpnprd01.prod.outlook.com (10.168.45.22) X-MS-Office365-Filtering-Correlation-Id: 91d3703a-e7de-4924-913c-08d3ae0b376a X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 2:eiET6aYOIp8pApYTPGS4iuLerYvOlBARMTm9gxZ6dPUfTrjmUTSRhlDK9oaxiQh2BeFzRnkpwzEzeEMdMqZCjZC45psw9kl3f9MiFqYRDRwtoWKo2XRk5/Jeqx5vvcPW81uv4j8EmnaNyO5CoCJLiD49tzv4HhZ9BsdJ7XyQMPE3spZ6sCkheyPsJDm3AUWL; 3:IE92ebDCM3kcutRTLw0YtQUc1rRlD/DjcbWwOI2UMhNeFeIe9zvh17IY18GESpG2a1m4oh+x6P9YbVeHlxzvCv6GuWaw2r5yIAD3rYezuaESUJnMRMSSXX/+PVew8QX9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0927; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 25:+mD2nn8ETa8rQSXG4wn0oKMT0yRNTW1jsmDyl33Bz/qNqRAWKVbbIg3esZSC2jYHkQ61D1mvKKRicyv08xiYAnANX78lk7c/slq1HdbSWlUuAV+H4UsNYxle71ldvb7x6OMiZUck86GqkihlJ66/DjyauAQIyirTpc08PQcuVX9+Q2t8tu8l1Jgwtubav+o//PQPd8mtRUOCRYiLNZtNx3yVEPLj1JXjBexfT18QWrx+/7Z2wJXwUBvY0bolmCn1HYtGyCbvs8WBQU/Kduw2uTqys12mlaOovhXdHAMaemnkfknkMPA8OfJH32cwN0XlBWE5/OuCmNVKSVFDCBccTsaMCn4EsW72feAu5PS18pFSLTFWglGhJF9bz2hKkH/hN9KO9NgBvE4eLC9qtG+yQJxOUN4Sb9I103zdyiBvFUQYuLpRf8xxFUc8vXKCyRY4g478j3r522XzFNpgtV6LenmEISHUIMucNihx67fughbr6kIMb8hbbBP2bjq0/p7giVJA3j+r+0RAlS1uuuVijh5uO35C0sXw16nQz7HghZINgN7veMa1HGWtFG4zllB6M9i5BpYCpia5HMaDYOP9ziLtVV7mEfly6tXSMBXT2R9M68xVdzRS1C+ioP9ja+BwRjFT8OxerzG+AhxOxMzR9j4MWejI9SK4siT0Lq1a4gmeTkrdCBwdFyWnJ/PNTckWWiDGZl+CcAqS6mRPFvVRIx6fmOA39hwtxPf+0mrKQNzqf2dTMgchifZyLpGiozhp+Y2Idal/mk09rzDuvYtZv1SQX1CK2LwonQ5r/lfrMjHdIzRUCYSFbOYLdgeLX7H+WtW7GAZf8dWj/Ab8R+YOig== X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 31:K4JBR5SmOQ9LN6nJASTHNF7/pBgE6GeYpZxO91ZEM8et94doeh+C3YRItkHmJVTeSQ2vZWPCTRgYovpcBGDoQ1GCrsJzenM82Bmh4oYWAahWv4NGq60ivX9eGOlLNcIngwb8s6XZF0n8F358+Xga4u99WeieNKMMl/9kHUG3PXdXWUIJqi2lecItkrQn2nxhwWWT6CH/mFQLXokRTgPaDg==; 4:rhximEGCeN+hN9FNfzUtA6eqLWHkLE+uFnEkHZlzE+MrWBqxJR7nu5mTIsJGE4XozZew7cdoQyBoN3MIvWYSkn926d84jbgEPWA7HbJ7UVmFlB6H0znb5817h//vojm80FXrDFHnfG2GxeDA7pHaHaPwAXGJRQA7r/hM0GNm60wK//CUmMGDc0Re6EIej6gj6hIiFlJ1YsTZlhm4ffiY1A2XEp39W576Q0DQp0FaoTddRaYfu2b68oGdh54quuhh/mmFV/DKt1v2zELiJyhMXSRtRq9G81Xe6wyvCg7/JE4Umm7PEqo92aRgcuqalXj08qSd5ohC523I72pVZs3VYgnNtBY8n/4cnl7tB/+9BXMFyhsAmpCGUafnG64WsWYGtCskF0fbqXUjJqACLTq6E/LqtXVQu9HftuTelCfXE29xKV58uMAk9EuALAw3k/3SIXM+q/7b5DkVTL42hTjgYQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6042046)(6043046); SRVR:TYXPR01MB0927; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0927; X-Forefront-PRVS: 00064751B6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(24454002)(31686004)(19580405001)(31696002)(92566002)(19580395003)(97736004)(189998001)(50466002)(42186005)(3846002)(586003)(6116002)(74482002)(4001350100001)(2501003)(106356001)(107886002)(83506001)(5001770100001)(23676002)(101416001)(15975445007)(105586002)(77096005)(33646002)(8676002)(47776003)(2870700001)(2906002)(64126003)(86362001)(68736007)(54356999)(76176999)(2950100001)(305945005)(50986999)(65956001)(66066001)(7736002)(81156014)(65806001)(81166006)(7846002)(65826006)(21314002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0927; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI3OzIzOkNWWExMMklwYzEyKytIU2hsZlpQMlBZTXR1?= =?utf-8?B?VTdzbjNBcE9SRzI1Tk1iOCt0ZU8vSk40MHlkazBUK3lyLzNPSmU3cjlnN2dk?= =?utf-8?B?QjV2WEhjSTRaQzEzaHluZzFVeDVMaHAydVUrcUlPeit4VUY0WXZRcTJyVk9V?= =?utf-8?B?WVNJVDhFN1l0WXV6SVhDTkZqSE1VM1VscmhZMVBxMTRPNWVmWTlhalBLa0Yw?= =?utf-8?B?cDR1amh2MUttNThINDNncnI4ZkY4LzNDa0xZSW4weXhidTJKM3BUaCtBbjJP?= =?utf-8?B?VzY1K3pjSEordTFURTZNN1h0Z01WcWdBQUJNYzQzQmovNm4vaWlUeG91TlJo?= =?utf-8?B?WFJSSktDaWlzOUxUWGxIUFBuOGcyWmhyODRNWmx1b3BPaklaQ2dud0NBeVRq?= =?utf-8?B?eERXcExGUjBhZEkyZnplR29SY2U2aGk1VzdrT1BpeGx1VHJWVEI4dDBTNE84?= =?utf-8?B?czJkQjNsMzY2eTJtNTZXaWdMK244QkNjdUtnaW1mYk84N1pTc2ZqL0ZqN05N?= =?utf-8?B?a3VDQk9qTGNjdDRIdFp5OE1odi9VU3hQeW12UThSRTdrZi85SHc1Z2E2cG0x?= =?utf-8?B?amVhNHZWOXEzbGpGVVNxV0IrU3B0WFl6YlEyNndDT0dzcUlSRmFtZ2I0bTNN?= =?utf-8?B?RVRvVTlUYXZUS3doMVJBUGlHNkoyMnd0ZVBYOG00WnlzcWRpYitQV2s4SjY5?= =?utf-8?B?WGhXVTI0MWpnZWUzSmlBcWk1UDU2ckI4bkxUSnp0eDRjNXA3bGpHWUxzN2Ux?= =?utf-8?B?QUVlc2lPVTJsWmdQVFQzM3lTVDdIbkkrUlZZd2hzT0JvUXZHekJVSjRKbVBM?= =?utf-8?B?STZzZnE0Z1dnYVlCN29od2JRTGRtcmRabUpFRHY3QXczLzFRNzdHOTEzWUQ3?= =?utf-8?B?UzBnUW8vOFlXRmFOVEZlKzc3c2VxeEhDYitnakxwU2U5Tkx1enVTbTluMjZP?= =?utf-8?B?aFNpNUxiQU5sK0pXWHo1UmVNNkVnNUZBQTlCTk90VWtTL1JudnJpT05GbUVp?= =?utf-8?B?Wk9iQVZOd2tvU0Vmc0M3VSsvdDhrQVI3UXVqZUNBSjlyMWdoeFg5N0h1RktU?= =?utf-8?B?VzdsWms4dkVLQXpMQ2o1ZGthcWhld1ZvRFRGTXNvdmlDNjFWeTZEMWRoNUV0?= =?utf-8?B?TzgvSTJ1c2NIcS9MN2Vuc3M0dFZveVZKTjdmMWdHM3dVSnQ3Y29xVDlvV3Ew?= =?utf-8?B?MGEwb1R6b2I0QU4vUTAyTmFOSWw1TkVTWjVoREFQbHE5L2htWXA2U29yY1h6?= =?utf-8?B?Y1NZV2x3WDdiTzkwT3hIaEpFMTN0b2pnYnptZUpsNFdrTTBIRjJ3Z1htOE5o?= =?utf-8?B?UlcvQWs0V3RLZ1N6Q0I5dTd6UmJ1b0xuSzRGcXV0Nk9yU1NGelhWMm90a0RJ?= =?utf-8?B?R3hBUkFMQms5VFdQMUdaa29PaUhpbld0TENydUkybjNYMWI1ZjNydllLWkJR?= =?utf-8?B?UUsxWnlJMHg3TEx2NHZVclFsZ0ZTL3JHQjh6M3VOTTVaUVl6UUNVMUV4NlBO?= =?utf-8?B?VnQ2M25wVWlNay9VUWRZT2NkU2U2TmNkeFQ4NlV2WmdqK29idVh4eVlJK2VQ?= =?utf-8?B?KzlWMmdzcUc2ZGI0bWl2ZU9NeVpmakVmYlNUMUNiYkxFNm15WEhndzhvNzdL?= =?utf-8?B?OVRVaVc2TFJXRDU1S0JWNGhNTk5VUjRVenk5NUZBeEliL3VsWEpyVFBMQzBa?= =?utf-8?B?a1YvdUhHWGs5OVg2dlBiR2hTeW9iUWFFTDgyU0R1MmFvLzNiMFRiWG5aNnBs?= =?utf-8?B?eFlMbE5nNU5RSHZWWUE4QkdkNldDbXJxa29IK2ZyM2FpWjNjVXhrMFk5Q2RZ?= =?utf-8?B?dDlSa3FXMS9aYksvWC9MbW5adVF5ZTVOQWJ1cVdnUklIdUE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0927; 6:dWX2kUlBjcldmOl/28Lh6D0qn31V6hNakgxgmXSlu83ygBwKYwxch2ewy6stSCaRv7jr84xrk1bhnvsR4rvAnKsSpNcZ1g6a1HNVVFiJkJXMiNsr147wEQ0c+J4prlXTaH8Q+p0H9PU+lFBPivqfY9aUs+QmqFtt5TGxUGRE+xTzyu9sbcCDBU3kmNJImzoaRHefGQBq6VxZUBVeNIHs8Qs2iLhxx0+iT6ZH7IMinN+e52lMdjusTTVm4M9Q+CnkbKwqRWj3tjd+Honqeteq/fRjBc5hhQlud4xSNwtMkgwNtp3tF8DdT6m8DwSSE9pb; 5:+YPq7iwTWs6aBsnZQsFLeW+ThT9ECBOEbAaUHBlBsCyI3baxFPa1pHPeQMocbe+uz2xnr37a20bAK/jhFAn5++LnueVbGSKUYWKa0QwJjinya2y3XC2t7/7ow7EuGdJDxMX2Igx8DmE9fBGLAP5d6Q==; 24:NE18Qj8JgKAUgqwjr2ShzywDYgaVgSjmrnQadFJ6VdO3FiVWIPGgR2ru+ngP6O2e3GzGy+HtePwGSsU8UvaEFwUAQerBkQ6Cd7b/TAp+AsU=; 7:TvDUTCnxGennhVjx6rO1+Tny3piwDTj7TEb6Jhd8d0uEbnwxLfi/w8LUVepOi+xwjhllZ7gWGNzwG3Phbp9BTdzwmBiJOHCYGsLP7Gf5q+QDvsiGYaKQmskG5VBh22KHYeY/8TAmIX4KnAvRgDU36MwTpytZOwqFeDtNg794PQhQoqhPS4hOsU+1J0MHeZYbZRHQeqUwrrJrr68ZIhhsJ0Qk+4uXMedQMHqOo86T+YAUstOeGmSnKEMHDapJhYDD SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2016 06:25:58.5744 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0927 Archived-At: Subject: Re: [media-types] Review request for structured syntax suffix registration: rar 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, 17 Jul 2016 06:26:26 -0000 On 2016/07/15 09:09, Kim Scarborough wrote: > Hello folks, For a structured suffix, these should be a few (at least potential) actual media types that would use it. Can you give (at least potential) examples? Regards, Martin. > This is a review request for a Registration Request for Structured > Syntax Suffix "rar". > > Name: RAR compression and archive format > > +suffix: rar > > References: “RAR 5.0 archive format", > > Encoding considerations: RAR is a binary format. > > Interoperability considerations: As this is not an open standard, > interoperability is left up to the discretion of the developer. > > Fragment identifier considerations: The syntax and semantics of fragment > identifiers specified for rar SHOULD be as specified for > "application/vnd.rar". (At publication of this document, there is no > fragment identification syntax defined for "application/vnd.rar".) > > The syntax and semantics for fragment identifiers for a specific > "xxx/yyy+rar" SHOULD be processed as follows: > > For cases defined in +rar, where the fragment identifier resolves per > the +rar rules, then process as specified in +rar. > > For cases defined in +rar, where the fragment identifier does not > resolve per the +rar rules, then process as specified in "xxx/yyy+rar". > > For cases not defined in +rar, then process as specified in "xxx/yyy+rar". > > Security considerations: > The security issues associated with this type have not been > assessed. > > Contact: > Kim Scarborough > > > Author/Change controller: > win.rar GmbH > Marienstrasse 12 > 10117 Berlin > Germany HRB 109885 B Amtsgericht Charlottenburg > Ust-ID Nr. DE255974207 > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From nobody Sun Jul 17 15:51: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 CC53612B026 for ; Sun, 17 Jul 2016 15:51:40 -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 HXqjfToH-By5 for ; Sun, 17 Jul 2016 15:51: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 7519012B00E for ; Sun, 17 Jul 2016 15:51:38 -0700 (PDT) Received: from smtp.rcn.com (smtp-fo2.rcn.cmh.synacor.com [69.168.97.82]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id u6HMpGUB017565 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 17 Jul 2016 22:51:38 GMT X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=WYROUApX c=1 sm=1 tr=0 a=xJnH0TjSJs1RdLaQaq4zsA==:117 a=xJnH0TjSJs1RdLaQaq4zsA==:17 a=IkcTkHD0fZMA:10 a=JH1ryHwkAAAA:8 a=48vgC7mUAAAA:8 a=JMO_tIbph8_6f65N1ysA:9 a=DBYRKNfLT0MA:10 a=EjxKlVCzCgcA:10 a=u639gV5tA_3KWspupztj:22 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: Y2hvd2Jva0ByY24uY29t Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=lists@unknown.nu; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=lists@unknown.nu; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=chowbok; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 207.181.247.115 is neither permitted nor denied by domain of unknown.nu) Received: from [207.181.247.115] ([207.181.247.115:34112] helo=[192.168.1.88]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPA id 91/50-24934-3EB0C875; Sun, 17 Jul 2016 18:51:16 -0400 To: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" , "media-types@iana.org" References: <060fc0e9-d87c-7f1a-9f79-750622f13a19@unknown.nu> From: Kim Scarborough Message-ID: Date: Sun, 17 Jul 2016 17:51:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [media-types] Review request for structured syntax suffix registration: rar 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, 17 Jul 2016 22:51:41 -0000 Sure. If this goes through, I'm planning on registering application/vnd.comicbook+rar, which would apply to .CBR files and would compliment application/vnd.comicbook+zip. RAR has better multimedia compression than comparable formats, so one could register something like video/mpeg+rar or audio/vnd.wave+rar (assuming audio/vnd.wave gets registered). On 07/17/2016 01:25 AM, Martin J. Dürst wrote: > On 2016/07/15 09:09, Kim Scarborough wrote: > > Hello folks, > > For a structured suffix, these should be a few (at least potential) > actual media types that would use it. Can you give (at least potential) > examples? > > Regards, Martin. > > > > This is a review request for a Registration Request for Structured > > Syntax Suffix "rar". > > > > Name: RAR compression and archive format > > > > +suffix: rar > > > > References: “RAR 5.0 archive format", > > > > Encoding considerations: RAR is a binary format. > > > > Interoperability considerations: As this is not an open standard, > > interoperability is left up to the discretion of the developer. > > > > Fragment identifier considerations: The syntax and semantics of fragment > > identifiers specified for rar SHOULD be as specified for > > "application/vnd.rar". (At publication of this document, there is no > > fragment identification syntax defined for "application/vnd.rar".) > > > > The syntax and semantics for fragment identifiers for a specific > > "xxx/yyy+rar" SHOULD be processed as follows: > > > > For cases defined in +rar, where the fragment identifier resolves per > > the +rar rules, then process as specified in +rar. > > > > For cases defined in +rar, where the fragment identifier does not > > resolve per the +rar rules, then process as specified in "xxx/yyy+rar". > > > > For cases not defined in +rar, then process as specified in "xxx/yyy+rar". > > > > Security considerations: > > The security issues associated with this type have not been > > assessed. > > > > Contact: > > Kim Scarborough > > > > > > Author/Change controller: > > win.rar GmbH > > Marienstrasse 12 > > 10117 Berlin > > Germany HRB 109885 B Amtsgericht Charlottenburg > > Ust-ID Nr. DE255974207 > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > From nobody Tue Jul 19 03:47: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 A6BEE12D0F0 for ; Tue, 19 Jul 2016 03:47: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=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 jub-hMIXp1dZ for ; Tue, 19 Jul 2016 03:47:42 -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 80F1912B05F for ; Tue, 19 Jul 2016 03:47:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u6JAlKAl009321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2016 10:47:41 GMT X-AuditID: c1b4fb2d-f79936d0000030e4-7a-578e0537119f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.E8.12516.7350E875; Tue, 19 Jul 2016 12:47:19 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.230]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Tue, 19 Jul 2016 12:46:31 +0200 From: =?iso-8859-1?Q?Jaime_Jim=E9nez?= To: "media-types@iana.org" Thread-Topic: Media type review of draft-ietf-core-http-mapping Thread-Index: AQHR4arPUGN2mp6Jn02UwG2tXsbDBQ== Date: Tue, 19 Jul 2016 10:46:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_C08D09CD4E0148FEA2910743E3923DD8ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2J7uK45a1+4wfKl4hYLpBwYPXrkAxij uGxSUnMyy1KL9O0SuDLWP9Es2BZRcbrvOlsDY59vFyMnh4SAicSX6yvZIWwxiQv31rOB2EIC RxglPjWUQ9hLGCX2ndAHsdkEnCW+fZ7FBGKLCBhKfD+6nhXEFhawkmg6sY4NIm4vsejOeaga PYnz33YwgtgsAqoSm+e+B7I5OHiBaq6vdAUJMwKt/X5qDVg5s4C4xK0n85kgzhGQWLLnPDOE LSrx8vE/VghbSaJxyRNWkDHMAskShw8qgYR5BQQlTs58wjKBUWgWkkmzEKpmIamCKNGTuDF1 ChuErS2xbOFrZghbV2LGv0NQNdYSH/p3oqhZwMixilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMwMg5u+a27g3H1a8dDjAIcjEo8vAqSveFCrIllxZW5hxglOJiVRHjvM/eFC/GmJFZWpRbl xxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamDM03pudGvxfh6xM9baFiqn 5jHtEH944me7PbOxq9mRPZueO5XwrU9e7xl0JDfz4dLz9mHcLc9ONYjPDDkgfIKBQ6k8ftWr 4KS9R7Z80fp1xtyJZ8fd+oX/ZTels/v0r5uU9PxPMvu9pzPlb3ce3CY/wYjR4y2f04WuiKQc d7drdT8CrnJJ11xXYinOSDTUYi4qTgQA7GMrPIgCAAA= Archived-At: Subject: [media-types] Media type review of draft-ietf-core-http-mapping 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, 19 Jul 2016 10:47:46 -0000 --_000_C08D09CD4E0148FEA2910743E3923DD8ericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to get a review of the media type template on section 9.2 of d= raft-ietf-core-http-mapping https://tools.ietf.org/html/draft-ietf-core-http-mapping-12#section-9.2 ----------- 8< ----------- 9.2. New 'coap-payload' Internet Media Type This document defines the "application/coap-payload" media type with a single parameter "cf". This media type represents any payload that a CoAP message can carry, having a content format that can be identified by a CoAP Content-Format parameter (an integer in range 0-65535). The parameter "cf" is the integer defining the CoAP content format. Type name: application Subtype name: coap-payload Required parameters: cf - CoAP Content-Format integer in range 0-65535 denoting the content format of the CoAP payload carried. Optional parameters: None Encoding considerations: The specific CoAP content format encoding considerations for the selected Content-Format (cf parameter) apply. Security considerations: The specific CoAP content format security considerations for the selected Content-Format (cf parameter) apply. Interoperability considerations: Published specification: (this I-D - TBD) Applications that use this media type: HTTP-to-CoAP Proxies. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person and email address to contact for further information: Esko Dijk ("esko@ieee.org") Intended usage: COMMON Restrictions on usage: An application (or user) can only use this media type if it has to represent a CoAP payload of which the specified CoAP Content-Format is an unrecognized number; such that a proper translation directly to the equivalent HTTP media type is not possible. Author: CoRE WG Change controller: IETF Provisional registration? (standards tree only): N/A - - Jaime Jimenez --_000_C08D09CD4E0148FEA2910743E3923DD8ericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I would like to get a rev= iew of the media type template on section 9.2 of draft-ietf-cor= e-http-mapping

https://tools.ietf.org/html/draft-ietf-= core-http-mapping-12#section-9.2
----------- 8< --= ---------


9.2.  New 'coap-payload' Internet Media Type


   This documen= t defines the "application/coap-payload" media type with
   a single par= ameter "cf".  This media type represents any payload that
   a CoAP messa= ge can carry, having a content format that can be
   identified b= y a CoAP Content-Format parameter (an integer in range
   0-65535). &n= bsp;The parameter "cf" is the integer defining the CoAP
   content form= at.

   Type name: a= pplication

   Subtype name= : coap-payload

   Required par= ameters:

   cf - CoAP Co= ntent-Format integer in range 0-65535 denoting the
   content form= at of the CoAP payload carried.

   Optional par= ameters: None

   Encoding con= siderations:

   The specific= CoAP content format encoding considerations for the
   selected Con= tent-Format (cf parameter) apply.

   Security con= siderations:

   The specific= CoAP content format security considerations for the
   selected Con= tent-Format (cf parameter) apply.

   Interoperabi= lity considerations:

   Published sp= ecification: (this I-D - TBD)

   Applications= that use this media type:

   HTTP-to-CoAP= Proxies.

   Fragment ide= ntifier considerations: N/A

   Additional i= nformation:

      Depr= ecated alias names for this type: N/A

      Magi= c number(s): N/A

      File= extension(s): N/A

      Maci= ntosh file type code(s): N/A

   Person and e= mail address to contact for further information:

      Esko= Dijk ("esko@ieee.org&= quot;)

   Intended usa= ge: COMMON

   Restrictions= on usage:

   An applicati= on (or user) can only use this media type if it has to
   represent a = CoAP payload of which the specified CoAP Content-Format
   is an unreco= gnized number; such that a proper translation directly to
   the equivale= nt HTTP media type is not possible.

   Author: CoRE= WG

   Change contr= oller: IETF

   Provisional = registration? (standards tree only): N/A



- - Jaime Jimenez

--_000_C08D09CD4E0148FEA2910743E3923DD8ericssoncom_-- From nobody Tue Jul 19 04:02: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 0AF9512D1EA for ; Tue, 19 Jul 2016 04:02:35 -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 VpqJ2hbLwHz0 for ; Tue, 19 Jul 2016 04:02: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 5A11112D179 for ; Tue, 19 Jul 2016 04:02:31 -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 u6JB2Amx014337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2016 11:02:31 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 86DC050AC8; Tue, 19 Jul 2016 07:02:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Tue, 19 Jul 2016 04:02:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf , media-types@iana.org Subject: Re: [media-types] [Netconf] review request for 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: Tue, 19 Jul 2016 11:02:35 -0000 application/yang-patch+json and application/yang-data+json look fine to = me. Carry on. Sean > On Jul 8, 2016, at 4:10 PM, Andy Bierman wrote: >=20 > Hi, >=20 > Here is the revised application/yang-patch+json media type = registration request >=20 >=20 > Type name: application > Subtype name: yang-patch+json >=20 > Required parameters: None >=20 > Optional parameters: None >=20 > // RFC Ed.: replace draft-ietf-netmod-yang-json with > // the actual RFC reference for JSON Encoding of YANG Data, > // and remove this note. >=20 > // RFC Ed.: replace draft-ietf-netmod-yang-metadata with > // the actual RFC reference for JSON Encoding of YANG Data, > // and remove this note. >=20 > // RFC Ed.: replace 'XXXX' with the real RFC number, > // and remove this note >=20 > 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] > In addition, the "yang-patch" YANG data template found > in [RFCXXXX] defines the structure of a YANG Patch request. >=20 > // 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. >=20 > 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. >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Interoperability considerations: [RFCXXXX] specifies the format > of conforming messages and the interpretation thereof. >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Published specification: RFC XXXX >=20 > Applications that use this media type: Instance document > data parsers used within a protocol or automation tool > that utilize the YANG Patch data structure. >=20 > Fragment identifier considerations: The syntax and semantics > of fragment identifiers are the same as specified for the > "application/json" media type. >=20 > Additional information: >=20 > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): .json > Macintosh file type code(s): "TEXT" >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Person & email address to contact for further information: See > Authors' Addresses section of [RFCXXXX]. >=20 > Intended usage: COMMON >=20 > Restrictions on usage: N/A >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Author: See Authors' Addresses section of [RFCXXXX]. >=20 > Change controller: Internet Engineering Task Force > (mailto: > iesg&ietf.org > ). >=20 > Provisional registration? (standards tree only): no >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jul 19 04:10:28 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 A73AB12D50E for ; Tue, 19 Jul 2016 04:10:26 -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=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 gr9YIFo5Kxe8 for ; Tue, 19 Jul 2016 04:10:25 -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 16FE212D501 for ; Tue, 19 Jul 2016 04:10:25 -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 u6JBA314001427 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2016 11:10:24 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 1FD7F509B5; Tue, 19 Jul 2016 07:10:02 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Tue, 19 Jul 2016 04:10:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf , media-types@iana.org Subject: Re: [media-types] [Netconf] review request for media type application/yang-patch 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, 19 Jul 2016 11:10:26 -0000 My feedback remains that these ought to remain = application/yang-patch+xml and application/yang-data+xml. I would be happy to be rebuked (with appropriate justifications), but = have not heard compelling reasons to vary from that course. Three observations: 1. If you occupy application/yang-patch as the XML variant now, what = happens when you have CBOR or some other fancy format du jour? Now = you=E2=80=99ve used up the =E2=80=9Cmain one=E2=80=9D. 2. Consider that image/svg+xml uses +xml, but doesn=E2=80=99t use = XPointer for fragment identifiers. It uses =E2=80=9CSVG barenames=E2=80=9D= or =E2=80=9CSVG views=E2=80=9D. See = . 3. If the fragment identifier syntax is what=E2=80=99s causing the = stumbling block, how about application/yang-patch-xml and = application/yang-data-xml ? That keeps the format front-and-center but = avoids the (perceived) fragment identifier stumbling block. Best regards, Sean > On Jul 8, 2016, at 4:10 PM, Andy Bierman wrote: >=20 > Hi, >=20 > Here is the revised application/yang-patch media type registration = request > (was application/yang-patch+xml) > Type name: application >=20 > Subtype name: yang-patch >=20 > Required parameters: None >=20 > Optional parameters: None >=20 > // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with > // the actual RFC reference for YANG 1.1, and remove this note. >=20 > // RFC Ed.: replace 'XXXX' with the real RFC number, > // and remove this note >=20 > Encoding considerations: 8-bit > Each conceptual YANG data node is encoded according to the > XML Encoding Rules and Canonical Format for the specific > YANG data node type defined in = [draft-ietf-netmod-rfc6020bis]. > In addition, the "yang-patch" YANG data template found > in [RFCXXXX] defines the structure of a YANG Patch request. >=20 > // 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. >=20 > 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. >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this >=20 > // note >=20 > Interoperability considerations: [RFCXXXX] specifies the format > of conforming messages and the interpretation thereof. >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Published specification: RFC XXXX >=20 > Applications that use this media type: Instance document > data parsers used within a protocol or automation tool > that utilize the YANG Patch data structure. >=20 > Fragment identifier considerations: The fragment field in the > request URI has no defined purpose. >=20 > Additional information: >=20 > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): .xml > Macintosh file type code(s): "TEXT" >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Person & email address to contact for further information: See > Authors' Addresses section of [RFCXXXX]. >=20 > Intended usage: COMMON >=20 > Restrictions on usage: N/A >=20 > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. >=20 > Author: See Authors' Addresses section of [RFCXXXX]. >=20 > Change controller: Internet Engineering Task Force > (mailto: > iesg&ietf.org > ). >=20 > Provisional registration? (standards tree only): no >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf