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

From: Graham Klyne <[email-masked]>
Date: Thu, 01 Jan 2015 10:21:07 +0000

On 31/12/2014 20:42, Dave Crocker wrote:
>     Archive formats are used to aggregate multiple files and other data
> into a single object, often with data compression and/or confidentiality
> protection (encryption).

This may be enough to address the point in an email I just sent (about scope re 
"archive" vs "multiple-file" format)?

#g
--

---

From: Sean Leonard <[email-masked]>
Date: Fri, 02 Jan 2015 05:29:17 -0800

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Jan 2015 09:59:54 -0800

On Fri, Jan 2, 2015 at 5:29 AM, Sean Leonard <[email-masked]> wrote:

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

It was supposed to be but it got truncated.  Added now.

> necessary IMO. If it is not in the approved charter, is is out-of-scope by
> definition.
>

That has not been the case in the past; sometimes leaving it unstated has
been interpreted as an ambiguity, and we're left to argue about whether
unstated things are covered by other wording.

-MSK

---

From: Larry Masinter <[email-masked]>
Date: Fri, 2 Jan 2015 18:30:29 +0000

https://github.com/mskucherawy/docs/blob/master/charter-arcmedia

"The W3C TAG work on packaging and archives, currently in progress, will also be observed."

addresses my concern. Thanks,

Larry
--
http://larry.masinter.net

---

From: Sean Leonard <[email-masked]>
Date: Fri, 2 Jan 2015 14:40:08 -0800

On Jan 2, 2015, at 10:30 AM, Larry Masinter <[email-masked]> wrote:

> "The W3C TAG work on packaging and archives, currently in progress, will also be observed.”

“observed” has two definitions: “will be looked at for informational purposes”, and “will be followed (respected = treated as normative)”.

I am okay with the former, but not with the latter. (And since we are talking about the charter, we need to be clear in the language which one we mean.)

As I wrote, the TAG stuff isn’t even a thing in use. ZIP, TAR, RAR, ISO 9660, etc. are in widespread use with long histories of deployment, and are the exemplary use cases.

Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Jan 2015 23:33:18 -0800

On Fri, Jan 2, 2015 at 2:40 PM, Sean Leonard <[email-masked]> wrote:

> “observed” has two definitions: “will be looked at for informational
> purposes”, and “will be followed (respected = treated as normative)”.
>

Since the thing being observed is a work-in-progress outside of the IETF, I
guessed that wouldn't be taken normatively.

How about "considered"?

-MSK

---

From: Sean Leonard <[email-masked]>
Date: Sat, 03 Jan 2015 00:31:49 -0800

On 1/2/2015 11:33 PM, Murray S. Kucherawy wrote:
> On Fri, Jan 2, 2015 at 2:40 PM, Sean Leonard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     “observed” has two definitions: “will be looked at for
>     informational purposes”, and “will be followed (respected =
>     treated as normative)”.
>
>
> Since the thing being observed is a work-in-progress outside of the 
> IETF, I guessed that wouldn't be taken normatively.
>
> How about "considered"?

"considered" is ok.

Please also put ISO 9660 in the charter, however--or if people don't 
like ISO 9660, some other archive format that is unquestionably a disk 
image. (TARs can be disk images, as they can store inode block info. But 
they are not generally thought of primarily in that way.)

Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Jan 2015 07:28:01 -0800

On Sat, Jan 3, 2015 at 12:31 AM, Sean Leonard <[email-masked]> wrote:

>
> Please also put ISO 9660 in the charter, however--or if people don't like
> ISO 9660, some other archive format that is unquestionably a disk image.
> (TARs can be disk images, as they can store inode block info. But they are
> not generally thought of primarily in that way.)
>

Can you propose a specific text change?  I'm having trouble seeing how this
would improve the charter given the only specific references we have in
there now are examples, and more of those won't change much...

-MSK

---

From: Sean Leonard <[email-masked]>
Date: Sat, 03 Jan 2015 10:10:48 -0800

On 1/3/2015 7:28 AM, Murray S. Kucherawy wrote:
> On Sat, Jan 3, 2015 at 12:31 AM, Sean Leonard <[email-masked] 
>     Please also put ISO 9660 in the charter, however--or if people
>     don't like ISO 9660, some other archive format that is
>     unquestionably a disk image. (TARs can be disk images, as they can
>     store inode block info. But they are not generally thought of
>     primarily in that way.)
>
>
> Can you propose a specific text change?  I'm having trouble seeing how 
> this would improve the charter given the only specific references we 
> have in there now are examples, and more of those won't change much...

Here's a diff, and the changed text.
(Not sure if it will be accepted by the IETF mailing list...guess we're 
about to find out)

