Eric Prud'hommeaux | 29 Jun 09:18 2016
Picon

Resend: request for review: application/sparql-results+json

I didn't see this come through, possibly because I sent it
To:ietf-types <at> alvestrand.no

Hi all, at W3C, we try to request a media type when a document reaches
candidate recommendation. In this case, we missed my a mere three years.
<http://www.w3.org/TR/sparql11-results-json/#content-type> accurately
documents our good intentions...

Type name:
    application
Subtype name:
    sparql-results+json
Required parameters:
    None
Optional parameters:
    None
Encoding considerations:
    The encoding considerations of the SPARQL Query Results JSON Format is identical to those of the
"application/json" as specified in [JSON-RFC].
Security considerations:
    SPARQL query results uses URIs. See Section 7 of [RFC3986].
    SPARQL query results uses IRIs. See Section 8 of [RFC3987].
    The security considerations of the SPARQL Query Results JSON Format is identical to those of the
"application/json" as specified in [JSON-RFC].
Interoperability considerations:
    There are no known interoperability issues.
Published specification:
    http://www.w3.org/TR/sparql11-results-json/
Applications which use this media type:
    No known applications currently use this media type.
(Continue reading)

Sean Leonard | 29 Jun 05:24 2016

Filling out templates in XML

Just curious if people have thought about using XML elements to fill out 
templates, in xml2rfc, rather than sticking the template instance in an 
artwork blob.

Consider <draft-ietf-netconf-restconf-14.xml> (which I just reviewed). 
In #media-types, the RFC 6838 templates are instantiated as artwork. 
Wouldn't it be better to put the things in some basic XML blocks? I have 
seen very long registration templates elsewhere, like URNs and URIs, 
that can spill over to multiple pages. It would be helpful if these 
could be treated (at least in part) as regular runs of text so that they 
are subject to page breaking automatically, etc.

There is a temptation to over-specify the details of every registration 
template. Perhaps a quick survey could be done, to see some common 
IETF/IANA registration templates, and if there is enough common to them 
to permit a small handful of elements. 6 elements or less, I would say. 
For example:

<instance schema="RFC6838">
   <field name="Type name">application</field>
   <field name="Subtype name">yang-data+xml</field>
   <field name="Required parameters">none</field>
   ...
   <field name="Security considerations"><t>Security considerations related
       to the generation and consumption of RESTCONF messages
       are discussed in Section NN of <xref target="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.</t>
(Continue reading)

Andy Bierman | 29 Jun 04:29 2016
Gravatar

request review of media type application/yang-patch+xml

Hi,

Please review and provide feedback on the media type registration
for  YANG Patch media type for the PATCH method.  This is used by
the RESTCONF protocol.




thanks,
Andy

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Andy Bierman | 29 Jun 04:27 2016
Gravatar

request review of media type application/yang-data+json

Hi,

Please review and provide feedback on the revised media type registration
for the RESTCONF protocol.




thanks,
Andy

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Andy Bierman | 29 Jun 04:24 2016
Gravatar

request review of media type application/yang-data+xml

Hi,

Please review and provide feedback on the revised media type registration
for the RESTCONF protocol.




thanks,
Andy


_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
media-types | 27 Jun 16:47 2016
Picon

DOC8546609361

Attachment (DOC8546609361.zip): application/x-zip, 4449 bytes
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Andy Bierman | 21 Jun 16:31 2016
Gravatar

Re: [Netconf] RESTCONF media type issue

Hi,

I forgot to CC: the media-types list ask Benoit asked.
Maybe they have an opinion on removing the operation media type.



Andy


On Tue, Jun 21, 2016 at 6:08 AM, Ladislav Lhotka <lhotka <at> nic.cz> wrote:

