Subject: Re: [ietf-types] Registration of media type application/embed+json
From: Graham Klyne <[email-masked]>
To: Mark Baker <[email-masked]>
Cc: ietf-types <[email-masked]>
Date: Mon, 29 Aug 2011 21:28:52 +0100
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On 28/08/2011 21:47, Mark Baker wrote:
> On Wed, Aug 24, 2011 at 5:39 AM, Graham Klyne<[email-masked]>  wrote:
>>>>>> 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.
>>>
>>> I wouldn't think that necessary. New data formats should define their
>>> own media type so that messages remain self-descriptive.
>>
>> Mark,
>>
>> I'm not sure what you're disagreeing with here.  Maybe I was being too
>> terse?  I was just suggesting that the registration document include
>> something akin to the above paragraph to make the purpose and intended use
>> of the new content type clearer.
>
> Graham, yes, I understood that as your point. I was trying to
> communicate that I don't consider it necessary or desirable for a
> registration for a +foo type to mention why */foo isn't sufficient,
> since IMO, the +foo type is always preferred.

Ah, I think I understand.  In terms of the actual specification, I don't 
disagree.  My comment was made in the context of having relevant information to 
review the proposal.

#g
--

Sender: [email-masked]
Date: Sun, 28 Aug 2011 16:47:05 -0400
From: Mark Baker <[email-masked]>
To: Graham Klyne <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

On Wed, Aug 24, 2011 at 5:39 AM, Graham Klyne <[email-masked]> wro=
te:
>>>>> 1. What is the point? =A0Why 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. =A0It might be worth drawing that out a bi=
t.
>>
>> I wouldn't think that necessary. New data formats should define their
>> own media type so that messages remain self-descriptive.
>
> Mark,
>
> I'm not sure what you're disagreeing with here. =A0Maybe I was being too
> terse? =A0I was just suggesting that the registration document include
> something akin to the above paragraph to make the purpose and intended us=
e
> of the new content type clearer.

Graham, yes, I understood that as your point. I was trying to
communicate that I don't consider it necessary or desirable for a
registration for a +foo type to mention why */foo isn't sufficient,
since IMO, the +foo type is always preferred.

Mark.

From: Paul Libbrecht <[email-masked]>
Date: Wed, 24 Aug 2011 13:12:21 +0200
To: James Snell <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

Dare I ask a curiosity question: what kind of interoperability can be =
expected by such a declaration??

- how would an email or www client display this if at all??
- how would a desktop open such a document??

I guess, my concern is the same for the plain application/xml and =
application/json... on all platforms I have seen this offered, one sees =
developer services (or ridiculous bindings such as opening a web-browser =
for a .xml file). I do not think this is the aim of this declaration, =
or?

Maybe identifying the function such a component would have within =
OpenSocial would explain this to me.
Naming two products that are libraries or standards to create other apps =
makes this declaration quite fuzzy to me.=20

My eyes currently only see "that's a binary type, can't do anything with =
it".

paul

Le 20 ao=FBt 2011 =E0 19:10, James Snell a =E9crit :