Sean
--- charter-arcmedia.txt	2015-01-03 09:37:30 -0800
+++ charter-arcmedia2.txt	2015-01-03 10:05:23 -0800
@@ -5,9 +5,11 @@
 
 There has been recent work to register media types for archive formats such
 as .tar (a POSIX standard format).  There are already several similar media
-types for archive formats, such as .gzip. and .zip. (see, for example,
-RFC6713), all of which are registered under the top-level media type
-"application".
+types for archive formats, such as .gzip. and .zip [RFC6713],
+all of which are registered under the top-level media type
+"application". Other formats for backup, disk imaging (e.g., .dmg,
+ISO 9660), and software packaging (e.g., .pkg, .rpm, .msi) are in
+widespread use on the Internet.
 
 We create top-level media types only rarely, only with Standards Track RFCs,
 and only when one or more media types get special (or common, in the case
@@ -19,6 +21,11 @@
 new top-level type, considering at a minimum the issue of type suffixes,
 fragment identifiers, and internationalization.  The W3C TAG work on
 packaging and archives, currently in progress, will also be considered.
+The working group will also consider and attempt to describe default
+fallback handling that applies across archive types.
+By extension, the working group will also consider and attempt
+to describe the types of formats that are appropriate for this
+top-level media type.
 
 Either in that same document or in a second one, it will produce an initial
 set of registrations under the new top-level media type.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Jan 2015 10:55:11 -0800

On Sat, Jan 3, 2015 at 10:10 AM, Sean Leonard <[email-masked]> wrote:

> this would improve the charter given the only specific references we have
> in there now are examples, and more of those won't change much...
>
>
> about to find out

I'm fine with the second change, but I don't understand why we need the
first.  All it does (as far as I can tell) is make the example list longer.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2015 19:17:48 -0000

>(Not sure if it will be accepted by the IETF mailing list...guess we're 

I'm with Murray.  It seems harmless but pointless.  One the things a WG
will have to do is to figure out what counts as an archive data format.
If you want us to consider ISO 9660, I want us to consider ANSI INCITS 27.

R's,
John

---

From: Sean Leonard <[email-masked]>
Date: Sat, 03 Jan 2015 11:24:16 -0800

> If you want us to consider ISO 9660, I want us to consider ANSI INCITS 27.

If it's used in regular commerce on the Internet, I don't have a problem 
with ANSI INCITS 27.

But I think your suggestion is a bit tongue-in-cheeck. .iso files are 
*everywhere* on the Internet, and can contain payloads that seriously 
affect the security of Internet-connected systems. I believe there is a 
certain popular website out there just dedicated to "hunting" for them. 
And to-date it still doesn't have a media type.

A few e-mails back, it was stated that "No other work is in scope for 
this working group" [except what's in the charter]. So the natural 
evolution is to be sure that the charter includes everything that should 
be in-scope.

Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Jan 2015 14:54:12 -0800

Why does creating a new top level type also have to include everything that
will be in it?

That paragraph just gives examples so the unfamiliar reader will know what
space we're talking about. I don't understand the purpose of enumerating
all of the arguably popular instances of archive formats.

-MSK
On Jan 3, 2015 11:25 AM, "Sean Leonard" <[email-masked]> wrote:

> certain popular website out there just dedicated to "hunting" for them. And
> to-date it still doesn't have a media type.
>
> A few e-mails back, it was stated that "No other work is in scope for this
> working group" [except what's in the charter]. So the natural evolution is
> to be sure that the charter includes everything that should be in-scope.
>
> Sean
>
> _______________________________________________
> arcmedia mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/arcmedia
>

---

From: Larry Masinter <[email-masked]>
Date: Sun, 4 Jan 2015 01:23:17 +0000

I didn’t want to quibble about the verb – “observed” is ambiguous, but so is “considered”. I was hoping not to have to define precisely what coordination is being mandated, but “will be looked at for informational purposes” isn’t strong enough.

If the W3C TAG work were instead in an IETF working group chartered to produce it, would the IETF even charter another group? If so, what coordination would be expected?

The way the IETF commits to do work is by chartering working groups; the way the IETF commits to coordinate is by putting the promise in working group charters (or, in APSAWG the document mini-charter).  I don’t want to wordsmith the charter and have the intent get lost. I want to avoid seeing IETF standardize arcmedia while W3C standardizes an arcmedia format which isn’t compatible. This may be simple or may require active coordination on both sides.

If we agree to the sentiment, we can decide how to say it in the charter.

(bcc public-ietf-w3c re arcmedia working group charter)

Larry

Since the thing being observed is a work-in-progress outside of the IETF, I guessed that wouldn't be taken normatively.

How about "considered"?

"considered" is ok.