> On 21 Jun 2016, at 14:56, Andy Bierman <andy <at> yumaworks.com> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 5:49 AM, Ladislav Lhotka <lhotka <at> nic.cz> wrote:
>
> > On 21 Jun 2016, at 14:32, Andy Bierman <andy <at> yumaworks.com> wrote:
> >
> >
> >
> > On Tue, Jun 21, 2016 at 5:23 AM, Ladislav Lhotka <lhotka <at> nic.cz> wrote:
> >
> > > On 21 Jun 2016, at 14:16, Andy Bierman <andy <at> yumaworks.com> wrote:
> > >
> > >
> > >
> > > On Tue, Jun 21, 2016 at 12:39 AM, Ladislav Lhotka <lhotka <at> nic.cz> wrote:
> > >
> > > > On 21 Jun 2016, at 02:11, Andy Bierman <andy <at> yumaworks.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The media type definitions in RESTCONF-13 are incorrect.
> > > > We cannot make subtypes for application/yang.
> > > > Each RESTCONF (and YANG Patch) media type has
> > > > to be registered.
> > > >
> > > >
> > > > Approach 1) hard-wired types
> > > >
> > > >
> > > > RESTCONF would register 10 media types and YANG Patch 4 media types
> > > > if we use the hardwired approach.
> > > >
> > > >    application/yang-api+xml
> > > >    application/yang-api+json
> > > >    application/yang-datastore+xml
> > > >    application/yang-datastore+json
> > > >    application/yang-data+xml
> > > >    application/yang-data+json
> > > >    application/yang-errors+xml
> > > >    application/yang-errors+json
> > > >    application/yang-operation+xml
> > > >    application/yang-operations+json
> > > >    application/yang-patch+xml
> > > >    application/yang-patch+json
> > > >    application/yang-patch-status+xml
> > > >    application/yang-patch-status+json
> > > >
> > > > Any new media types would need to be registered.
> > > > No usage of the restconf-media-type is possible besides
> > > > this list of media types for RESTCONF and YANG Patch
> > > > without additional registrations.
> > > >
> > > > Approach 2) generic types with a parameter
> > > >
> > > > A parameter approach would allow YANG to be used to define any
> > > > message content schema.  E.g., a mandatory "type" parameter
> > > > that specifies the module and name of the restconf-media-type.
> > > >
> > > > Only 2 media type need to be registered for every media-type
> > > > that could ever be specified (SDO or vendor)
> > > >
> > > >    application/yang-data-xml;type=<module>:<name>
> > > >    application/yang-data-json;type=<module>:<name>
> > > >
> > > >    application/yang-data-xml;type=ietf-restconf:api
> > > >    application/yang-data-json;type=ietf-restconf:api
> > > >    application/yang-data-xml;type=ietf-restconf:datastore
> > > >    application/yang-data-json;type=ietf-restconf:datastore
> > > >    application/yang-data-xml;type=ietf-restconf:data
> > > >    application/yang-data-json;type=ietf-restconf:data
> > > >    application/yang-data-xml;type=ietf-restconf:errors
> > > >    application/yang-data-json;type=ietf-restconf:errors
> > > >    application/yang-data-xml;type=ietf-restconf:operation
> > > >    application/yang-data-json;type=ietf-restconf:operation
> > > >    application/yang-data-xml;type=ietf-yang-patch:yang-patch
> > > >    application/yang-data-json;type=ietf-yang-patch:yang-patch
> > > >    application/yang-data-xml;type=ietf-yang-patch:yang-patch-status
> > > >    application/yang-data-json;type=ietf-yang-patch:yang-patch-status
> > > >
> > > >
> > > > If you have a preference how this issue is resolved, send comments.
> > >
> > > I prefer #1, as media types aren't supposed to carry schema information (and we do have it elsewhere). One thing to consider though is to reduce the number of media types. For example, it's IMO not necessary to have separate media types "application/yang-data" and "application/yang-operation" because they can be easily discriminated via the URI.
> > >
> > >
> > >
> > > I think #1 is simpler to implement.
> > > I don't agree we should make operation and data resources the same media type.
> > > It is useful in implementation to tell POST data from POST operation before parsing
> > > the message-body.
> >
> > Parsing and resolving the RequestURI should be sufficient to tell them apart, no?
> >
> >
> > no...
> >
> >
> > container foo {
> >    container input {
> >       leaf X { type string; }
> >    }
> >    action bar {
> >       input {
> >          leaf X { type string; }
> >       }
> >     }
> >  }
> >
> >
> > POST /restconf/data/foo
> >
> > { "input" : {
> >      "X" : "so is this an invocation of action bar or a creation of container input?"
> >    }
> > }
>
> Shouldn't the action be invoked with
>
> POST /restconf/data/foo/bar
>
>
>
> yes -- the URIs will be different.
>
> I don't see what problem it solves to change it now.
> Either we think RESTCONF-specific media types help or they should all be removed.
>
> To take this argument to the logical conclusion, we could dump all the media types
> and just use application/xml and application/json.
>
> In fact, we support that in our server, proving the RESTCONF media types can be ignored
> because there is enough context in the request to deduce the schema.
>
> I think the media types add some strong typing.
> Not sure if that is important or not.

