Consider registering media type (mime type) for 3dm files/blobs

[pearswj]

Based on a question from ShapeDiver on the forum...

http://tools.ietf.org/html/rfc2045#section-5

The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.

HISTORICAL NOTE: The Content-Type header field was first defined in RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one that is largely compatible with the mechanism given here.

The Content-Type header field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation. The ordering of parameters is not significant.

I suggest either model/3dm or model/vnd.3dm based on a quick review of the information. My understanding is that the vnd prefix is suitable for commercial/proprietary types. The 3dm file format is proprietary, but the tools for reading and writing it are open source. I've used model/vnd.3dm in the examples below.

A couple of examples, based on my understanding of why this is useful...

1. The client calls the server's /export endpoint with the Accept header set to model/vnd.3dm. The server responds by exporting a saved model as a 3dm file and returning the binary data in the response body. The server could also support model/stl and model/obj.
2. The client calls the server's /convert endpoint with a Content-Type: model/stl and Accept: model/vnd.3dm and the contents of a binary STL file in the request body. The server returns a 3dm file in the response body that contains a mesh that was created from the STL file.

I'm unsure if there should be special considerations for sending and receiving 3dm blobs (i.e. the serialised opennurbs geometry data that compute deals with). Perhaps for this we should use model/vnd.3dm+json, as per RFC 3023.

We may need to register something, at some point. For now I'm just taking notes!

References

• Up-to-date list of media types maintained by IANA
• RFC 2045 - MIME formats and encodings
• RFC 2077 - Model top-level media type
• RFC 6838 - Media type specifications and registration procedures
• Registration application

Examples

• model/stl
• model/obj
• model/gltf+json
• model/gltf+binary

[mcneel-build]

Linked with COMPUTE-131