Re: [ietf-types] Registration of media type application/embed+json

[Graham Klyne <[e-mail]>]

On 23/08/2011 00:04, James Snell wrote:
> On Sun, Aug 21, 2011 at 3:38 AM, Graham Klyne<[e-mail]>  wrote:
>> [snip]
>>
>> Hmmm...
>>
>> 1. What is the point?  Why not just use existing MIME type application/json?
>> What, if anything, is the difference?
>>
>
> The key reason is that we'll be passing these around within a
> multipart email, much the same way that multipart messages are used to
> contain both plain text and HTML versions of a message. We need to be
> able to quickly look at the mime part headers and determine if an
> embedded experience document is included as opposed to just some other
> random type of JSON or XML document. We do not want to have to parse
> the JSON first to make that determination.

That makes more sense to me.  It might be worth drawing that out a bit.

>> 2. "This specification" doesn't seem to actually be a specification.  Just a
>> carrier for the registration template.  I cannot find any description of
>> "Embedded experience document" in
>> http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Gadget.xml
>> Appendix C.15 describes many things, but nothing I recognize as a
>> "document".  I can guess at what is intended, but cannot be certain based on
>> the text I'm seeing.
>>
>
> I definitely agree that the spec text in the OpenSocial Core Gadget
> spec is a bit lacking as far as defining the Embedded Experiences
> format as a document per se. If necessary, I can easily add details to
> the I-D that fill in the gaps.

I think what you said above would do it.

>> 3. "This specification" has intended status "informational", but seems to be
>> requesting standards-tree registrations.  Is this right?
>>
>
> Yes and I definitely understand the concern. The main issue is that
> OpenSocial is not a standards track specification originating from an
> IETF WG so Informational status on the I-D seemed to be the most
> appropriate; that said, however, the formats defined are relatively
> simple extensions of the JSON and XML media types and are not vendor
> specific.

>> 4. From the limited descriptions given, this seems to be presented to
>> address specific goals of "opensocial" - as such, wouldn't a vnd.opensocial
>> or similar registration be more appropriate?  This would substantially
>> address my comments 1-3.
>>
>
> I defer to the judgement of this group on that. While OpenSocial.org
> is itself an standalone organization, the OpenSocial specifications
> are not specific to any single vendor and were developed following an
> open, consensus driven process. Further, while currently realized only
> within OpenSocial, it is fully expected that the embedded experience
> format in question will be useful beyond just OpenSocial itself.

I recall reading that "vendor" is intended to be interpreted very broadly, to 
include non-commercial organizations.  I expect that OpenSocial would count in 
that respect.

#g
--