Subject: [Netconf] Discovery of the Encoding Format WAS:FW: Opinion poll for the RESTCONF encoding

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Thu, 6 Aug 2015 20:21:54 +0000

All,

please use this thread for the discussion on the discovery of the encoding format.

Cheers,
Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue, Mehmet (Nokia - DE/Munich)
Sent: Thursday, August 06, 2015 10:18 PM
To: Netconf
Subject: [Netconf] Opinion poll for the RESTCONF encoding

Dear NETCONF WG,

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.

Please do state your opinion with short and concrete reasoning, by August 19, 2015 18:00 PST about the following options:

x) XML is mandatory, JSON optional,
j) JSON is mandatory, XML optional,
x&j) XML and JSON are both mandatory,
x+j) Either XML or JSON is mandatory the other one is optional,
nm) Both XML and JSON are optional and _not_ mandatory.

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.
For the solution discussion a separate thread will be started and can be finalized also after the poll deadline.

You may think that one or the other option is useless from your pov. In this case please ignore it.

Looking forward to counting your votes and reading your reasoning.
Thank you.

Best Regards,
Mehmet & Mahesh

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 6 Aug 2015 20:26:49 +0000

I will vote JSON, again.

j) JSON is mandatory, XML optional

From: <Ersue>, "Mehmet (Nokia - DE/Munich)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 6, 2015 at 1:21 PM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] Discovery of the Encoding Format WAS:FW: Opinion poll for the RESTCONF encoding

All,

Cheers,
Mehmet

Dear NETCONF WG,

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.

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.
For the solution discussion a separate thread will be started and can be finalized also after the poll deadline.

Best Regards,
Mehmet & Mahesh

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Aug 2015 23:07:27 +0200

Hi,

I believe no disussion is needed here, the solution is provided by HTTP:

- the client sends all supported encodings in the Accept request-header, perhaps also indicating the preference via the quality (q)   
  parameter.

- the client either sends the reply in one of those encodings, or replies with 406 (not supported).

Lada
  
> On 06 Aug 2015, at 22:21, Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]> wrote:
> 
> All,
>  
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 6 Aug 2015 14:34:26 -0700

[Chair hat off]

If client can indicate desired encoding format by sending it in Accept request-header, why do we need to mandate any form of encoding? If server supports the form of encoding, it will respond with a valid response. If not it will respond with a 406.

> On Aug 6, 2015, at 2:07 PM, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi,
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Aug 2015 14:41:30 -0700

On Thu, Aug 6, 2015 at 2:34 PM, Mahesh Jethanandani <[email-masked]
> wrote:

> [Chair hat off]
>
> If client can indicate desired encoding format by sending it in Accept
> request-header, why do we need to mandate any form of encoding? If server
> supports the form of encoding, it will respond with a valid response. If
> not it will respond with a 406.
>
>

I would like to limit the number of formats in the client I have to support
to a small finite number. I do not want a server claiming conformance
to RESTCONF which does not support XML or JSON, only its own
"application/text" proprietary CLI format.

Andy

> > - the client sends all supported encodings in the Accept request-header,
> perhaps also indicating the preference via the quality (q)
> >  parameter.
> >
> >> 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.
> >>
> >> 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.
> >>
> >> Please do state your opinion with short and concrete reasoning, by
> August 19, 2015 18:00 PST about the following options:
> >>
> >> 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.
> >> For the solution discussion a separate thread will be started and can
> be finalized also after the poll deadline.
> >>

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Thu, 6 Aug 2015 21:43:48 +0000

Limiting the choices to XML or JSON mandatory enforces interoperability.

As such the RESTCONF implementer must support a well-known encoding defined in the standard specification.
I believe x or j or x+j can be a solution for the standard text.

Cheers, 
Mehmet 

-----Original Message-----
From: ext Mahesh Jethanandani [mailto:[email-masked]] 
Sent: Thursday, August 06, 2015 11:34 PM
To: Ladislav Lhotka
Cc: Ersue, Mehmet (Nokia - DE/Munich); Netconf
Subject: Re: [Netconf] Discovery of the Encoding Format WAS:FW: Opinion poll for the RESTCONF encoding

[Chair hat off]

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 6 Aug 2015 14:59:57 -0700

I should have clarified. 

Do we need the options x), j) or x+j)?

Why not have x-j) as the only option, with Accept request-header being used to determine which one the server supports? 

> On Aug 6, 2015, at 2:43 PM, Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 Aug 2015 20:54:44 +0000

[Just back from PTO]

HTTP Accept headers should be regarded as a safety net, one that RESTCONF
servers most definitely MUST implement.  But I rather focus on how the
server can advertise its supported encodings, much like the <hello>
message.  For instance, the solution could leverage the
/.well-known/host-meta file:

      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.

What do you think?   // documenting this in the draft would be relatively
easy...

Kent

On 8/6/15, 5:59 PM, "Mahesh Jethanandani" <[email-masked]> wrote:

>Why not have x-j) as the only option, with Accept request-header being
>used to determine which one the server supports?
>
>>request-header, why do we need to mandate any form of encoding? If
>>server supports the form of encoding, it will respond with a valid
>>response. If not it will respond with a 406.
>> 
>>> - the client sends all supported encodings in the Accept
>>>request-header, perhaps also indicating the preference via the quality
>>>(q)   
>>> parameter.
>>> 
>>>>mandatory statements in RESTCONF, NETCONF WG co-chairs would like to
>>>>start a new opinion poll.
>>>> 
>>>> So, all interested NETCONF WG members, please speak up so that we get
>>>>a better data to judge on WG (rough) consensus.
>>>>declare consensus in the sake of progress, based on the ³dominant
>>>>view² determined by the co-chairs and AD.
>>>> 
>>>> 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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Aug 2015 23:04:33 +0200

Kent,

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.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>