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:
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 |
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod