Subject: [media-types] Subtypes and registration trees

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Jun 2016 09:45:25 +1000

YANG is attempting to register a number of media types that begin with "application/yang."; see:
  https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#section-4.2
  https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-11.3

E.g., it calls "application/yang.api" a "subtype" of "application/yang".

I read RFC6838 to prohibit this, because the portion of a subtype preceded by the first "." indicates the registration tree in a facet, and faceted media types are prohibited from being registered in the standards tree (unless they're grandfathered in in Appendix A). Furthermore, the drafts' use of "subtype" is erroneous.

Is that understanding correct? If so, should they be using different media types, or is there some other way to accommodate what they want?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Sean Leonard <[email-masked]>
Date: Thu, 9 Jun 2016 19:15:02 -0700

When it comes to Internet media types, "subtype" refers to everything 
after the "/" and "type" refers to everything prior to the "/".

The field "Subtype name" is a field in the media type registration 
template--its usage in those drafts is correct.

When referring to the construct as a whole, the term "media type" is 
generally used, not "media subtype" or "subtype". However, I suppose 
that "subtype" would be technically correct (although not preferred) 
because application/xml (for example) is actually a subtype of 
application. Stylistically it should be called the media type 
application/xml, etc.

They should be called application/yang-api, application/yang-patch, 
application/yang-patch-status, etc.

I am assuming that YANG is referring specifically to the language (akin 
to saying "C++" or "JavaScript"), and not referring specifically to the 
structured syntax (akin to saying "JSON"). If YANG is referring 
specifically to a structured syntax, then the media types should end in 
+yang. My knowledge of YANG is not deep enough to opine further on this 
point.

Regards,

Sean

On 6/9/2016 4:45 PM, Mark Nottingham wrote:
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Jun 2016 12:34:53 +1000

> On 10 Jun 2016, at 12:15 PM, Sean Leonard <[email-masked]> wrote:
> 
> When it comes to Internet media types, "subtype" refers to everything after the "/" and "type" refers to everything prior to the "/".
> 
> The field "Subtype name" is a field in the media type registration template--its usage in those drafts is correct.

Even:

"""
The parent MIME media type for RESTCONF resources is application/yang, which is defined in [RFC6020].  This document defines the following sub-types for this media type.
"""

? That seems to read as if "application/foo.bar" is a subtype of "application/foo".

> 
> When referring to the construct as a whole, the term "media type" is generally used, not "media subtype" or "subtype". However, I suppose that "subtype" would be technically correct (although not preferred) because application/xml (for example) is actually a subtype of application. Stylistically it should be called the media type application/xml, etc.
> 
> They should be called application/yang-api, application/yang-patch, application/yang-patch-status, etc.
> 
> I am assuming that YANG is referring specifically to the language (akin to saying "C++" or "JavaScript"), and not referring specifically to the structured syntax (akin to saying "JSON"). If YANG is referring specifically to a structured syntax, then the media types should end in +yang. My knowledge of YANG is not deep enough to opine further on this point.
> 
> Regards,
> 
> Sean
>

---

From: Sean Leonard <[email-masked]>
Date: Thu, 9 Jun 2016 19:58:08 -0700

> ? That seems to read as if "application/foo.bar" is a subtype of "application/foo".

Sorry, I missed that because I did a search on "subtypes" instead of 
"sub-types" <g>.

On a technical note: is there a compelling reason why the media type has 
to be application/yang-patch? The fact that it is a patch is obvious by 
the use of the header "Accept-Patch". Why not just say application/yang, 
or application/xml, or application/json, as appropriate?

It looks (to me) like the content is obviously a patch or patch-status, 
as evidenced by strings/data elements such as

"ietf-yang-patch:yang-patch-status" and <yang-patch xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-patch">.

I do not see a compelling reason to use the media type to duplicate 
obvious information.

****
On a related note: okay, now I am seeing "sub types" in 
draft-ietf-netconf-restconf-13. Sneaky little devils, eh ;-) (I am 
referring to the subtypes, not the authors ;-) )

