Re: Any protocol buffers MIME types?

2009-10-18 Thread 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.comwrote:



  On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato maeng...@gmail.comwrote:

  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, 3rdUrban, 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 

Re: Any protocol buffers MIME types?

2009-08-19 Thread 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/

On Mon, Aug 17, 2009 at 10:01 PM, M. David Peterson xmlhac...@gmail.comwrote:

 On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato maeng...@gmail.comwrote:


 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, 3rdUrban, 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?

2009-04-16 Thread 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.

 On Mon, Mar 9, 2009 at 2:11 PM, Marc Gravell marc.grav...@gmail.com 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?

2009-03-09 Thread 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.

On Mon, Mar 9, 2009 at 2:11 PM, Marc Gravell marc.grav...@gmail.com 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
-~--~~~~--~~--~--~---