Hello, Joe, Jurgen,

RFC6020 doesn't really register  file extensions, but rather media types. I don't feel we need a new mediatype for this as we really use json and xml. However I see it useful to document in the file extension that this is not just any plain old XML; it is yang instance data in XML format.  Alternatives:

  1. Use the .yid file extension (my favorite)
  2. Use 2 separate file extensions: .yidxml, .yidjson
  3. just use .xml and .json

What is the rule, do I need to register a file extension as a media-type? Is that optional? Is that needed?

regards Balazs

On 2018. 11. 28. 15:48, Juergen Schoenwaelder wrote:
On Wed, Nov 28, 2018 at 09:35:55AM -0500, Joe Clarke wrote:
On 11/23/18 07:48, Balázs Lengyel wrote:
Do you have to register the ".yid" file extension as well?
BALAZS: Is there a registry for file extensions? I was not aware.
RFC6020 section 14 registers media types that include file extensions
for .yin and .yang.  I am asking are you proposing to do the same and
registering something like application/yang-instance-data with a .yid
extension?

Isn't this just json and xml? If we need specific media types, I think
it would be two.

In theory, it would be even nicer if the document would be written in
such a way that it works with any (future) encoding. The way things
are defined today, by referring to responses of specific protocol
operations, is a bit odd. Does it matter whether the XML is returned
by a NETCONF <get-data> or RESTCONF/HTTP GET? Ideally, the format of
the instance files would be coming out of the data encoding
specifications (plus the architectural framework of datastores).

/js

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: balazs.leng...@ericsson.com 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to