Specifically:

       Subtype name: yang.xxx, where "xxx" is 1 of "api",
       "data", "datastore", "errors", "operation", or "stream"

I have never seen a registration like this. Usually you have one 
registration per subtype.

What you're trying to do here, is much better served by using required 
or optional parameters, namely:
Content-Type: application/yang; subtype="xxx"

Where xxx is api, data, datastore, errors, operation, or stream. That 
way it's extensible without needing another whole RFC for it. Must say 
whether it's case sensitive; it looks case insensitive. May I suggest 
renaming the parameter to something other than subtype, although nothing 
better comes to mind...

However, I think it is duplicitous (both redundant, and underhanded) to 
have a subtype parameter when (as with yang patch) the data itself 
describes the response very clearly, such as:

<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">

We have seen this pattern elsewhere: see the registrations for PKCS #7 / 
CMS and the smime-type and encapsulatingContent parameters.

The problem is that this is basically a hint to a receiver of what lies 
inside. But what if what lies inside doesn't match the parameter? Who 
wins? You should say which one wins. Ideally, you should only have one 
place in your protocol say what it is, to avoid divergent behavior.

Regards,

Sean

---

From: Mark Baker <[email-masked]>
Date: Sat, 11 Jun 2016 01:19:12 -0400

On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard <[email-masked]> wrote:
> On a technical note: is there a compelling reason why the media type has to
> be application/yang-patch? The fact that it is a patch is obvious by the use
> of the header "Accept-Patch". Why not just say application/yang, or
> application/xml, or application/json, as appropriate?

For the same reason we deliver HTML as text/html and not text/sgml or
text/plain.

IMO, these registrations look like they just need a +yang suffix. What
they're currently doing is defining subtype facets as peers to vnd,
prs, and x, and I can't imagine that was the intent.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Jun 2016 23:17:12 -0700

On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker <[email-masked]> wrote:

> to

YANG is not an encoding format. It is a schema language.
Instance documents conforming to YANG schema are encoded in XML or JSON.

Andy

---

From: Sean Leonard <[email-masked]>
Date: Sat, 11 Jun 2016 10:17:22 -0700

On 6/10/2016 11:17 PM, Andy Bierman wrote:
>
>
> On Fri, Jun 10, 2016 at 10:19 PM, Mark Baker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard
>     <[email-masked] <mailto:[email-masked]>> wrote:

That confirms my suspicion. So, these proposed media type(s) should have 
+xml, +json, or nothing (as structured syntax suffixes are optional, 
they are really intended more as a hint to intermediate decoders such as 
debugging tools). They should not have +yang.

Sean

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Jun 2016 10:22:18 -0700

On Sat, Jun 11, 2016 at 10:17 AM, Sean Leonard <[email-masked]> wrote:

>> On Thu, Jun 9, 2016 at 10:58 PM, Sean Leonard < <[email-masked]>
>> [email-masked]> wrote:
> +xml, +json, or nothing (as structured syntax suffixes are optional, they
> are really intended more as a hint to intermediate decoders such as
Yes.  The CORE WG is developing a YANG to CBOR mapping
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-00

So we have +xml and +json now, and soon +cbor

I think the original question was whether our IANA requests were correct or
not.

Sean
Andy

---

From: Mark Baker <[email-masked]>
Date: Mon, 13 Jun 2016 12:33:58 -0400

> debugging tools). They should not have +yang.

Yah, having just spent some quality time with RFC 6090 over the weekend, I
concur.

And to answer mnot's question, yep, the period needs to go.

---

From: Sean Leonard <[email-masked]>
Date: Mon, 13 Jun 2016 19:35:03 -0700

