Re: [media-types] [Netconf] request review of media type application/yang-data+xml

[Andy Bierman <[e-mail]>]

On Tue, Jun 28, 2016 at 8:17 PM, Sean Leonard <[e-mail]> wrote:



removing all text except the fragment identifier issue....

According to RFC 7303, sec. 5, any usage of +xml requires implementation of
the XPointerFramework
https://www.w3.org/TR/2003/REC-xptr-framework-20030325/

RESTCONF "fragments" are sub-trees within the YANG data structures.
These are accessed by the request URI path and the "fields" query parameter.
XPointer is rather complex and completely redundant for RESTCONF.

So do we have to add text that a RESTCONF server MUST implement the
"element"
scheme?






>
>
>    Fragment identifier considerations: The fragment field in the
>       request URI has no defined purpose.
>
>
> From the perspective of NETCONF this is probably correct. However, Section
> 4.11 of RFC 6838 says:
>
>    Media types are encouraged to adopt fragment identifier schemes that
>    are used with semantically similar media types.  In particular, media
>    types that use a named structured syntax with a registered "+suffix"
>    MUST follow whatever fragment identifier rules are given in the
>    structured syntax suffix registration.
>
>
> There are some things about +xml things:
>
> http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
>
> RFC 7303.
>
> Look it up.
>
>



   The syntax and semantics of fragment identifiers for the XML media
   types defined in this specification are based on the
   [XPointerFramework
<https://tools.ietf.org/html/rfc7303#ref-XPointerFramework>] W3C
Recommendation.  It allows simple names and
   more complex constructions based on named schemes.  When the syntax
   of a fragment identifier part of any URI or Internationalized
   Resource Identifier (IRI) ([RFC3987
<https://tools.ietf.org/html/rfc3987>]) with a retrieved media type
   governed by this specification conforms to the syntax specified in
   [XPointerFramework
<https://tools.ietf.org/html/rfc7303#ref-XPointerFramework>],
conforming applications MUST interpret such
   fragment identifiers as designating whatever is specified by the
   [XPointerFramework
<https://tools.ietf.org/html/rfc7303#ref-XPointerFramework>] together
with any other specifications governing
   the XPointer schemes used in those identifiers that the applications
   support.  Conforming applications MUST support the 'element' scheme
   as defined in [XPointerElement
<https://tools.ietf.org/html/rfc7303#ref-XPointerElement>], but need
not support other schemes.







Registrations which use this '+xml' convention MUST also make
reference to [RFC7303 <http://www.iana.org/go/rfc7303>], specifically
Section 5, in specifying fragment identifier syntax and semantics, and
they MAY restrict the syntax to a specified subset of schemes, except
that they MUST NOT disallow barenames or 'element' scheme pointers.
They MAY further require support for other registered schemes. They
also MAY add additional syntax (which MUST NOT overlap with
[XPointerFramework
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>] syntax)
together with associated semantics, and MAY add additional semantics
for barename XPointers which, as provided for in Section 5, will only
apply when [RFC7303 <http://www.iana.org/go/rfc7303>] does not define
an interpretation.

In practice these constraints imply that for a fragment identifier
addressed to an instance of a specific "xxx/yyy+xml" type, there are
three cases:

For fragment identifiers matching the syntax defined in
[XPointerFramework
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>], where the
fragment identifier resolves per the rules specified there, then
process as specified there;

For fragment identifiers matching the syntax defined in
[XPointerFramework
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>], where the
fragment identifier does _not_ resolve per the rules specified there,
then process as specified in "xxx/yyy+xml";

For fragment identifiers _not_ matching the syntax defined in
[XPointerFramework
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>], then
process as specified in "xxx/ yyy+xml". A fragment identifier of the
form "xywh=160,120,320,240", as defined in [MediaFrags
<http://www.w3.org/TR/2012/REC-media-frags-20120925/>], which might be
used in a URI for an XML-encoded image, would fall in this category.
See Section 10, [RFC7303 <http://www.iana.org/go/rfc7303>].









> I don't have experience dealing with this, and I would not hold back the
> registration on that basis. The Expert Reviewer might.
>
>


Andy