[whatwg] FW: [[IANA #598704] Registration for application/microdata+json media type]

Hixie,

See below the reply from IANA about registration for application/microdata+json.

I'll make the simple "n/a" changes when I re-submit it. But see in
particular the suggestion about security.

  --Mike

----- Forwarded message from Amanda Baber via RT <iana-mime@iana.org> -----

Subject: [IANA #598704] Registration for application/microdata+json media type
From: Amanda Baber via RT <iana-mime@iana.org>
To: mike@w3.org
Date: Tue, 18 Sep 2012 18:29:33 +0000

Hi Michael,

The IESG-designated expert has reviewed your application and returned 
the inline comments below. Please reply to this email within 30 days 
(i.e. by October 17) with a revised application. 

If you have any questions, please don't hesitate to contact us.

Best regards,

Amanda Baber
ICANN/IANA

===

> Type name:
> application

> Subtype name:
> microdata+json

> Required parameters:
> Same as for application/json [JSON]

> Optional parameters:
> Same as for application/json [JSON]

Application/json does not define any parameters. As such, this is an
unnecessary reference that forces readers to check something and find
nothing. 

Moreover, in the highly unlikely event that parameters were to be added
to application/json in the future, it would be extremely unwise for
existing registrations to inherit them willy-nilly.

Both of these need to be changed to: n/a.

> Encoding considerations:
> 8bit (always UTF-8)

> Security considerations:
> Same as for application/json [JSON]

If my understanding is correct, like JSON in general, microdata content
is essentially arbitrary. The point of having a microdata specification
is to have a consistent means of embedding stuff in HTML5, not to define
what that stuff is.

Given this, and had the security considerations for application/json
been done properly, this might, and I emphasize might, have been
sufficient to just reference the application/json security considerations.

But the security considerations for application/json fail to address the
issues associated with being able to represent arbitrary content. As
such, they need to be addressed here. At a minimum the possibility of
active or executable content as well as privacy and integrity need to be
addressed. I suggest something like:

  The security considerations associated with the JSON format [JSON]
apply to
  this media type. The content of this media type can include active or
  executable content. The content may also be sensitive, so privacy and
  integrity services may need to be used to protect the content in some
  instances.


> Interoperability considerations:
> Same as for application/json [JSON]

This is again a reference to nothing. It needs to change to: n/a

> Published specification:

> Labeling a resource with the application/microdata+json type asserts that
> the resource is a JSON text that consists of an object with a single entry
> called "items" consisting of an array of entries, each of which
consists of
> an object with an entry called "id" whose value is a string, an entry
> called "type" whose value is another string, and an entry called
> "properties" whose value is an object whose entries each have a value
> consisting of an array of either objects or strings, the objects being of
> the same form as the objects in the aforementioned "items" entry.
Thus, the
> relevant specifications are the JSON specification and the HTML Microdata
> specification.

> http://www.w3.org/TR/microdata/#application-microdata-json

This is a hard one to get right. Referencing the media type declaration
is circular and therefore somewhat pointless, but referencing the entire
microdata specification seems wrong somehow. My suggestion would be to
reference section 5.1:

   http://www.w3.org/TR/microdata/#json

But if you want to reference the entire specification that's also OK:

   http://www.w3.org/TR/microdata
 
> Applications that use this media type:
> Same as for application/json [JSON]

It's fine not to list specific applications and therefore leave this
blank, but this is effectively asserting that every application that
uses JSON also uses microdata, which is rather obviously incorrect.

> Additional information:
> Magic number(s):
> Same as for application/json [JSON]

Change to: n/a

> File extension(s):
> Same as for application/json [JSON]

Change to: .json

> Macintosh file type code(s):
> Same as for application/json [JSON]

Change to: n/a

> Person & email address to contact for further information:
> Michael[tm] Smith <mike@w3.org>

> Intended usage:
> Common

> Restrictions on usage:
> No restrictions apply.

> Author:
> Ian Hickson <ian@hixie.ch>

> Change controller:
> W3C

> Fragment identifiers used with application/microdata+json resources have
> the same semantics as when used with application/json (namely, at the time
> of writing, no semantics at all). [JSON]

I have to wonder if this is a good idea, but it's acceptable from
a registration standpoint.

----- End forwarded message -----

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Wednesday, 3 October 2012 16:44:42 UTC