Subject: [media-types] Review requested for draft-bormann-cbor-04

From: "John R Levine" <[email-masked]>
Date: 15 Jul 2013 11:20:36 -0400

draft-bormann-cbor-04 describes a new binary structured data format called 
Concise Binary Object Representation (CBOR), and proposes a media type for 
it.  The media type info in the draft is:

7.3.  Media Type ("MIME Type")

    The Internet media type [RFC6838] for CBOR data is application/cbor.

    Type name: application

    Subtype name: cbor

    Required parameters: n/a

    Optional parameters: n/a

    Encoding considerations:  none; CBOR is a binary format

    Security considerations:  Same as for the base document

    Interoperability considerations: n/a

    Published specification: This document

    Applications that use this media type:  None yet, but it is expected
       that this format will be deployed in many protocols and
       applications.

    Additional information:
      Magic number(s): n/a
      File extension(s): .cbor
      Macintosh file type code(s): n/a

    Person & email address to contact for further information:
      Carsten Bormann
      [email-masked]

    Intended usage: COMMON

    Restrictions on usage: none

    Author:
      Carsten Bormann
      [email-masked]

    Change controller:
      Carsten Bormann
      [email-masked]

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 15 Jul 2013 18:09:33 +0200

>    Encoding considerations:  none; CBOR is a binary format

Then it's 'binary', not 'none'.

>    Security considerations:  Same as for the base document

This could use an additional sentence explaining why there is and what
is a "base document" in this context, and why the higher-level format
does not introduce any new security considerations.

>       that this format will be deployed in many protocols and

This should provide more contextual detail than "many". Is there a
particular kind of application that would use it, like backup and
archival software or 3d modeling applications or Office programs?

>    Person & email address to contact for further information:

The typical rendering is more like `Carsten Bormann <[email-masked]>`.

>      [email-masked]

Making Carsten Bormann the change controller requires some rationale,
including where RFC 6838 allows that, especially considering that the
draft-bormann-cbor-04 document appears to be "Standards Track".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: SM <[email-masked]>
Date: Tue, 16 Jul 2013 22:54:21 -0700

>Then it's 'binary', not 'none'.

Yes.

I agree with the points which Bjoern  raised.

>draft-bormann-cbor-04 document appears to be "Standards Track".

As the registration is in the standards tree I suggest IESG as the 
change controller.

Regards,
-sm

---

From: Tony Hansen <[email-masked]>
Date: Wed, 17 Jul 2013 11:03:46 -0400

On 7/15/2013 11:20 AM, John R Levine wrote:
> draft-bormann-cbor-04 describes a new binary structured data format
> called Concise Binary Object Representation (CBOR), and proposes a
> media type for it.  The media type info in the draft is:

An open question in draft-bormann-cbor-04 is:

>    TBD: Maybe add application/mmmmm+cbor for specific protocols?

I think CBOR is worthy of defining a structured syntax suffix. Here is a
candidate addition.

    Tony Hansen

7.4. The +cbor Structured Syntax Suffix Registration

   Name:  Concise Binary Object Representation (CBOR)

   +suffix:  +cbor

   References:  [RFC-THIS-SPEC]

   Encoding considerations: CBOR is a binary format.

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

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

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

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

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

   Security considerations:  See [RFC-THIS-SPEC]

   Contact:  Apps Area Working Group ([email-masked])

   Author/Change controller:
      The Apps Area Working Group.  IESG has change control over this
      registration.

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2013 17:54:44 -0000

>>    TBD: Maybe add application/mmmmm+cbor for specific protocols?

That was a mistake.  The authors tell me they indended to delete it.

R's,
John