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

From: Kim Scarborough <[email-masked]>
Date: Mon, 12 Sep 2016 15:45:55 -0500

So, uh... what do I need to do next on this?

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
>> > <[email-masked]>
>> >
>> > Author/Change controller:
>> > win.rar GmbH
>> > Marienstrasse 12
>> > 10117 Berlin
>> > Germany HRB 109885 B Amtsgericht Charlottenburg
>> > Ust-ID Nr. DE255974207
>> >
>> > _______________________________________________
>> > media-types mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/media-types
>> >
> 
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 13 Sep 2016 16:50:41 +0900

> 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.

> .

-- 
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