The granularity of media types seems to be a controversial topic (feed Google with "media type explosion").
I'd suggest to consult APPS folks.

Lada

>
>
> Andy
>
> Section 3.6 says
>
>    An action is invoked as:
>
>    POST {+restconf}/data/<data-resource-identifier>/<action>
>
>
> >
> >
> > What problem are you solving by combining them?
>
> Media types should not be multiplied unnecessarily.
>
> Lada
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Lada
> > >
> > > >
> > > >
> > >
> > >
> > > Andy
> > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf <at> ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sean Leonard | 19 Jun 00:48 2016

Is dot (.) basically reserved?

Is it fair to say that the dot (.) is basically a reserved character as a delimiter for facet names in media
types, but does that mean it can’t ever be used?

Suppose that I want to register a media type for X.690-encoded values (commonly known as BER, CER, DER) as a
whole. (I am not actually going to do this, at least not for the time being. Working on other things...)

application/x.690 makes sense. (application/ber etc. do not make sense, because BER / CER / DER are
basically the same. Similarly application/asn.1 does not make sense because this is an encoding of
ASN.1, it’s not generic to ASN.1 as a whole.)

However, x. is reserved specifically according to Section 3.4. There is also Section 4.2.

What about application/itu.x.690 ? (Or application/itu-t.x.690?) Basically this would call for
registering “itu” (or “itu-t”) as a facet, which requires Standards Action. Would subsequent
dots then be allowed?

Thanks,

Sean
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Philippe Le Hegaret | 16 Jun 16:16 2016
Picon
Gravatar

Update to media type "application/ttml+xml"

The W3C Timed Text Working Group would like to update the media type 
"application/ttml+xml" as follows. Comments are welcome.

It updates the media type, "application/ttml+xml" to add a new 
parameter, codecs. All other provisions of the media type specification 
remain the same. This supercedes the initial registration information in 
TTML 1.0 Second Edition.

Text copied below but see also the original text at:
  https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype

