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
-~----------~----~----~----~------~----~------~--~---

Reply via email to