Re: [media-types] Review request for structured syntax suffix registration: rar

[" Martin J. Dürst " <[e-mail]>]

On 2016/09/13 05:45, Kim Scarborough wrote:
> So, uh... what do I need to do next on this?

Well, just read the RFC and follow the steps there. To be specific, that 
would be at
https://tools.ietf.org/html/rfc6838#section-6
where you are probably now around step 4, and may want to move forward 
to step 5.

Regards,   Martin.


> On 07/17/2016 05:51 PM, Kim Scarborough wrote:
>> Sure. If this goes through, I'm planning on registering
>> application/vnd.comicbook+rar, which would apply to .CBR files and would
>> compliment application/vnd.comicbook+zip. RAR has better multimedia
>> compression than comparable formats, so one could register something
>> like video/mpeg+rar or audio/vnd.wave+rar (assuming audio/vnd.wave gets
>> registered).
>>
>>
>> On 07/17/2016 01:25 AM, Martin J. Dürst wrote:
>>> On 2016/07/15 09:09, Kim Scarborough wrote:
>>>> Hello folks,
>>>
>>> For a structured suffix, these should be a few (at least potential)
>>> actual media types that would use it. Can you give (at least potential)
>>> examples?
>>>
>>> Regards,   Martin.
>>>
>>>
>>>> This is a review request for a Registration Request for Structured
>>>> Syntax Suffix "rar".
>>>>
>>>> Name: RAR compression and archive format
>>>>
>>>> +suffix: rar
>>>>
>>>> References: “RAR 5.0 archive format", <http://www.rarlab.com/technote.htm>
>>>>
>>>> Encoding considerations: RAR is a binary format.
>>>>
>>>> Interoperability considerations: As this is not an open standard,
>>>> interoperability is left up to the discretion of the developer.
>>>>
>>>> Fragment identifier considerations: The syntax and semantics of fragment
>>>> identifiers specified for rar SHOULD be as specified for
>>>> "application/vnd.rar". (At publication of this document, there is no
>>>> fragment identification syntax defined for "application/vnd.rar".)
>>>>
>>>> The syntax and semantics for fragment identifiers for a specific
>>>> "xxx/yyy+rar" SHOULD be processed as follows:
>>>>
>>>> For cases defined in +rar, where the fragment identifier resolves per
>>>> the +rar rules, then process as specified in +rar.
>>>>
>>>> For cases defined in +rar, where the fragment identifier does not
>>>> resolve per the +rar rules, then process as specified in "xxx/yyy+rar".
>>>>
>>>> For cases not defined in +rar, then process as specified in "xxx/yyy+rar".
>>>>
>>>> Security considerations:
>>>> The security issues associated with this type have not been
>>>> assessed.
>>>>
>>>> Contact:
>>>> Kim Scarborough
>>>> <[e-mail]>
>>>>
>>>> Author/Change controller:
>>>> win.rar GmbH
>>>> Marienstrasse 12
>>>> 10117 Berlin
>>>> Germany HRB 109885 B Amtsgericht Charlottenburg
>>>> Ust-ID Nr. DE255974207
>>>>
>>>> _______________________________________________
>>>> media-types mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/media-types
>>>>
>>
>> _______________________________________________
>> media-types mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/media-types
>>
> .
>

-- 
Martin J. Dürst
Department of Intelligent Information Technology
Collegue of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan