- From: Michael[tm] Smith <mike@w3.org>
- Date: Thu, 4 Oct 2012 01:39:00 +0900
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@lists.whatwg.org
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