On 6/13/2016 9:33 AM, Mark Baker wrote:
>
> On Sat, Jun 11, 2016 at 1:17 PM, Sean Leonard <[email-masked] 
> <mailto:[email-masked]>> wrote:
> they
> Yah, having just spent some quality time with RFC 6090 over the 
> weekend, I concur.
>
You mean this RFC 6090?

  Fundamental Elliptic Curve Cryptography Algorithms

Not sure if that is the right RFC for the topic...

Sean

---

From: Mark Baker <[email-masked]>
Date: Mon, 13 Jun 2016 23:51:02 -0400

> You mean this RFC 6090?

Obviously not. I meant 6020.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Jun 2016 10:26:38 -0700

On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <[email-masked]> wrote:

> The parent MIME media type for RESTCONF resources is application/yang,
> which is defined in [RFC6020].  This document defines the following
> sub-types for this media type.
> """
>

I can see from RFC 6838, 4.2 that we named all of our media types
incorrectly.

The media type application/yang just refers to UTF-8 text that represents a
YANG
module or submodule. It is expected to conform to the YANG syntax.

https://tools.ietf.org/html/rfc6020#section-14.1

We are incorrectly using this as a tree root for adding subtypes.

We want to create media types that conform to a particular YANG schema.
We defined a YANG extension hack to define YANG data structures for a media
type
https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-8
(see restconf-media-type)

Our IANA section for Media Sub Types is wrong

It appears we have to make a Media Type registration similar to RFC 6020
14.1
for each of (what we call) the sub-types.

     application/yang-api
     application/yang-data
     application/yang-datastore
     application/yang-errors
     application/yang-operation
     application/yang-stream

     application/yang-patch
     application/yang-patch-status

Andy

> generally used, not "media subtype" or "subtype". However, I suppose that
> "subtype" would be technically correct (although not preferred) because
> application/xml (for example) is actually a subtype of application.
> Stylistically it should be called the media type application/xml, etc.
> >
> >> I read RFC6838 to prohibit this, because the portion of a subtype
> preceded by the first "." indicates the registration tree in a facet, and
> faceted media types are prohibited from being registered in the standards
> tree (unless they're grandfathered in in Appendix A). Furthermore, the
> drafts' use of "subtype" is erroneous.
> >>
> >> Is that understanding correct? If so, should they be using different
> media types, or is there some other way to accommodate what they want?
> >>
> >> Cheers,
> >>
> >>
> >> --

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Jun 2016 09:36:04 +0200

I'm not sure what the conclusion is regarding this email thread?
Also, it should be time to include the NETCONF community on this topic.
Why not an email thread with both netconf and media-types?

Regards, B.
>
>
> On Thu, Jun 9, 2016 at 7:34 PM, Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > On 10 Jun 2016, at 12:15 PM, Sean Leonard <[email-masked]
>     > When it comes to Internet media types, "subtype" refers to
>     everything after the "/" and "type" refers to everything prior to
>     the "/".
>     >
>     > The field "Subtype name" is a field in the media type
>     registration template--its usage in those drafts is correct.
>
>     Even:
>
>     """
>     The parent MIME media type for RESTCONF resources is
>     application/yang, which is defined in [RFC6020].  This document
>     defines the following sub-types for this media type.
>     """
>
> The media type application/yang just refers to UTF-8 text that 
> represents a YANG
> We defined a YANG extension hack to define YANG data structures for a 
> media type
> It appears we have to make a Media Type registration similar to RFC 
> 6020 14.1
>     > When referring to the construct as a whole, the term "media
>     type" is generally used, not "media subtype" or "subtype".
>     However, I suppose that "subtype" would be technically correct
>     (although not preferred) because application/xml (for example) is
>     actually a subtype of application. Stylistically it should be
>     called the media type application/xml, etc.
>     >
>     > They should be called application/yang-api,
>     application/yang-patch, application/yang-patch-status, etc.
>     >
>     > I am assuming that YANG is referring specifically to the
>     language (akin to saying "C++" or "JavaScript"), and not referring
>     specifically to the structured syntax (akin to saying "JSON"). If
>     YANG is referring specifically to a structured syntax, then the
>     media types should end in +yang. My knowledge of YANG is not deep
>     enough to opine further on this point.
>     >
>     > Regards,
>     >
>     > Sean
>     >
>     >> I read RFC6838 to prohibit this, because the portion of a
>     subtype preceded by the first "." indicates the registration tree
>     in a facet, and faceted media types are prohibited from being
>     registered in the standards tree (unless they're grandfathered in
>     in Appendix A). Furthermore, the drafts' use of "subtype" is
>     erroneous.
>     >>
>     >> Is that understanding correct? If so, should they be using
>     different media types, or is there some other way to accommodate
>     what they want?
>     >>
>     >> Cheers,
>     >>
>     >>
>     >> --
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Jun 2016 04:42:45 -0700

> Why not an email thread with both netconf and media-types?
I am changing the media type name so that faceted names are not used.

yang.foo becomes yang-foo

The IANA registration section is being redone to conform to RFC 6838

Andy

>> > On 10 Jun 2016, at 12:15 PM, Sean Leonard < <[email-masked]>
> The media type application/yang just refers to UTF-8 text that represents
> a YANG

---

From: Sean Leonard <[email-masked]>
Date: Fri, 17 Jun 2016 05:59:17 -0700

On 6/17/2016 4:42 AM, Andy Bierman wrote:
>
>
> On Fri, Jun 17, 2016 at 12:36 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

application/yang.foo -> application/yang-foo

corrects the faceted name problem, yes.

However, the other point has not been addressed. I do not see a 
technical reason or justification for registering 8 media types, when 
application/yang; yangtype="foo" (api, data, datastore, errors, 
operation, stream, patch, patch-status) suffices. Please address.

Best regards,

Sean

>>         > On 10 Jun 2016, at 12:15 PM, Sean Leonard
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>         >
>>         everything after the "/" and "type" refers to everything
>>         prior to the "/".
>>         >
>>         application/yang, which is defined in [RFC6020].  This
>>         document defines the following sub-types for this media type.
>>         """
>>
>>     We defined a YANG extension hack to define YANG data structures
>>     for a media type
>>     It appears we have to make a Media Type registration similar to
>>     RFC 6020 14.1
>>         However, I suppose that "subtype" would be technically
>>         correct (although not preferred) because application/xml (for
>>         example) is actually a subtype of application. Stylistically
>>         it should be called the media type application/xml, etc.
>>         >
>>         language (akin to saying "C++" or "JavaScript"), and not
>>         referring specifically to the structured syntax (akin to
>>         saying "JSON"). If YANG is referring specifically to a
>>         structured syntax, then the media types should end in +yang.
>>         My knowledge of YANG is not deep enough to opine further on
>>         this point.
>>         >
>>         > Regards,
>>         >
>>         > Sean
>>         >
>>         >> YANG is attempting to register a number of media types
>>         that begin with "application/yang."; see:
>>         >>
>>         subtype preceded by the first "." indicates the registration
>>         tree in a facet, and faceted media types are prohibited from
>>         being registered in the standards tree (unless they're
>>         grandfathered in in Appendix A). Furthermore, the drafts' use
>>         of "subtype" is erroneous.
>>         >>
>>         different media types, or is there some other way to
>>         accommodate what they want?
>>         >>
>>         >> Cheers,
>>         >>
>>         >>
>>         >> --

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Jun 2016 16:46:51 +0200

