Re: [netconf] restconf collections

Martin Björklund <mbj+ietf@4668.se> Thu, 29 October 2020 07:51 UTC

Return-Path: <mbj+ietf@4668.se>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1181A3A0B8E for <netconf@ietfa.amsl.com>; Thu, 29 Oct 2020 00:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=eZjJ5FxD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GXXRYbvs
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 R2PcT3-STv_r for <netconf@ietfa.amsl.com>; Thu, 29 Oct 2020 00:51:11 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4858F3A0B72 for <netconf@ietf.org>; Thu, 29 Oct 2020 00:51:11 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A06075C006F; Thu, 29 Oct 2020 03:51:10 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 29 Oct 2020 03:51:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= +nwcrWagG2XZRbqyP1NLAsJe27KM3oc2B4RysbZFgaU=; b=eZjJ5FxDPFVg8BBk XT4dN109/Hqtd68aWvEytdQSn47TBOD3UIcz1Q5vPxtKzaPOiZw18cB53qnB69Yd 0674KPHJDCOfeASDWz4DFmCMQ3qYss0r0dd029PUlHsJEJRZ0YLhFnqN1dvUDZeB V+cGK0XWcrpuan3fiDLMS1OvjsKRml9cQPbXDQiAcmhkQqvdvT2bqRGEsYFZKwIt FZczO1WVDte2zraeCzRwudp/Ird3d4SXlQ0d7vCOBfjc5w7/DEzfFbX/RpzCQkHi +k7zteG/dOp+YAq94GujfCR5/IsJp/gMutMrJ2qr4RFquYZI2tXHUx3MIBcPNmL+ GEqr3A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+nwcrWagG2XZRbqyP1NLAsJe27KM3oc2B4RysbZFg aU=; b=GXXRYbvsaNw4FNJhSEU0HHPgTG3FjvBEyyiI1B/kcGY5EqB2RuKpbl8wG w6nwbWNILqlUI21mlQcLMsAaGyYQU0ETs2PwZsJZlyWu6aAx6zxiKEeuwrMcJB/J bqnaO23VtGI4lGzDR/gxo7ig2NGkQF5d5178L/Mi+I8vS7aSQbAM3+Ltaufxiyzn GXuTdrGyOfIcG36BRgtc7KI/mBS7CKEe7WSZvrZa0POmkoWGxCMnOHRv3wHZ93rY QO5fHgA10JWEhxvH69TAo4S2dPQUnkwVXGqZ2B+OOsj6bax74xmYXC/R2dpe8pVu 2BIp+LuMe9/g4ud7pFJB3xuIi8UdQ==
X-ME-Sender: <xms:bnSaX82JrCUp75CYVd8nLX-TMuAcmZrQurD1tvUEKc_nNRDF4b15QQ> <xme:bnSaX3H2NiV6tOgwoNyzy8kYp4eiD8XUlDzAv1LhJHmYPDfl4vpJt9PoYOt0SWiGk cLyrUqdnicFklhI4ig>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrledvgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepiefhtddvgeffvdelveevle egffevheeghfeujefhteeiueduudevgfeiieffhefgnecuffhomhgrihhnpegvgigrmhhp lhgvrdgtohhmnecukfhppedvuddvrddvudegrdduuddriedtnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedr shgv
X-ME-Proxy: <xmx:bnSaX07MXF9Q3JssOuwpdR40jitG4cUGuS84PRRuUXjyfQiqDQpNUQ> <xmx:bnSaX1193Dq1S20Ld8VKzUwoQ9Zv7RXXP3EtsX5fCemcN5YIshxxKA> <xmx:bnSaX_GygpxY20B-TT2FTKwz2NayRvtgON6N8ALQzcd8HL_r3ffTJg> <xmx:bnSaX2wmPywfsb65d0kF35hKxkXiSn-CyvgfXHwR66dr2tLErgUGpQ>
Received: from localhost (212-214-11-60-static.se.customer.tele2.net [212.214.11.60]) by mail.messagingengine.com (Postfix) with ESMTPA id 9230D3280059; Thu, 29 Oct 2020 03:51:09 -0400 (EDT)
Date: Thu, 29 Oct 2020 08:51:08 +0100 (CET)
Message-Id: <20201029.085108.142889809049265936.id@4668.se>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <0100017571c59d4d-f1032aa5-103d-4443-933e-4db30f2ef641-000000@email.amazonses.com>
References: <01000174e9c75096-5f451248-48e7-4add-a56b-9789cddd3e56-000000@email.amazonses.com> <CAL73O_z+zy9wN9YOoGuA1VOTKxj4FL2Jj0N+cQ8fScT04J8-UA@mail.gmail.com> <0100017571c59d4d-f1032aa5-103d-4443-933e-4db30f2ef641-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/atAxzsY7sg6ll42I5WinpQ18-Ug>
Subject: Re: [netconf] restconf collections
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2020 07:51:14 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
> [Update: a spinoff team has formed and is working on two I-D’s]
> 
> One issue has come up, regarding the encoding when GET returns a list
> or leaf-leaf.
> 
> Generally, in RFC 8040, GET returns an instance of the targeted
> resource.  This continues to be possible with JSON, as the
> list/leaf-list is a JSON array, but no array-equivalent exists with
> XML.
> 
> This is likely why Section 4.3 states "More than one element MUST NOT
> be returned for XML encoding”, though this statement never needed to
> be said, as there is no case where more than one element would be
> returned anyway!
> 
> This intent of this email is to discuss changing that statement in
> 4.3, that is, to allow more than one element to be returned for the
> XML encoding.
> 
> Following are what I hope the WG can agree on being valid responses:
> 
> ===== JSON =====
> 
> 
>  REQUEST
> 
>     GET /restconf/data/example-jukebox:jukebox/library/artist?where=<expr>
>     Host: example.com
>     Accept: application/yang-data+json
> 
> 
>  RESPONSE-1 (list exists, but no matching content)
> 
>     HTTP/1.1 204 No Content
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
> 
> 
>  RESPONSE-2 (matching content)
> 
>     HTTP/1.1 200 OK
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
>     Content-Type: application/yang-data+json
> 
>     {
>       "example-jukebox:artist”: [
>         {
>          “name”: "Foo Fighters”,
>           “album”: {
>             “name”: "One by One”,
>             “year”: 2012
>           }
> 
>         },
>         {
>           “name”: "Nick Cave and the Bad Seeds”,
>           “album”: {
>             “name”: "Tender Pre”,
>             “year”: 1988
>           }
>         }
>       ]
>     }
> 
> 
> 
> ===== XML =====
> 
> 
>   REQUEST
> 
>     GET /restconf/data/example-jukebox:jukebox/library/artist?where=<expr>
>     Host: example.com
>     Accept: application/yang-data+xml
> 
> 
>   RESPONSE-1 (list exists, but no matching content)
> 
>     HTTP/1.1 204 No Content
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
> 
> 
>   RESPONSE-2 (matching content)
> 
>     HTTP/1.1 200 OK
>     Date: Thu, 26 Jan 2017 20:56:30 GMT
>     Server: example-server
>     Content-Type: application/yang-data+xml
> 
>     <artist xmlns="https://example.com/ns/example-jukebox">
>       <name>Foo Fighters</name>
>       <album>
>         <name>One by One</name>
>         <year>2012</year>
>       </album>
>     </artist>
>     <artist xmlns="https://example.com/ns/example-jukebox">
>       <name>Nick Cave and the Bad Seeds</name>
>       <album>
>         <name>Tender Prey</name>
>         <year>1988</year>
>       </album>
>     </artist>
> 
> 
> 
> Thoughts?  If no objection, we will proceed as per above.
> 
> PS: I am aware, of course, of the pseudo-parent element (“collection”)
> defined in in draft-ietf-netconf-restconf-collection.  The hope is to
> avoid needing to introduce a pseudo element, as the above seems
> simpler, more consistent, and without issues, other than requiring
> that statement in Section 4.3 to be rescinded.

This is not a good proposal, since the result is not a valid XML
document.  An XML document has exactly one root element.

Also, the media types used in the examples are misleading.  The
example reply doesn't match the media type
"application/yang-data+json" (same for xml).

I suggest you define new media types and a "collection" root
element; or keep the media types and define "collection" in a YANG
module as:

  anydata collection;


/martin