[[

Type name:

     application
Subtype name:

     ttml+xml
Required parameters:

     None.
Optional parameters:

     charset

         If specified, the charset parameter must match the XML encoding 
declaration, or if absent, the actual encoding. See also Encoding 
Considerations below.
     profile

         The document profile of a TTMLDocument Instance may be 
specified using an optional profile parameter, which, if specified, the 
value of which must adhere to the syntax and semantics of ttp:profile 
parameter defined by TTML 1.0 Second Edition, Section 6.2.8 ttp:profile 
of the published specification.

     codecs

         The optional codecs parameter provides a short form version of 
the profile parameter with multiple-profile combinatorial capability. If 
a short (4-character) form of a profile is registered in the TTML 
Profile Registry, it is recommended that this codecs parameter be used 
and not the profile parameter. The nominal value of this parameter is a 
single 4 character code from the registry.

         Additionally, applications using the entries in the registry 
are encouraged to adopt the following combination syntax:

         Employ two combination operators, '+' (AND) and '|' (OR), which 
may be used to specify, respectively, that multiple processor profiles 
apply (simultaneously) or that any processor profile of a list of 
profiles may apply individually. If both operators are used in a codecs 
value, then the '+' operator has precedence.

         The example: "A+B|C+D|E" states that a TTML processor that 
implements any one of A+B or C+D or E processor profiles satisfies, at 
first order, the requirements to fetch and begin decode/processing of a 
TTML document, where X+Y means that both X and Y processor profiles must 
be supported, and X|Y means that either X or Y processor profile must be 
supported.

         For more information about processor profile combination, see 
TTML2 Profile Combination.

Encoding considerations:

     Same for application/xml, except constrained to either UTF-8 or 
UTF-16. See IETF RFC 3023, XML Media Types, Section 3.2. For the purpose 
of filling out the IANA Application for Media Type 
(http://www.iana.org/cgi-bin/mediatypes.pl), the value binary applies.
Security considerations:

     As with other XML types and as noted in IETF RFC 3023, XML Media 
Types, Section 10, repeated expansion of maliciously constructed XML 
entities can be used to consume large amounts of memory, which may cause 
XML processors in constrained environments to fail.

     In addition, because of the extensibility features for TTML and of 
XML in general, it is possible that "application/ttml+xml" may describe 
content that has security implications beyond those described here. 
However, TTML does not provide for any sort of active or executable 
content, and if the processor follows only the normative semantics of 
the published specification, this content will be outside TTML 
namespaces and may be ignored. Only in the case where the processor 
recognizes and processes the additional content, or where further 
processing of that content is dispatched to other processors, would 
security issues potentially arise. And in that case, they would fall 
outside the domain of this registration document.

     Although not prohibited, there are no expectations that XML 
signatures or encryption would normally be employed.
Interoperability considerations:

     The published specification describes processing semantics that 
dictate behavior that must be followed when dealing with, among other 
things, unrecognized elements and attributes, both in TTML namespaces 
and in other namespaces.

     Because TTML is extensible, conformant "application/ttml+xml" 
processors may expect (and enforce) that content received is well-formed 
XML, but it cannot be guaranteed that the content is valid to a 
particular DTD or Schema or that the processor will recognize all of the 
elements and attributes in the document.
Published specification:

     This media type registration is extracted from the TTML Profile 
Registry.
Applications that use this media type:

     TTML is used in the television industry for the purpose of 
authoring, transcoding and exchanging timed text information and for 
delivering captions, subtitles, and other metadata for television 
material repurposed for the Web or, more generally, the Internet.

     There is partial and full support of TTML in components used by 
several Web browsers plugins, and in a number of caption authoring tools.
Additional information:

     Magic number(s):
     File extension(s):

         .ttml
     Macintosh file type code(s):

         "TTML"
     Fragment identifiers:

         For documents labeled as application/ttml+xml, the fragment 
identifier notation is intended to be used with xml:id attributes, as 
described in section 7.2.1 of the Timed Text Markup Language 1 (TTML1) 
specification.

Person & email address to contact for further information:

     Timed Text Working Group (public-tt <at> w3.org)
Intended usage:

     COMMON
Restrictions on usage:

     None
Author:

     The published specification is a work product of the World Wide Web 
Consortium's Timed Text (TT) Working Group.
Change controller:

     The W3C has change control over this specification.
]]
https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20160510/#mediatype

Thank you,

Philippe
Mark Nottingham | 10 Jun 01:45 2016
Picon
Gravatar

Subtypes and registration trees

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/
Sean Leonard | 9 Jun 17:31 2016

The styling of media types in IETF specifications

  During the publication of draft-seantek-windows-image-03 (soon to be 
RFC 7903), the RFC Editor questioned:

> 2) We note that the names of the media types being registered
> sometimes appear without quotation marks (e.g., image/x-wmf) and a
> couple of times appear enclosed in double quotation marks (e.g.,
> "image/x-wmf"). Should the usage be consistent?

I checked RFC 6838, and RFC 6838 is itself inconsistent between quoting 
and unquoting media types.

How shall media types in IETF specifications be stylized in plain text, 
and in xml2rfc? Specifically: shall they be quoted "application/pdf", or 
unquoted application/pdf? In xml2rfc, shall they be quoted or unquoted, 
shall the quotes be curly quotes or straight quotes, and shall the text 
be in <tt> elements or plain?

My 2¢:

When referring to the media type as a string in a protocol element, in 
plain text "application/pdf" is correct (possibly with other elements, 
e.g., "text/plain; charset=ISO-8859-1". In xml2rfc, the same situations 
should be covered by <tt>application/pdf</tt> (no quotes).

When referring to the media type as a prose statement of the contents or 
using the media type for its semantics, do not use quotes and do not 
encase in <tt>. Examples:

   An application that renders application/pdf data needs to put it in a 
window with scroll bars.

   When a generator generates text/html, it SHOULD balance the tags.

Basically the use of the media type can be substituted by a prose and 
possibly more unwieldy description, such as:

   An application that renders PDFs needs to put it in a window with 
scroll bars.

   When a generator generates HTML documents, it SHOULD balance the tags.

Thank you,

Sean

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types

Gmane