> operation, stream, patch, patch-status) suffices. Please address.
Is this a constraint imposed by the media-type designated expert or a 
preference?
Maybe this is mentioned by one of the RFCs at 
http://www.iana.org/assignments/media-types/media-types.xhtml? Sorry I 
have not read them all.
If a preference, then it should be discussed on the NETCONF mailling list.

Regards, Benoit

>>>     I can see from RFC 6838, 4.2 that we named all of our media
>>>     types incorrectly.
>>>
>>>         > When referring to the construct as a whole, the term
>>>         "media type" is generally used, not "media subtype" or
>>>         "subtype". However, I suppose that "subtype" would be
>>>         technically correct (although not preferred) because
>>>         application/xml (for example) is actually a subtype of
>>>         application. Stylistically it should be called the media
>>>         type application/xml, etc.
>>>         >
>>>         grandfathered in in Appendix A). Furthermore, the drafts'
>>>         use of "subtype" is erroneous.
>>>         >>
>>>         >> Is that understanding correct? If so, should they be
>>>         using different media types, or is there some other way to

---

From: Mark Baker <[email-masked]>
Date: Fri, 17 Jun 2016 11:01:28 -0400

On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard <[email-masked]> wrote:
> However, the other point has not been addressed. I do not see a technical
> reason or justification for registering 8 media types, when
> application/yang; yangtype="foo" (api, data, datastore, errors, operation,
> stream, patch, patch-status) suffices. Please address.

