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 firstname.lastname@example.org 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 -~----------~----~----~----~------~----~------~--~---