> For review =
(http://www.ietf.org/internet-drafts/draft-snell-embed-document-01.txt)
>=20
>      Type name:
>        application
>      Subtype name:
>        embed+json
>      Required parameters:
>        None.
>      Optional parameters:
>        None.
>      Encoding considerations:
>        Identical to those of "application/json" as described
>        in [RFC4627], Section 6.
>      Security considerations:
>        As defined in this specification. In addition, as
>        this media type uses the "+json" convention, it
>        shares the same security considerations as described
>        in [RFC4627], Section 6.
>      Interoperability considerations:
>        There are no known interoperability issues.
>      Published specification:
>        This specification.
>      Applications that use this media type:
>        OpenSocial 2.0 (http://opensocial.org)
>        Apache Shindig (http://shindig.apache.org)
>      Additional information:
>        Magic number(s):
>          As specified for "application/json" in [RFC4627],
>          Section 6.
>        File extension(s):
>          .embed
>        Macintosh file type code(s):
>          TEXT
>      Person & email address to contact for further information:
>        James M Snell ([email-masked])
>      Intended usage:
>        COMMON
>      Restrictions on usage:
>        None
>      Author:
>        James M Snell ([email-masked])
>      Change controller:
>        IESG
>=20
> Thank you,
>=20
> - James
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Wed, 24 Aug 2011 10:39:32 +0100
From: Graham Klyne <[email-masked]>
To: Mark Baker <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

On 23/08/2011 22:24, Mark Baker wrote:
> On Tue, Aug 23, 2011 at 5:29 AM, Graham Klyne<[email-masked]>  wrote:
>> On 23/08/2011 00:04, James Snell wrote:
>>>
>>> On Sun, Aug 21, 2011 at 3:38 AM, Graham Klyne<[email-masked]>
>>>   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.
>
> I wouldn't think that necessary. New data formats should define their
> own media type so that messages remain self-descriptive.

Mark,

I'm not sure what you're disagreeing with here.  Maybe I was being too terse?  I 
was just suggesting that the registration document include something akin to the 
above paragraph to make the purpose and intended use of the new content type 
clearer.

#g
--

> In XML-land, some people believed that XML namespaces meant that
> application/xml was all you ever needed for a media type, as the
> namespace URI could be used to identify the specification to be used
> to interpret the meaning of the message. Though RFC 3023 warns against
> such an interpretation, there's no namespace-like grounding mechanism
> in JSON. IMO, that makes 'application/json' a suitable media type if
> and only if you control both ends of the pipe (e.g. an HTML script
> that uses XHR to retrieve JSON from the same origin that delivered the
> HTML).
>
>> 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.
>
> +1
>
> Using the vendor tree would also address another concern I had; that
> "embed" is an extremely generic name that could have many alternate,
> valid meanings in the context of structured data exchange.
>
> Mark.
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
>

Sender: [email-masked]
Date: Tue, 23 Aug 2011 17:24:07 -0400
From: Mark Baker <[email-masked]>
To: Graham Klyne <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

On Tue, Aug 23, 2011 at 5:29 AM, Graham Klyne <[email-masked]> wro=
te:
> On 23/08/2011 00:04, James Snell wrote:
>>
>> On Sun, Aug 21, 2011 at 3:38 AM, Graham Klyne<[email-masked]>
>> =A0wrote:
>>>
>>> [snip]
>>>
>>> Hmmm...
>>>
>>> 1. What is the point? =A0Why 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. =A0It might be worth drawing that out a bit.

I wouldn't think that necessary. New data formats should define their
own media type so that messages remain self-descriptive.

In XML-land, some people believed that XML namespaces meant that
application/xml was all you ever needed for a media type, as the
namespace URI could be used to identify the specification to be used
to interpret the meaning of the message. Though RFC 3023 warns against
such an interpretation, there's no namespace-like grounding mechanism
in JSON. IMO, that makes 'application/json' a suitable media type if
and only if you control both ends of the pipe (e.g. an HTML script
that uses XHR to retrieve JSON from the same origin that delivered the
HTML).

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

+1

Using the vendor tree would also address another concern I had; that
"embed" is an extremely generic name that could have many alternate,
valid meanings in the context of structured data exchange.

Mark.

From: Bjoern Hoehrmann <[email-masked]>
To: James Snell <[email-masked]>
Date: Tue, 23 Aug 2011 17:50:05 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/embed+xml

* James Snell wrote:
>      Applications that use this media type:
>        OpenSocial 2.0 (http://opensocial.org)
>        Apache Shindig (http://shindig.apache.org)

This should identify the class of application like word processors or 3d
modeling tools, not list individual implementations.

>      Additional information:
>        Magic number(s):
>          As specified for "application/xml" in [RFC3023],
>          Section 3.2.

This should say "none beyond" or something to that effect.

>        File extension(s):
>          .embed
>        Macintosh file type code(s):
>          TEXT
>      Person & email address to contact for further information:
>        James M Snell ([email-masked])

The parens should be angle brackets as that format is the most common,
but it does not matter much.
-- 
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/ 

Date: Tue, 23 Aug 2011 10:29:22 +0100
From: Graham Klyne <[email-masked]>
To: James Snell <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

On 23/08/2011 00:04, James Snell wrote:
> On Sun, Aug 21, 2011 at 3:38 AM, Graham Klyne<[email-masked]>  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
--

Date: Mon, 22 Aug 2011 16:04:14 -0700
From: James Snell <[email-masked]>
To: Graham Klyne <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

On Sun, Aug 21, 2011 at 3:38 AM, Graham Klyne <[email-masked]> wro=
te:
> [snip]
>
> Hmmm...
>
> 1. What is the point? =A0Why 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.

> 2. "This specification" doesn't seem to actually be a specification. =A0J=
ust a
> carrier for the registration template. =A0I cannot find any description o=
f
> "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". =A0I can guess at what is intended, but cannot be certain bas=
ed 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.

> 3. "This specification" has intended status "informational", but seems to=
 be
> requesting standards-tree registrations. =A0Is 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.opensoci=
al
> or similar registration be more appropriate? =A0This 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.

- James

> #g
> --
>
>

Date: Sun, 21 Aug 2011 11:38:11 +0100
From: Graham Klyne <[email-masked]>
To: James Snell <[email-masked]>
Cc: ietf-types <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/embed+json

James Snell wrote:
> For review (http://www.ietf.org/internet-drafts/draft-snell-embed-document-01.txt)
> 
>       Type name:
>         application
>       Subtype name:
>         embed+json
>       Required parameters:
>         None.
>       Optional parameters:
>         None.
>       Encoding considerations:
>         Identical to those of "application/json" as described
>         in [RFC4627], Section 6.
>       Security considerations:
>         As defined in this specification. In addition, as
>         this media type uses the "+json" convention, it
>         shares the same security considerations as described
>         in [RFC4627], Section 6.
>       Interoperability considerations:
>         There are no known interoperability issues.
>       Published specification:
>         This specification.
>       Applications that use this media type:
>         OpenSocial 2.0 (http://opensocial.org)
>         Apache Shindig (http://shindig.apache.org)
>       Additional information:
>         Magic number(s):
>           As specified for "application/json" in [RFC4627],
>           Section 6.
>         File extension(s):
>           .embed
>         Macintosh file type code(s):
>           TEXT
>       Person & email address to contact for further information:
>         James M Snell ([email-masked])
>       Intended usage:
>         COMMON
>       Restrictions on usage:
>         None
>       Author:
>         James M Snell ([email-masked])
>       Change controller:
>         IESG
> 
> Thank you,
> 
> - James
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
> 

Hmmm...

1. What is the point?  Why not just use existing MIME type application/json? 
What, if anything, is the difference?

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.

3. "This specification" has intended status "informational", but seems to be 
requesting standards-tree registrations.  Is this right?

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.

#g
--

Date: Sat, 20 Aug 2011 10:10:38 -0700
From: James Snell <[email-masked]>
To: ietf-types <[email-masked]>
Subject: [ietf-types] Registration of media type application/embed+json

For review (http://www.ietf.org/internet-drafts/draft-snell-embed-document-01.txt)

      Type name:
        application
      Subtype name:
        embed+json
      Required parameters:
        None.
      Optional parameters:
        None.
      Encoding considerations:
        Identical to those of "application/json" as described
        in [RFC4627], Section 6.
      Security considerations:
        As defined in this specification. In addition, as
        this media type uses the "+json" convention, it
        shares the same security considerations as described
        in [RFC4627], Section 6.
      Interoperability considerations:
        There are no known interoperability issues.
      Published specification:
        This specification.
      Applications that use this media type:
        OpenSocial 2.0 (http://opensocial.org)
        Apache Shindig (http://shindig.apache.org)
      Additional information:
        Magic number(s):
          As specified for "application/json" in [RFC4627],
          Section 6.
        File extension(s):
          .embed
        Macintosh file type code(s):
          TEXT
      Person & email address to contact for further information:
        James M Snell ([email-masked])
      Intended usage:
        COMMON
      Restrictions on usage:
        None
      Author:
        James M Snell ([email-masked])
      Change controller:
        IESG

Thank you,

- James

Date: Sat, 20 Aug 2011 10:09:29 -0700
From: James Snell <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration of media type application/embed+xml

For review... http://www.ietf.org/internet-drafts/draft-snell-embed-document-01.txt

      Type name: application
      Subtype name: embed+xml
      Required parameters: None.
      Optional parameters:
        "charset": This parameter has smantics identical
          to the charset parameter of the "application/xml"
          media type as specified in [RFC3023].
      Encoding considerations:
        Identical to those of "application/xml" as described
        in [RFC3023], Section 3.2.
      Security considerations:
        As defined in this specification. In addition, as this
        media type uses the "+xml" convention, it shares the
        same security considerations as described in [RFC3023],
        Section 10.
      Interoperability considerations:
        There are no known interoperability issues.
      Published specification:
        This specification.
      Applications that use this media type:
        OpenSocial 2.0 (http://opensocial.org)
        Apache Shindig (http://shindig.apache.org)
      Additional information:
        Magic number(s):
          As specified for "application/xml" in [RFC3023],
          Section 3.2.
        File extension(s):
          .embed
        Macintosh file type code(s):
          TEXT
      Person & email address to contact for further information:
        James M Snell ([email-masked])
      Intended usage:
        COMMON
      Restrictions on usage:
        None
      Author:
        James M Snell ([email-masked])
      Change controller:
        IESG

Thank you...

- James Snell