Re: [netconf] issue #2 draft-ietf-netconf-https-notif (discover capabilities)

[Martin Bjorklund <[e-mail]>]

Martin Bjorklund <[e-mail]> wrote:
> Hi,
> 
> For the encoding I think we have four options:
> 
> 1)  define one fixed encoding
> 
> 2)  support multiple encodings and let the identity https derive from
>     sn:configurable-encoding.  this ties into the mechanism defined in
>     RFC 8529.  requires a "default encoding".
> 
> 3)  support multiple encodings and do not derive from
>     sn:configurable-encoding.  define a discovery mechanism that must
>     be used to dynamically figure out which encoding to use.
> 
> 4)  combination of 2+3; make it configurable, but let the default
>     encoding be dynamic
> 
> 
> I think it is quite clear that we don't want to do 1.  People have
> expressed requirements for both text-based and binary encodings.
> 
> To discover the encoding, isn't this possible with standard HTTP?
> Googling a bit showed an old I-D for an Accept-Post header that the
> server could return in response to OPTIONS; this could have been
> useful.  (Hmm, it seems it is actually
> defined:https://www.iana.org/assignments/message-headers/message-headers.xhtml)
> Perhaps someone with HTTP knowledge can recommend a solution?
> 
> As for the format of capabilities in general, I think a normal config
> false YANG model will work.

Sorry, this should be sx:structure.

> If we use OPTIONS (or GET on some related
> uri) the client can send an Accept header to indicate which format it
> prefers for this config false data as usual
> ("application/yang-data+xml" or "application/yang-data+json" or some
> other media type for binary formats)



/martin