Each of those vocabularies are distinct languages with no - AFAICT -
compatibility defined between them. Parameters aren't meant to carry
additional typing info, though are occasionally used this way - in a
non-authoritative manner - for certain types of compound documents
(eg. media containers/codecs). That doesn't appear to apply here.

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Jun 2016 09:36:47 -0700 (PDT)

> (eg. media containers/codecs). That doesn't appear to apply here.

If so, then it sounds to me like distinct types are entirely appropriate.

Generally speaking we try not to have more than one name for a given type - the
reasons for this are, I hope, obvious. If there's a need to carry information
externally to further label the type or control it's handling, that's what type
and disposition parameters are for.

That said, we have made exceptions in cases where types are used in  contexts
where additional external parameterization isn't possible. This has happened
several times, and it's why there's no hard rule requiring a single name
for a type.

				Ned

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Jun 2016 09:58:18 -0700

On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed <[email-masked]> wrote:

> technical
> operation,

I would really like to simplify the registration.
Do I need 1 registration for +xml and another for +json?
If so, then there are 16 of these. So far.

They all share the common property that the instance document conforms
to a specific YANG "restconf-media-type". This is a YANG extension and
can be used in any YANG module, so there could be 100s or 1000s of these
that will never get registered.

If we could have 1 media type with a parameter, plus encoding, that would
be best.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Jun 2016 16:21:42 -0700

Hi,

We would like to support the restconf-media-type even from different YANG
modules:

module A {
   import ietf-restconf { prefix rc; }
   rc:restconf-media-type "foo" {
       container X { }
   }

}

module B {
   import ietf-restconf { prefix rc; }
   rc:restconf-media-type "foo" {
       container Y { }
   }

}

We cannot control usage of this YANG extension and therefore we cannot
prevent duplicates.
The current proposal will not work.

1 media type with a mandatory parameter "type" would work for what we need:

    application/yang-data+xml;type=A:foo

    application/yang-data+xml;type=B:foo

    application/yang-data+json;type=B:foo

Andy

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Jun 2016 19:12:31 -0700 (PDT)

> Do I need 1 registration for +xml and another for +json?

That's entirely dependent on how the types are used. If all of your
applications that use these types accept data in either format and don't
require external information to tell them what to do, then there's no need to
have separate types. (Of course you cannot use type suffixes in this case.)

But if applications are more selective and only support a specific format
or require external information to tell them what format to use or produce,
then that's an indication you need separate types.

There are past examples of both sorts of registrations - there was one recent
type that was available in half a dozen different formats. Whereas the choice
for CGM types many years ago was for separate types (3 distinct formats, as I
recall).

> If so, then there are 16 of these. So far.

So? Names are cheap.

> that will never get registered.

This may argue for using internal labelling or perhaps a parameter to make
these distinctions, but I fail to see what this has to do with types using
different formats. I seriously doubt there are 100s or 1000s of +foos in play
here.

