Subject: Re: [Netconf] Discovery of encoding format

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Aug 2015 09:30:57 +0200

> On 10 Aug 2015, at 21:36, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> One advantage of Accept is that the server can support different
> encoding formats for different resources.
> 
> The XRD approach saves a round-trip (if the client guesses wrong)

I think the client needn’t guess but rather specify all supported encodings, possibly with priorities expressed via “q” parameter.

Lada

> but the info applies to the server in general, not a specific resource.
> 
> It is useful to do both.
> (And that's what HTTP provides).
> 
> Some of the questions on the NETCONF mailing list show
> a complete ignorance of how HTTP works.  Since RESTCONF
> relies on HTTP, we are careful not to reinvent anything already
> handled by HTTP.
> 
> 
> Andy
> 
> 
> On Mon, Aug 10, 2015 at 12:30 PM, Mahesh Jethanandani <[email-masked]> wrote:
> Kent,
> 
> As you catch up with your e-mail, you will find a thread that Mehmet kicked off around the question of how the client will discover the encodings supported by the server. You might want to take the discussion to that thread.
> 
> As you do that, maybe you can elaborate on how this process is different/better than using the ‘Accept request-header’ discussion that has already taken place on the thread.
> 
> Cheers.
> 
>> On Aug 10, 2015, at 12:05 PM, Kent Watsen <[email-masked]> wrote:
>> 
>> 
>> [Just back from PTO and catching up on email]
>> 
>> The solution should leverage the /.well-known/host-meta file.  For instance:
>> 
>>       Request
>>       -------
>>       GET /.well-known/host-meta users HTTP/1.1
>>       Host: example.com
>>       Accept: application/xrd+xml
>> 
>> 
>>       Response
>>       --------
>>       HTTP/1.1 200 OK
>>       Content-Type: application/xrd+xml
>>       Content-Length: nnn
>>       <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
>>           <Link rel='restconf' href='/restconf'>
>>               <Property type="urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>json</Property>
>>               <Property type="urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>xml</Property>
>>           </Link>
>>       </XRD>
>> 
>> In the above example, the RESTCONF server supports both the JSON and XML encodings.
>> 
>> Documenting this in the draft would be relatively easy...
>> 
>> Thanks,
>> Kent
>> 
>> 
>> From: Mahesh Jethanandani <[email-masked]>
>> Date: Thursday, August 6, 2015 at 4:09 PM
>> To: Andy Bierman <[email-masked]>
>> Cc: Ladislav Lhotka <[email-masked]>, "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>, Kent Watsen <[email-masked]>, Martin Bjorklund <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, Benoit Claise <[email-masked]>
>> Subject: Re: Opinion poll for the RESTCONF Encoding
>> 
>> As I understand, option x-j) stands as follows:
>> 
>> RESTCONF server MUST support XML or JSON. Discovery of which encoding format will be done with the use of 'Accept Header' in HTTP. The server will return “406 Not Acceptable” if the desired encoding format in 'Accept Header' is not supported by the server.
>> 
>> For option x), and  j) ‘Accept Header’ can be used to discover whether the optional encoding is supported.
>> 
>> For option x+j), no ‘Accept Header’ is required.
>> 
>> Did I get it right?
>> 
>> Question: Do we really need option x), j) or x+j) if we can discover the encoding format supported?
>> 
>>> On Aug 6, 2015, at 12:27 PM, Andy Bierman <[email-masked]> wrote:
>>> 
>>> OK I updated the issue tracker
>>> 
>>> 
>>> On Thu, Aug 6, 2015 at 12:18 PM, Mahesh Jethanandani <[email-masked]> wrote:
>>>> Just to be clear. nm) is not an option.
>>>> 
>>>> Can we update the GitHub to reflect this discussion?
>>>> 
>>>>> On Aug 6, 2015, at 10:44 AM, Andy Bierman <[email-masked]> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Aug 6, 2015 at 12:01 AM, Ladislav Lhotka <[email-masked]> wrote:
>>>>>> "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]> writes:
>>>>>> 
>>>>>> > Hi Andy,
>>>>>> >
>>>>>> > I remember at least some of the folks saying that they don’t like any mandatory encoding and everything should be optional.
>>>>>> > So the options below are just to provide a complete list independent
>>>>>> > of any potential stupidity.
>>>>>> 
>>>>>> But Andy's option doesn't seem to be included in the list: a server MUST
>>>>>> implement XML or JSON encoding (or both).
>>>>> 
>>>>> maybe that is x-j
>>>>> 
>>>>> The wording might be
>>>>> 
>>>>>   Either XML or JSON MUST be supported by the server.
>>>>> 
>>>>> This does not explicitly state that the the one not picked MAY
>>>>> be supported by the server.
>>>>> 
>>>>> 
>>>>>> 
>>>>>> As for negotiation, I believe HTTP already has an established solution:
>>>>>> The client sends supported media types in Accept request-header. If the
>>>>>> server doesn't support any of them, it sends a 406 response (not
>>>>>> acceptable).
>>>>>> 
>>>>> 
>>>>> yes -- HTTP already defines this mechanism so we don't have
>>>>> to add any discovery
>>>>> 
>>>>>  
>>>>>> Lada
>>>>>> 
>>>>> 
>>>>> Andy
>>>>>  
>>>>>> >
>>>>>> > Cheers,
>>>>>> > Mehmet
>>>>>> >
>>>>>> > From: ext Andy Bierman [mailto:[email-masked]]
>>>>>> > Sent: Tuesday, August 04, 2015 6:56 PM
>>>>>> > To: Ersue, Mehmet (Nokia - DE/Munich)
>>>>>> > Cc: Kent Watsen; Martin Bjorklund; Juergen Schoenwaelder; ext Ladislav Lhotka; Benoit Claise; ext Mahesh Jethanandani
>>>>>> > Subject: Re: Opinion poll for the RESTCONF Encoding
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Tue, Aug 4, 2015 at 9:33 AM, Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > just before sending out the new opinion poll the discussion concerning "XML or JSON is mandatory" raised.
>>>>>> > To be fair we now prepared a complete list of options to go to the opinion poll.
>>>>>> >
>>>>>> > Please comment especially on the need for a solution to determine the used encoding for the cases
>>>>>> > “XML or JSON, one of them is mandatory” and “Both XML and JSON are _not_ mandatory”.
>>>>>> > Thanks.
>>>>>> >
>>>>>> >
>>>>>> > I don't think anybody is really proposing that the server is not required
>>>>>> > to support any standard encoding.
>>>>>> >
>>>>>> > The proposal is to say the server MUST support XML or JSON.
>>>>>> > Changed from "MUST support XML".
>>>>>> >
>>>>>> >
>>>>>> > Mehmet
>>>>>> > ----------------
>>>>>> >
>>>>>> >
>>>>>> > Andy
>>>>>> >
>>>>>> >
>>>>>> > Dear All,
>>>>>> >
>>>>>> > last October we had an opinion poll on the RESTCONF encoding, which ended with a close consensus in favor of XML as mandatory.
>>>>>> > See https://mailarchive.ietf.org/arch/msg/netconf/YSEbLd-nnI0dlkeiIeGW-z6JqDg
>>>>>> >
>>>>>> > Based on the recent discussion on this topic and opinions against mandatory statements in RESTCONF,
>>>>>> > NETCONF WG co-chairs would like to start a new opinion poll.
>>>>>> >
>>>>>> > As stated in the mail for the previous poll, the result of the poll depends on the count of people voting.
>>>>>> > So, all interested NETCONF WG members, please speak up so that we get a better data to judge on WG (rough) consensus.
>>>>>> > If the voting result is again close, the WG co-chairs will (again) declare consensus, in the sake of progress, based on the “dominant view” determined by the co-chairs and AD.
>>>>>> >
>>>>>> > Pls do state your opinion by [date here 2 weeks from now on].
>>>>>> >
>>>>>> > Please state your opinion about these options:
>>>>>> >
>>>>>> > x) XML is mandatory, JSON optional,
>>>>>> > j) JSON is mandatory, XML optional,
>>>>>> > x+j) XML and JSON are both mandatory,
>>>>>> > x-j) XML or JSON, one of them is mandatory the other one is optional,
>>>>>> > nm) Both XML and JSON are _not_ mandatory and are optional.
>>>>>> > For “x-j” and “nm” please provide a solution for a successful negotiation or determination of the encoding to be used between server and client.
>>>>>> > The solution can be finalized after the poll deadline.
>>>>>> >
>>>>>> >
>>>>>> > Cheers,
>>>>>> > Mehmet
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> 
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>> 
>>>> 
>>>> Mahesh Jethanandani
>>>> [email-masked]
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> Mahesh Jethanandani
>> [email-masked]
>> 
>> 
>> 
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
> 
> 

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Aug 2015 18:01:37 +0000

On 8/11/15, 3:30 AM, "Ladislav Lhotka" <[email-masked]> wrote:
> I think the client needn¹t guess but rather specify all supported
> encodings, possibly with priorities expressed via ³q² parameter.

+1 and, of course, the server's Content-Type would indicate which encoding
was selected.

On 8/10/15, 5:04 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:
> what is wrong with the client trying its preferred encoding and if the
> server says 'sorry' the client switches the encoding? Your proposal
> does not save any round trips.

For me it's not an issue of saving round-trips so much as being explicit
about such things.  And, since it's easy enough to do, why not?   Of
course, I'm assuming that the server's support for encodings is global,
not resource-specific.  If the supported encodings can vary by resource,
then this won't work...

Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Aug 2015 11:16:35 -0700

> +1 and, of course, the server's Content-Type would indicate which encoding

The Accept header is a bit complicated to support.
I suspect this will be one of the many areas where server implementations
will vary greatly.

> not resource-specific.  If the supported encodings can vary by resource,

The XRD data may help the client if the server implements XML or
JSON but not both.   Then the client knows it can skip the
Accept headers because there is only 1 encoding choice.

Since the server may support JSON for some resources and XML
for other resources, the Accept header is still needed if the
server supports both.

Andy

>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>