Any protocol buffers MIME types?

[Marc Gravell]

As part of ongoing work looking at RPC (over a range of transports),
one thing that keeps cropping up is sending messages via a RESTful API
over http[s] (so the method to invoke it part of the URI, with the
message as the body); pretty trivial to do, but I wonder: is there any
common MIME type that anyone has used for such? Or just application/
octet-stream?

Marc Gravell

[Kenton Varda]

We haven't defined a MIME type.

Does it make sense to define a MIME type for protocol buffers in general, as opposed to MIME types for individual protocols?  The latter makes more sense to me, since there's not much you can do with a protocol buffer without knowing its type.

[Pavel Shramov]

I'm using application/x-protobuf in HTTP RPC to know when PB is used (also
application/json is supported for non-pb applications).

If You are interested in python implementation take a look at [1, 2]
Pavel

--
[1] http://grid.pp.ru/wiki/pbufrpc
[2] http://grid.pp.ru/git/?p=psha/pbufrpc/.git

[Michael Abato]

Even if the stream of bytes has no semantic meaning without
the .proto, its "format" is still protobuf binary, so the MIME type
makes some sense even if it is not sufficient.

Putting a ref to the appropriate .proto in the HTTP headers REST-style
seems sensible - loosely similar to declaring a schema or dtd on an
XML file:

http://blog.foemmel.com/2008/07/restful-protocol-buffers.html

Michael Abato

On Mar 9, 5:19 pm, Kenton Varda <ken...@google.com> wrote:
> We haven't defined a MIME type.
> Does it make sense to define a MIME type for protocol buffers in general, as
> opposed to MIME types for individual protocols?  The latter makes more sense
> to me, since there's not much you can do with a protocol buffer without
> knowing its type.
>

[M. David Peterson]

On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato <maen...@gmail.com> wrote:

Even if the stream of bytes has no semantic meaning without
the .proto, its "format" is still protobuf binary, so the MIME type
makes some sense even if it is not sufficient.

Did this discussion ever continue past this single thread?  The only other thread I've noticed that matches on the term mime type doesn't really go into a great depth on the topic, so I can only assume no.  That said, if I'm mistaken and this conversation has long since taken place and a determination made my apologies in advance for reopening a closed discussion.

With the above disclaimer in place, might I make a suggestion to use the widely accepted (and for that matter, recommended) [category]/[type+serializationFormat] format where -- in the case of protocol buffers might look something like application/foo+protobuf where foo represents .proto for a given object? (e.g. application/atom+xml where atom represents the type and xml the serialization format)

 

Putting a ref to the appropriate .proto in the HTTP headers REST-style
seems sensible - loosely similar to declaring a schema or dtd on an
XML file:

From the standpoint of HTTP this makes a lot of sense: You can certainly specify to the .proto of a given type via an X- response header.  But when it comes to anything /other/ than HTTP you're left to your own devices as to how to go about specifying the .proto type which, to me anyway, is just begging for fragmentation issues between transportation protocols. 

Of course, there is one obvious problem with the above and that is the dynamic nature of types compared to the very static, and slow moving process of requesting/registering/receiving an official IANA registered mime-type.  

But this is only a problem if you consider gaining an official IANA mime-type pertinent to the usage of the given mime-type string within your applications.  If this is not something that you see as a barrier for adoption, then the one obvious approach to dealing with things like namespace clashes is to adopt a solution that has worked well for other dynamically driven spaces where name clashes are inevitable, that of using the tld.domain.classpath.type format adopted by the Java community to ensure that my application/foo+protobuf and your application/foo+protobuf can easily co-exist by simply using application/com.mydomain.foo+protobuf and application/com.yourdomain.foo+protobuf

Thoughts/comments/criticism/suggestions? 

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.d...@3rdandUrban.com | m.d...@amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/

[Kenton Varda]

Nope, there hasn't been any off-list discussion.

Personally I have no opinion on the matter since it doesn't affect anything that I do with protocol buffers.  However, the Google Wave people -- who are developing an open-source protocol that will use protocol buffers -- seem to care about this and might be submitting an official registration.  You might talk to them about it.

http://www.waveprotocol.org/

[Max Afonov]

Looking over the [Wave protocol spec][1], it appears that they're
using XMPP which has no entry in the /etc/mime.types on my system, but
does have application/xmpp+xml mentioned in RFC3293. Which leaves us
with absolutely nothing in terms of a MIME type for protocol buffers.

One thing to note is that there's nothing preventing a single
organization from adopting a MIME type for use by only its systems,
especially if the services never see the light of day outside of that
organization. On the other hand, it would be nice to have a commonly
accepted MIME type for the sake of interoperability.

If we're going to be flinging suggestions at the wall to see if
anything would stick, how about something like this:

Content-Type: application/vnd.google.protobuf;
proto=com.example.SomeMessage

The above accomplishes the two important goals: (a) specify that the
message body is serialized using Protocol Buffers; and (b) specify
the .proto package & message used. If, for some reason, the .proto
specification is not important (e.g. the receiving system will just
pass this message along unmolested), the "proto=" parameter is
optional and can be omitted.

What does everyone think?

[1]: http://www.waveprotocol.org/draft-protocol-specs/draft-protocol-spec

On Aug 19, 4:04 pm, Kenton Varda <ken...@google.com> wrote:
> Nope, there hasn't been any off-list discussion.
> Personally I have no opinion on the matter since it doesn't affect anything
> that I do with protocol buffers.  However, the Google Wave people -- who are
> developing an open-source protocol that will use protocol buffers -- seem to
> care about this and might be submitting an official registration.  You might
> talk to them about it.
>
> http://www.waveprotocol.org/
>

> On Mon, Aug 17, 2009 at 10:01 PM, M. David Peterson <xmlhac...@gmail.com>wrote:

> > Email: m.da...@3rdandUrban.com | m.da...@amp.fm