Re: [media-types] [Netconf] review request for media type application/yang-patch

[Sean Leonard <[e-mail]>]

My feedback remains that these ought to remain application/yang-patch+xml and application/yang-data+xml.

I would be happy to be rebuked (with appropriate justifications), but have not heard compelling reasons to vary from that course.

Three observations:
1. If you occupy application/yang-patch as the XML variant now, what happens when you have CBOR or some other fancy format du jour? Now you’ve used up the “main one”.

2. Consider that image/svg+xml uses +xml, but doesn’t use XPointer for fragment identifiers. It uses “SVG barenames” or “SVG views”. See <http://www.w3.org/TR/SVG/mimereg.html>.

3. If the fragment identifier syntax is what’s causing the stumbling block, how about application/yang-patch-xml and application/yang-data-xml ? That keeps the format front-and-center but avoids the (perceived) fragment identifier stumbling block.

Best regards,

Sean


> On Jul 8, 2016, at 4:10 PM, Andy Bierman <[e-mail]> wrote:
> 
> Hi,
> 
> Here is the revised application/yang-patch media type registration request
> (was application/yang-patch+xml)
>       Type name: application
> 
>       Subtype name: yang-patch
> 
>       Required parameters: None
> 
>       Optional parameters: None
> 
>      // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
>      // the actual RFC reference for YANG 1.1, and remove this note.
> 
>      // RFC Ed.: replace 'XXXX' with the real RFC number,
>      // and remove this note
> 
>       Encoding considerations: 8-bit
>          Each conceptual YANG data node is encoded according to the
>          XML Encoding Rules and Canonical Format for the specific
>          YANG data node type defined in [draft-ietf-netmod-rfc6020bis].
>          In addition, the "yang-patch" YANG data template found
>          in [RFCXXXX] defines the structure of a YANG Patch request.
> 
>      // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
>      // section number for Security Considerations
>      // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
>      // RFC number, and remove this note.
> 
>       Security considerations: Security considerations related
>          to the generation and consumption of RESTCONF messages
>          are discussed in Section NN of [RFCXXXX].
>          Additional security considerations are specific to the
>          semantics of particular YANG data models. Each YANG module
>          is expected to specify security considerations for the
>          YANG data defined in that module.
> 
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
> 
>      // note
> 
>       Interoperability considerations: [RFCXXXX] specifies the format
>          of conforming messages and the interpretation thereof.
> 
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
> 
>       Published specification: RFC XXXX
> 
>       Applications that use this media type: Instance document
>         data parsers used within a protocol or automation tool
>         that utilize the YANG Patch data structure.
> 
>       Fragment identifier considerations: The fragment field in the
>          request URI has no defined purpose.
> 
>       Additional information:
> 
>         Deprecated alias names for this type: N/A
>         Magic number(s): N/A
>         File extension(s): .xml
>         Macintosh file type code(s): "TEXT"
> 
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
> 
>       Person & email address to contact for further information: See
>          Authors' Addresses section of [RFCXXXX].
> 
>       Intended usage: COMMON
> 
>       Restrictions on usage: N/A
> 
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
> 
>       Author: See Authors' Addresses section of [RFCXXXX].
> 
>       Change controller: Internet Engineering Task Force
>          (mailto:
> iesg&ietf.org
> ).
> 
>       Provisional registration? (standards tree only): no
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf