Subject: Re: [media-types] [Netconf] RESTCONF media type issue

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Jun 2016 07:31:03 -0700

Hi,

I forgot to CC: the media-types list ask Benoit asked.
Maybe they have an opinion on removing the operation media type.

Andy

On Tue, Jun 21, 2016 at 6:08 AM, Ladislav Lhotka <[email-masked]> wrote:

>
> > On 21 Jun 2016, at 14:56, Andy Bierman <[email-masked]> wrote:
> >
> >
> >
> > On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka <[email-masked]> wrote:
> >
> > > On 21 Jun 2016, at 14:32, Andy Bierman <[email-masked]> wrote:
> > >
> > >
> > >
> > > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka <[email-masked]>
> wrote:
> > >
> > > > On 21 Jun 2016, at 14:16, Andy Bierman <[email-masked]> wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <[email-masked]>
> wrote:
> > > >
> > > > > On 21 Jun 2016, at 02:11, Andy Bierman <[email-masked]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > The media type definitions in RESTCONF-13 are incorrect.
> > > > > We cannot make subtypes for application/yang.
> > > > > Each RESTCONF (and YANG Patch) media type has
> > > > > to be registered.
> > > > >
> > > > >
> > > > > Approach 1) hard-wired types
> > > > >
> > > > >
> > > > > RESTCONF would register 10 media types and YANG Patch 4 media types
> > > > > if we use the hardwired approach.
> > > > >
> > > > >    application/yang-api+xml
> > > > >    application/yang-api+json
> > > > >    application/yang-datastore+xml
> > > > >    application/yang-datastore+json
> > > > >    application/yang-data+xml
> > > > >    application/yang-data+json
> > > > >    application/yang-errors+xml
> > > > >    application/yang-errors+json
> > > > >    application/yang-operation+xml
> > > > >    application/yang-operations+json
> > > > >    application/yang-patch+xml
> > > > >    application/yang-patch+json
> > > > >    application/yang-patch-status+xml
> > > > >    application/yang-patch-status+json
> > > > >
> > > > > Any new media types would need to be registered.
> > > > > No usage of the restconf-media-type is possible besides
> > > > > this list of media types for RESTCONF and YANG Patch
> > > > > without additional registrations.
> > > > >
> > > > > Approach 2) generic types with a parameter
> > > > >
> > > > > A parameter approach would allow YANG to be used to define any
> > > > > message content schema.  E.g., a mandatory "type" parameter
> > > > > that specifies the module and name of the restconf-media-type.
> > > > >
> > > > > Only 2 media type need to be registered for every media-type
> > > > > that could ever be specified (SDO or vendor)
> > > > >
> > > > >    application/yang-data-xml;type=<module>:<name>
> > > > >    application/yang-data-json;type=<module>:<name>
> > > > >
> > > > >    application/yang-data-xml;type=ietf-restconf:api
> > > > >    application/yang-data-json;type=ietf-restconf:api
> > > > >    application/yang-data-xml;type=ietf-restconf:datastore
> > > > >    application/yang-data-json;type=ietf-restconf:datastore
> > > > >    application/yang-data-xml;type=ietf-restconf:data
> > > > >    application/yang-data-json;type=ietf-restconf:data
> > > > >    application/yang-data-xml;type=ietf-restconf:errors
> > > > >    application/yang-data-json;type=ietf-restconf:errors
> > > > >    application/yang-data-xml;type=ietf-restconf:operation
> > > > >    application/yang-data-json;type=ietf-restconf:operation
> > > > >    application/yang-data-xml;type=ietf-yang-patch:yang-patch
> > > > >    application/yang-data-json;type=ietf-yang-patch:yang-patch
> > > > >    application/yang-data-xml;type=ietf-yang-patch:yang-patch-status
> > > > >
> application/yang-data-json;type=ietf-yang-patch:yang-patch-status
> > > > >
> > > > >
> > > > > If you have a preference how this issue is resolved, send comments.
> > > >
> > > > I prefer #1, as media types aren't supposed to carry schema
> information (and we do have it elsewhere). One thing to consider though is
> to reduce the number of media types. For example, it's IMO not necessary to
> have separate media types "application/yang-data" and
> "application/yang-operation" because they can be easily discriminated via
> the URI.
> > > >
> > > >
> > > >
> > > > I think #1 is simpler to implement.
> > > > I don't agree we should make operation and data resources the same
> media type.
> > > > It is useful in implementation to tell POST data from POST operation
> before parsing
> > > > the message-body.
> > >
> > > Parsing and resolving the RequestURI should be sufficient to tell them
> apart, no?
> > >
> > >
> > > no...
> > >
> > >
> > > container foo {
> > >    container input {
> > >       leaf X { type string; }
> > >    }
> > >    action bar {
> > >       input {
> > >          leaf X { type string; }
> > >       }
> > >     }
> > >  }
> > >
> > >
> > > POST /restconf/data/foo
> > >
> > > { "input" : {
> > >      "X" : "so is this an invocation of action bar or a creation of
> container input?"
> > >    }
> > > }
> >
> > Shouldn't the action be invoked with
> >
> > POST /restconf/data/foo/bar
> >
> >
> >
> > yes -- the URIs will be different.
> >
> > I don't see what problem it solves to change it now.
> > Either we think RESTCONF-specific media types help or they should all be
> removed.
> >
> > To take this argument to the logical conclusion, we could dump all the
> media types
> > and just use application/xml and application/json.
> >
> > In fact, we support that in our server, proving the RESTCONF media types
> can be ignored
> > because there is enough context in the request to deduce the schema.
> >
> > I think the media types add some strong typing.
> > Not sure if that is important or not.
>
> The granularity of media types seems to be a controversial topic (feed
> Google with "media type explosion").
> I'd suggest to consult APPS folks.
>
> Lada
>
> >
> >
> > Andy
> >
> > Section 3.6 says
> >
> >    An action is invoked as:
> >
> >    POST {+restconf}/data/<data-resource-identifier>/<action>
> >
> >
> > >
> > >
> > > What problem are you solving by combining them?
> >
> > Media types should not be multiplied unnecessarily.
> >
> > Lada
> >
> > >
> > >
> > > Lada
> > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > > Lada
> > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > Andy
> > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Netconf mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> > > > --
> > > > Ladislav Lhotka, CZ.NIC Labs
> > > > PGP Key ID: E74E8C0C
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>