Jaime Jiménez | 19 Jul 12:46 2016
Picon

Media type review of draft-ietf-core-http-mapping

Hi,

I would like to get a review of the media type template on section 9.2 of draft-ietf-core-http-mapping


----------- 8< -----------


9.2.  New 'coap-payload' Internet Media Type


   This document defines the "application/coap-payload" media type with
   a single parameter "cf".  This media type represents any payload that
   a CoAP message can carry, having a content format that can be
   identified by a CoAP Content-Format parameter (an integer in range
   0-65535).  The parameter "cf" is the integer defining the CoAP
   content format.

   Type name: application

   Subtype name: coap-payload

   Required parameters:

   cf - CoAP Content-Format integer in range 0-65535 denoting the
   content format of the CoAP payload carried.

   Optional parameters: None

   Encoding considerations:

   The specific CoAP content format encoding considerations for the
   selected Content-Format (cf parameter) apply.

   Security considerations:

   The specific CoAP content format security considerations for the
   selected Content-Format (cf parameter) apply.

   Interoperability considerations:

   Published specification: (this I-D - TBD)

   Applications that use this media type:

   HTTP-to-CoAP Proxies.

   Fragment identifier considerations: N/A

   Additional information:

      Deprecated alias names for this type: N/A

      Magic number(s): N/A

      File extension(s): N/A

      Macintosh file type code(s): N/A

   Person and email address to contact for further information:

      Esko Dijk ("esko <at> ieee.org")

   Intended usage: COMMON

   Restrictions on usage:

   An application (or user) can only use this media type if it has to
   represent a CoAP payload of which the specified CoAP Content-Format
   is an unrecognized number; such that a proper translation directly to
   the equivalent HTTP media type is not possible.

   Author: CoRE WG

   Change controller: IETF

   Provisional registration? (standards tree only): N/A



- - Jaime Jimenez

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Kim Scarborough | 15 Jul 02:09 2016
Picon

Review request for structured syntax suffix registration: rar

Hello folks,

This is a review request for a Registration Request for Structured
Syntax Suffix "rar".

Name: RAR compression and archive format

+suffix: rar

References: “RAR 5.0 archive format", <http://www.rarlab.com/technote.htm>

Encoding considerations: RAR is a binary format.

Interoperability considerations: As this is not an open standard,
interoperability is left up to the discretion of the developer.

Fragment identifier considerations: The syntax and semantics of fragment
identifiers specified for rar SHOULD be as specified for
"application/vnd.rar". (At publication of this document, there is no
fragment identification syntax defined for "application/vnd.rar".)

The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+rar" SHOULD be processed as follows:

For cases defined in +rar, where the fragment identifier resolves per
the +rar rules, then process as specified in +rar.

For cases defined in +rar, where the fragment identifier does not
resolve per the +rar rules, then process as specified in "xxx/yyy+rar".

For cases not defined in +rar, then process as specified in "xxx/yyy+rar".

Security considerations:
The security issues associated with this type have not been
assessed.

Contact:
Kim Scarborough
<user <at> unknown.nu>

Author/Change controller:
win.rar GmbH
Marienstrasse 12
10117 Berlin
Germany HRB 109885 B Amtsgericht Charlottenburg
Ust-ID Nr. DE255974207

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Andy Bierman | 9 Jul 01:10 2016
Gravatar

review request for media type application/yang-patch+json

Hi,

Here is the revised application/yang-patch+json media type registration request


Type name: application
Subtype name: yang-patch+json Required parameters: None Optional parameters: None // RFC Ed.: replace draft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace draft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // 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 [draft-ietf-netmod-yang-json]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata] 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 syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .json 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

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Andy Bierman | 9 Jul 01:10 2016
Gravatar

review request for media type application/yang-patch

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

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Andy Bierman | 9 Jul 01:10 2016
Gravatar

review request for media type application/yang-data

Hi,

Here is the revised application/yang-data media type registration request
(was application/yang-data+xml)
Type name: application Subtype name: yang-data 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. 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]. // 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 YANG defined data structures. 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

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
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.
Additional information:
Magic number(s):
    n/a
File extension(s):
    ".srj"
Macintosh file type code(s):
    "TEXT"
Person & email address to contact for further information:
    Andy Seaborne <public-rdf-dawg-comments <at> w3.org>
Intended usage:
    COMMON
Restrictions on usage:
    None
Author/Change controller:
    The SPARQL specification is a work product of the World Wide Web Consortium's SPARQL Working Group. The W3C
has change control over these specifications.

--

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric <at> w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
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>

   <additional>blah blah blah at end of instance</additional>
</instance>

That yields 3 elements: instance, field, and additional.

An alternate approach is to have some XML namespace/schema and embed it 
in a <figure>, similar to <svg> (in <artwork>) and <sourcecode>. Could 
get needlessly complex, but would limit arbitrary placement. Depends on 
whether one feels that registration templates need to be in <figure> 
elements or not. I believe that template instances can be part of the 
main specification text (first, because template instances can contain 
normative specification language; second, because it's possible that 
template fields might have figures inside); therefore, they should not 
be required to be in <figure> elements.

Just my 2¢.

Sean

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
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

Gmane