Re: [Netconf] Opinion poll on RESTCONF encoding

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> Andy Bierman <[e-mail]> writes:
> 
> > On Wed, Aug 26, 2015 at 5:03 PM, Mahesh Jethanandani <
> > [e-mail]> wrote:
> >
> >> A little more than two weeks ago, the chairs of NETCONF WG had issued a
> >> opinion poll on RESCONF encoding. The options given were:
> >>
> >> 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.
> >>
> >> The option x+j won by a large margin and at this time can be declared as
> >> the rough consensus by the WG.
> >>
> >> Separately, a secondary question was raised around how the encoding could
> >> be or would be discovered. On that we do not seem to have a consensus. Two
> >> proposals that were made are:
> >>
> >>
> >>    1. Client sends all supported encodings in Accept request-header, with
> >>    an (optional) preference indication via quality (q). Server responds with
> >>    one of the encodings or 406 (not supported). The encoding formats would be
> >>    limited to a small set - XML and JSON with this option to encourage
> >>    interoperability.
> >>    2. Server advertises support of encodings using the
> >>    ./well-known/host-meta file and XRD.
> >>
> >>
> >> Please indicate your opinion on the discovery of encoding part of the
> >> discussion. This opinion will not change the consensus on the poll of
> >> RESTCONF encoding.
> >>
> >>
> > This really isn't subject to the opinion of the WG.
> > HTTP uses the Accept header.
> > The only issue for RESTCONF is what does the server do if
> > there is no Accept header from the client?
> > Currently I think the draft says the server will send XML by default.
> > It needs to change to be silent and let the server send whatever it wants.
> >
> > Even if (2) was done the server still MUST support the Accept header.
> 
> I agree with Andy, this is really HTTP business, and RESTCONF is just an
> application on top of it.

I agree that we should not specify anything about the Accept header;
that is HTTP's business.

But this doesn't mean that (2) cannot be useful.  With (2) a client
can learn the encodings supported by the server before it constructs
payload in an encoding that may or may not be supported by the server.


/martin