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: > > > > > On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato <maeng...@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.da...@3rdandurban.com | m.da...@amp.fm > > Mobile: (206) 999-0588 > >http://3rdandUrban.com|http://amp.fm| > >http://broadcast.oreilly.com/m-david-peterson/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
