Re: Any protocol buffers MIME types?
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 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 > wrote: > > > > > On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato 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.
Re: Any protocol buffers MIME types?
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 wrote: > On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato 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 -~--~~~~--~~--~--~---
Re: Any protocol buffers MIME types?
On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato 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 -~--~~~~--~~--~--~---
Re: Any protocol buffers MIME types?
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 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. > > On Mon, Mar 9, 2009 at 2:11 PM, Marc Gravell wrote: > > > 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Any protocol buffers MIME types?
On Mon, Mar 09, 2009 at 02:11:54PM -0700, Marc Gravell wrote: > 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? 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Any protocol buffers MIME types?
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. On Mon, Mar 9, 2009 at 2:11 PM, Marc Gravell wrote: > > 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 > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Any protocol buffers MIME types?
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---