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

[Alexey Melnikov <[e-mail]>]

Hi Amanda,

On 20/04/2024 02:28, Amanda Baber via RT wrote:
> Hi Alexey,
>
> Does this work? The fragment identifier section has been changed to "N/A," and creator Sadayuki Furuhashi has confirmed to us that he's OK with the updated change control section.

I think this is fine to register now.

Best Regards,

Alexey

> thanks,
> Amanda
>
> ===
>
> 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: N/A
>
> 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]>, on behalf of Sadayuki Furuhashi
>
> On Thu Apr 11 11:56:30 2024, [e-mail] wrote:
>> Hi Amanda,
>>
>> On 25/03/2024 19:21, Amanda Baber via RT wrote:
>>> 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"
>> It looks like this is trying to register a structured syntax suffix
>> +msgpack. This requires a separate IANA registration. The process is
>> specified in RFC 6838, Section 6.
>>
>> In order to get this approved, I suggest just removing this and
>> pursuing
>> the structured syntax suffix registration separately.
>>
>>> 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.
>> Is there a community around MessagePack project? If there is, I
>> suggest
>> using an email address for such community in the media type
>> registration
>> request instead.
>>
>> Best Regards,
>>
>> Alexey
>>
>>> ===
>>>
>>> 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