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

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

On 01/01/2015 00:02, Larry Masinter wrote:
> Happy new year...
>
> -----Original Message-----
> From: Larry Masinter
> Sent: Wednesday, December 31, 2014 4:01 PM
> To: 'Graham Klyne'; Murray S. Kucherawy; Stian Soiland-Reyes
> Cc: [email-masked]; IETF Apps Discuss
> Subject: RE: [apps-discuss] Proposed charter for arcmedia
>
> I think the arcmedia WG charter should take into the W3C TAG work on packaging/archives
>
> http://w3ctag.github.io/packaging-on-the-web/

Agreed.  But noting that there could be some differences in emphasis, as that 
format is not intended to be an *archive* format.   Which I guess begs a 
question here: should the charter focus to be on *archive* or more broadly on 
multiple-file packaging formats?  (I'm not sure what difference that would make 
in practice, but I have a feeling some archival specialists might have something 
to add about this.)  I lean to the latter, but "archive format" is a more 
concise description.

In particular, if suggesting a common fragment identifier format, I think the 
specification in the W3C document could be useful to consider for adoption.

#g
--

>
> (W3c-tag bcc)
>
>
>> -----Original Message-----
>> From: apps-discuss [mailto:[email-masked]] On Behalf Of
>> Graham Klyne
>> Sent: Wednesday, December 31, 2014 8:00 AM
>> To: Murray S. Kucherawy; Stian Soiland-Reyes
>> Cc: [email-masked]; IETF Apps Discuss
>> Subject: Re: [apps-discuss] Proposed charter for arcmedia
>>
>> Re:
>> http://www.ietf.org/mail-archive/web/arcmedia/current/msg00001.html
>>
>> I think the suggested charter looks pretty good.  The work seems
>> well-scoped to me.
>>
>> I'd expect to review at least the proposed base document, and maybe
>> some of the initial registrations.
>>
>> #g
>> --
>>
>>
>> On 30/12/2014 18:13, Murray S. Kucherawy wrote:
>>> On Mon, Dec 29, 2014 at 9:58 PM, Stian Soiland-Reyes <
>>> [email-masked]> wrote:
>>>
>>>> Hi - what's the status of the chartering of the arcmedia WG? I
>>>> don't see that it has been added to http://datatracker.ietf.org/wg/
>>>> and there is no further emails on the arcmedia mailing list.
>>>>
>>>
>>> A mailing list was created shortly after the November meeting, and
>>> the proposed charter was posted there and here.  There has been no
>>> response of any kind.
>>>
>>> -MSK
>>>
>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

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: Stian Soiland-Reyes <[email-masked]>
Date: Fri, 2 Jan 2015 04:54:22 -0600

I think the whole point of the archive/ type is the general
archive/file fall-back, as discussed in the BOF - e.g. the OS/browser
can do "I don't know how to deal with this
archive/grahams-latest-thing, I'll just throw it at
Winzip/7Zip/Archive Manager and hope for the best" - it's a similar
default as Notepad for text/* and Gimp for image/*.

Packaging-on-the-web *is* relevant, because it is deliberately an
archive, while say application/vnd.msoffice.cant.remember.exactly.docx
is NOT meant to be an archive for the general user. It is not helpful
for grandma to get her word-document expanded as a file structure. A
developer who wants to extract images might like that - but she would
need to know more than it being an archive.

I'm not sure what is the timeline for
http://w3ctag.github.io/packaging-on-the-web/ - it doesn't say.  I
have anyway reminded them about us at
https://github.com/w3ctag/packaging-on-the-web/issues/13 :)

On 1 January 2015 at 04:17, Graham Klyne <[email-masked]> wrote:
> Agreed.  But noting that there could be some differences in emphasis, as
> that format is not intended to be an *archive* format.   Which I guess begs
> a question here: should the charter focus to be on *archive* or more broadly
> on multiple-file packaging formats?  (I'm not sure what difference that
> would make in practice, but I have a feeling some archival specialists might
> have something to add about this.)  I lean to the latter, but "archive
> format" is a more concise description.
>
> In particular, if suggesting a common fragment identifier format, I think
> the specification in the W3C document could be useful to consider for
> adoption.
>
> #g
> --
>
>>
>> (W3c-tag bcc)
>>
>>
> arcmedia mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/arcmedia

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

---

From: Graham Klyne <[email-masked]>
Date: Fri, 02 Jan 2015 13:07:44 +0000

Hi Stian,

> default as Notepad for text/* and Gimp for image/*.

I don't know what was said at the BoF.  This being the IETF, it didn't 
officially happen unless it also appears on the mailing list.

Is this something that you think should appear in the charter?

I'm not entirely convinced that archive/<unknown> has a safe fallback like 
text/<unknown> - I think in that respect it's more like application/<unknown> 
which falls back to application/octet-stream, for which the default behaviour is 
generally to just save it.  Of course, individual implementations may use their 
own local fallback strategies along the lines you suggest, but I'd suggest 
that's out of scope for a MIME type spec.

> need to know more than it being an archive.

Well, that wasn't my reading of http://w3ctag.github.io/packaging-on-the-web/, 
but rather that it is intended for efficient delivery of complex web pages. 
Specifically, the descision to *not* use regular MIME multipart format there was 
because that does not lend itself to streaming data processing, which I don't 
see as a requirement for archives (in the sense of preservation formats).  But I 
could be missing something, so feel free to point out why you think it is an 
archive format.  (I'm not sure what the msoffice example has to do with this - 
I'd say that too is clearly not an archive format.)

All this is probably moot with the revised charter wording - "Archive formats 
are used to aggregate multiple files and other data into a single object"; this 
suggests a broader reading of "archive" which I think the packaging-on-web spec 
does address (and per current charter, the msoffice stuff too, but I don't 
offhand think that has much to say to archive MIME type requirements).

> https://github.com/w3ctag/packaging-on-the-web/issues/13 :)

Good!  It's been quiescent for a while, but I think did see a recent mention of 
it on the W3C TAG list.

#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: Sean Leonard <[email-masked]>
Date: Fri, 02 Jan 2015 05:34:58 -0800

On 1/2/2015 5:07 AM, Graham Klyne wrote:
> I'm not entirely convinced that archive/<unknown> has a safe fallback 
> like text/<unknown> ...

The BoF was an official BoF...and minutes were taken. So I think the 
minutes need to be posted to the mailing list. (I forgot who took the 
minutes.)

But yes, this stuff was explicitly discussed; one common motivator is 
that archive/* should have fallback handling that is more specific than 
application/octet-stream. As of 2015, many file archive programs are 
swiss-army knives, handling a wide array of formats.

Cheers,

Sean

---

From: Graham Klyne <[email-masked]>
Date: Fri, 02 Jan 2015 14:54:59 +0000

On 02/01/2015 13:34, Sean Leonard wrote:
> ... one common motivator is that
> archive/* should have fallback handling that is more specific than
> application/octet-stream. As of 2015, many file archive programs are swiss-army
> knives, handling a wide array of formats.

If consensus can be found for a common fallback, then fine.  I'll be interested 
to see a concrete proposal.

But I have a suspicion it might prove harder than at first seems, to describe a 
fallback that can work (in the sense of providing a useful increment of 
interoperability over application/octet-stream treatment) across all reasonable 
contexts.  I'd hate for the work to founder on this point.

In other words, I suggest: don't create a hostage to fortune by making this a 
hard charter requirement.  But by all means consider it.

#g
--

---

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