[media-types] [IANA #1360120] application/vnd.msgpack registration request

[Amanda Baber via RT <[e-mail]>]

Hi Alexey,

We have fragment identifier and change author/change controller responses from the applicant:

===

1) Fragment identifier +msgpack is considered to be used with other
media types to define encoding like +json does (unless specified
otherwise). So "Fragment identifier considerations" section could be
something like this:

The syntax and semantics of fragment identifiers specified for +msgpack
should be as specified for "application/vnd.msgpack"

2) I'm a contributor of MessagePack project, who wanted to resolve the
issue of widespread use of deprecated media types. As the original
MessagePack specification author Sadayuki Furuhashi is inactive for a
while, I don't want to bother him by publishing his contacts. I would
like to include them without that if it's appropriate.

===

thanks,
Amanda

On Sun Mar 17 01:42:29 2024, [e-mail] wrote:
> Hi Amanda,
> 
> Sorry for the slow response.
> 
> This is mostly fine, but I have a small question and a bigger concern
> expressed below.
> 
> 
> On 01/03/2024 18:14, Amanda Baber via RT wrote:
> 
> > Hi Alexey,
> 
> > Can you review this registration request by March 15th?
> 
> > This was originally submitted as a request for standards-tree
> > registration, but the submitter isn't affiliated with a standards
> > organization and has yet to write an I-D.
> 
> > He writes, "I would like to edit the registration template to make it
> > a vendor-tree ('application/vnd.msgpack') registration request, as
> > writing RFC would take some considerable time (but pretty much aim to
> > do that anyway)."
> 
> > thanks,
> > Amanda
> 
> > ===
> 
> > Name: Alexander Ivanov
> 
> > Email: [e-mail]
> 
> > Media type name: application
> 
> > Media subtype name: vnd.msgpack
> 
> > Required parameters: N/A.
> 
> > Optional parameters: N/A.
> 
> > Encoding considerations: binary
> 
> > Security considerations: This media type does not enforce a security
> > mechanism, as it does not contain any executable content. The format
> > specification does not provide any encryption or integrity checks, so
> > appropriate mechanisms must be implemented at the application or
> > transport level. The format allows applications to define
> > application-specific types, so security considerations of such
> > extensions cannot be assessed.
> 
> > Interoperability considerations: The specification explicitly defines
> > a way to encode information (relying on standards such as IEEE 754),
> > as well as limitations to allow conversion to and from other
> > encodings (such as JSON). This provides interoperability not just
> > between implementations, applications and hardware, but media types
> > as well.
> 
> > Published specification:
> > https://github.com/msgpack/msgpack/blob/master/spec.md
> > https://msgpack.org/
> 
> > Applications which use this media: MessagePack has been used to
> > exchange arbitrary data between applications written in various
> > programming languages and environments, replacing existing media
> > types such as JSON.
> 
> > Fragment identifier considerations: +msgpack
> 
> I am not clear on what this means.
> 
> > Restrictions on usage: N/A.
> 
> > Provisional registration? (standards tree only): No
> 
> > Additional information:
> 
> > 1. Deprecated alias names for this type: application/x+msgpack
> > 2. Magic number(s): N/A.
> > 3. File extension(s): N/A.
> > 4. Macintosh file type code: N/A.
> > 5. Object Identifiers: N/A.
> 
> > General Comments:
> 
> > Person to contact for further information:
> 
> > 1. Name: Alexander Ivanov
> > 2. Email: [e-mail]
> 
> > Intended usage: COMMON
> 
> > Author/Change controller: Alexander Ivanov
> > <[e-mail]>
> 
> It is not clear to me how Alexander is related to the project, as the
> original
> creator of MessagePack is a different person. Can you please ask?
> 
> Thank you,
> Alexey