I also fail to see how this differs from the general situation surrounding
XML or JSON based types in general. We let people define separate types
when they need them but also have application/xml and application/json
available.

> If we could have 1 media type with a parameter, plus encoding, that would

AFAICT that's an option. It's up to you, as designers of the base format, to
decide on the best labelling system. And note that you could have two base
types application/base+xml and application/base+json.

				Ned

---

From: Sean Leonard <[email-masked]>
Date: Fri, 17 Jun 2016 22:35:50 -0700

I agree with Andy, based on my understanding of netconf/YANG.

(NB: I am not heavily involved with YANG, but I did read through the 
specifications in arriving at these conclusions. I am also not the media 
types expert reviewer, but I have put a number of media types through. 
Therefore my opinion is just that: an "informed opinion".)

YANG works on "YANG Modules"; a YANG module is a hierarchy of nodes that 
can include sub-modules. Each YANG module has its own vocabulary of 
sorts. There are identifier strings for the modules and the nodes, so 
that a YANG processor can figure out what the module is about, as long 
as it knows that the data is YANG in the first place. There is "internal 
labeling".

YANG can be serialized as XML and JSON. There is also movement to 
serialize it in CBOR.

Based on this description, +xml, +json, and (eventually) +cbor are 
appropriate. By having separate media type (suffixes) for these, clients 
and servers can advertise the kinds of YANG they support. A constrained 
device, for example, might only want to accept +cbor based YANG.

Andy and Ned made two counterpoints:
Andy: "If so, then there are 16 of these. So far. / They all share the 
common property ... "restconf-media-type". This is a YANG extension and 
can be used in any YANG module, so there could be 100s or 1000s of these 
that will never get registered. / If we could have 1 media type with a 
parameter, plus encoding, that would be best."

Ned: So? Names are cheap.

There are two points here: burden of registration and burden on 
implementations.
Names (media types) are indeed "cheap", in the sense that you just need 
to fill out (properly) a registration template for each name, and 
probably nobody is going to squat on anything after application/yang* 
for things other than YANG/RESTCONF. (Note the "probably"--there is no 
registration rule that says that YANG has dibs on everything starting 
with application/yang* either.)

However, you do have to fill out registration templates for each one. So 
that would be 16+ registrations. And if indeed there are 100s or 1000s 
of YANG module names, then you need 100s or 1000s of media type 
registration templates. That seems like an unnecessary administrative 
burden all around. Furthermore, the MIME/media type parser component has 
to be aware of these "100s or 1000s of names", which means duplicated code.

The underlying engineering questions are, how are YANG modules named and 
identified, and how does the set of YANG modules grow?

Is all YANG data is self-describing (assuming that it's YANG) in all 
formats, namely, that somewhere at the beginning, some identifier 
declares the module type, such as "ietf-restconf:errors" (JSON) and 
'<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">' (XML)?

If so, then we have an analogous situation to application/cms and 
application/pkcs7-mime, namely, the identifier is baked into the 
container format, so it only needs one media type, and a parameter that 
repeats the identifier can be optional (namely, as a "hint" to a MIME 
parser without cracking open the contents).

If not, then either the parameter is required (to discriminate the 
data), or you should consider registering multiple media types.

Another point (mainly @Andy): Are you proposing a difference between 
application/yang and application/yang-data? What is the difference, if 
anything?

Third point: If we go down the media type parameter route, can we reuse 
an existing registry? I note that RFC 6020 establishes a "YANG Module 
Names" registry 
<http://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml>. 
This already has nice neat ASCII strings to use in the "Prefix (Modules 
Only)" column. How about  considering using those?

Sean

