Re: [arcmedia] [apps-discuss] Proposed charter for arcmedia

[Sean Leonard <[e-mail]>]

Hello all and Happy New Year. Sorry that I didn't respond to this thread 
earlier--a lot going on with the holidays.

I looked at 
<https://github.com/mskucherawy/docs/blob/master/charter-arcmedia> just 
now, which I assume is the latest.

On 12/31/2014 12:42 PM, Dave Crocker wrote:
>> its initial input.  It will specify rules for registering subtypes
>> under that new top-level type.  All of the usual things will be
>> considered, including type suffixes, fragment identifiers, and
>> internationalization.
> Replace sentence with:
>
>      The rules will at least include consideration of type suffixes,
> fragment identifiers, and internationalization.

Yes, please include this text. (It's not in yet.)

With all respect to the W3C TAG work, I find the TAG stuff inapposite. 
Perhaps it should be considered, but it should carry less weight than 
formats that already exist and are in widespread use. These formats include:
ZIP
TAR family
RAR
SIT (StuffIt)
7-Zip / LZMA
Disk-Image Formats, including DMG, ISO 9660, WIM, VMDK

I think that at least a couple more formats should be mentioned by name; 
ISO 9660 for example (seeing as how it is an SDO-based format).

I understand the point of TAG, but it doesn't seem much different in 
spirit, scope, or technical details to MHTML 
<https://tools.ietf.org/html/rfc2557> 
<http://en.wikipedia.org/wiki/MHTML>, except maybe the fragment 
identifier stuff. In any event, TAG packages and MHTML are not *file* 
archive formats per-se; they are ways of bundling web content (with the 
headers and URI references) into one stream, much like message/rfc822. 
It would seem more appropriate for TAG packages to be classified under 
message/* or multipart/*. Indeed it looks completely feasible to fold 
TAG packages into RFC 2557 and RFC 2387 (multipart/related) with 
Content-Type: multipart/related; type="text/w3c-package-directory". The 
root part would just be a flat text file with separators, basically 
being the directory of the parts (since one complaint about the ZIP 
format is that the directory is at the end). If the boundary parameter 
requirement of "multipart"is too burdensome (a dubious assertion IMO), 
the format can be classified with message/* instead.

The statement "No other work is in scope for this working group" is not 
necessary IMO. If it is not in the approved charter, is is out-of-scope 
by definition.

Cheers,

Sean