On 6/17/2016 4:21 PM, Andy Bierman wrote:
> Hi,
>
>
> We would like to support the restconf-media-type even from different 
> YANG modules:
>
> module A {
> On Fri, Jun 17, 2016 at 9:36 AM, Ned Freed <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Fri, Jun 17, 2016 at 8:59 AM, Sean Leonard

---

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Jun 2016 10:28:10 -0700

Hi,

Perhaps the simplest solution is to make the 16 registrations that are
known at this time.

The NETCONF WG is not actually chartered to support a generic solution for
the restconf-media-type extension.  The official list of RESTCONF
media-types
is not likely to grow.

It is not always self-evident from the method and request URI which schema
to use
for the message-body. (e.g., operation vs. data vs. datastore have
different schema contexts).

The existing YANG media types in RFC 6020 do not apply.
They refer to representations of YANG schema documents.
The restconf-media-type is for representations of YANG instance data.

Andy

On Sat, Jun 18, 2016 at 9:32 AM, Ned Freed <[email-masked]> wrote:

> Again, this seems very similar to the general situation with XML and JSON:
> An effectively infinite number of specific vocabularies, each with
> their own semantics, can be created.
>
> Our solution in this case has been to allow, but not require, the
> specification
> of separate types for different vocabularies, and to provide generic types
> when
> you don't want or need a specific type.
>
> Another alternative is to carry the information in a type parameter. This
> has
> been done several times as well, both as a mandatory parameter (appropriate
> when the type cannot be immediately deduced from the content), or optional
> (either as a hint or as an alternate label when the label in the content
> itself
> is optional).
>
> Given the incredibly wide diversity of XML-based and JSON-based types
> a parameter didn't seem apropriate. But YANG is much more limited in scope.
>
> This seems reasonable.
> You've missed my point, it seems, which was that the possibility of having
> many
> types is not in an of itself an argument against requiring separate type
> specifications. Nothing more.
>
> That's assuming current process rules. If a situation actually arose where
> there was a demonstrable need to register 1000s of separate types on an
> ongoing
> basis, I have no doubt it would also make sense to define a streamlined
> process
> of some sort.
>
> As for parser awareness, such a massive set of registrations would
> certainly
> include some sort of naming rule, and while I've learned not to expect too
> much
> from developers, I think special casing such a convention would likely be
> within the capabilites of most.
>
> All that said, and speaking entirely as an observer, I'm not seeing the
> case
> for separate types here. But that doesn't mean there isn't one to be made.
>
> Exactly! And those are questions for the folks writing this specification.
>
> The type registration and review process provides a set of services that
> may
> (or may not) be of use here. And to the extent there are limitations on
> those
> services, it's important to recogize what those are so appropriate use can
> be
> made of what's available.
>
> But that's as far as it goes.
>
> Right again.
> Reusing an existing registry makes all sorts of sense IMO.
>
>                                 Ned
>

---

From: Ned Freed <[email-masked]>
Date: Sat, 18 Jun 2016 09:32:03 -0700 (PDT)

Our solution in this case has been to allow, but not require, the specification
of separate types for different vocabularies, and to provide generic types when
you don't want or need a specific type.

Another alternative is to carry the information in a type parameter. This has
been done several times as well, both as a mandatory parameter (appropriate
when the type cannot be immediately deduced from the content), or optional
(either as a hint or as an alternate label when the label in the content itself
is optional).

This seems reasonable.

> Ned: So? Names are cheap.

You've missed my point, it seems, which was that the possibility of having many
types is not in an of itself an argument against requiring separate type
specifications. Nothing more.

That's assuming current process rules. If a situation actually arose where
there was a demonstrable need to register 1000s of separate types on an ongoing
basis, I have no doubt it would also make sense to define a streamlined process
of some sort.

As for parser awareness, such a massive set of registrations would certainly
include some sort of naming rule, and while I've learned not to expect too much
from developers, I think special casing such a convention would likely be
within the capabilites of most.

All that said, and speaking entirely as an observer, I'm not seeing the case
for separate types here. But that doesn't mean there isn't one to be made.

The type registration and review process provides a set of services that may
(or may not) be of use here. And to the extent there are limitations on those
services, it's important to recogize what those are so appropriate use can be
made of what's available.

Right again.

				Ned