Subject: [apps-discuss] IETF 91 scheduling

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Sep 2014 13:36:23 -0700

Colleagues,

The window is closed for us to request a meeting slot for Toronto.  We have
requested our usual APPSAWG/APPAREA Monday morning 9:30 slot with the usual
conflict set.

Please propose agenda items for this meeting in response to this thread.
We'll have our usual updates from the co-chairs and ADs and will be
inviting chairs of BoFs and newly formed working groups to give short
presentations on what's happening during the week.

If you are working on a document in APPSAWG that requires face time to
resolve some issues, or would like to make or request a presentation on a
particular topic, please let us know ASAP.  Our preliminary agenda is due
to the Secretariat on Friday, October 27th, which is also the final date to
be able to submit drafts to the datatracker before the meeting.

-MSK, APPSAWG co-chair

---

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Sep 2014 14:46:43 -0700

Topic: Archive TLMT

Based on responses from last week (and the IETF 91 BoF deadline), I requested that the Area Directors schedule a BoF. They have not responded yet one way or another. This might be a good opportunity for apps-discuss to consider whether it makes more sense to discuss it in APPSAWG, to create a BoF, to create a new WG, or some combination of the three.

Additional TLMTs (top level media types) have been proposed *rarely* but none have actually been registered in recent memory. Since they aren’t proposed very often, however, it doesn’t seem to me that we need to layer on additional process beyond the normal IETF processes that are in place for new proposals in general.

Here are some of the issues to be considered, which I put on the proposed BoF agenda:
Agenda
Discuss proposal to make archive TLMT
Identify use cases
Identify types of archives and whether these types of archives should all go in, e.g.: archiving only, multi-function, software packaging, disk images, backup
Identify formats in common use, and debate which ones should be considered as exemplary for purposes of creating archive TLMT
Identify commonalities between all formats
Sketch how to represent commonalities (e.g., fragment identifiers), and whether these commonalities should be mandated (e.g., all fragment identifiers have the same syntax or the same (possibly extensible) base syntax)
Identify user interface considerations
Identify security considerations
Identify composite-type considerations (e.g., Content-Coding of bzip2 vs. integrating into media type)
Identify issues with interchange when sending and receiving systems do not have the same settings (e.g., different code pages), and the failure to coordinate these same settings result in interchange problems because the archive does not take the differences into consideration (e.g., interpreting file names in one character set/codepage vs. another character set/codepage, where the character set/codepage is not specified in the archive)
Divide work up
Overall I think that the archive TLMT can be defined in a single RFC, which itself does not justify the creation of a working group. However, it is not sufficient to define the archive TLMT—we ought to take the time to review and register a broad swath of the common formats that are being exchanged on the Internet, including:
 zip (i.e., reconsider whether it should be reclassified, or dual-classified)
 rar
 arj
 7z
 tar
 tar.* (.tar.gz, .tar.bz2, etc.)
 iso
 bin/cue
 ace
 arc
 arj
 img/ima/imz (floppy disk images)
 dmg (Apple disk images)
 nrg
 rpm
 sit
 vmdk
 vhd
 vfd
 uif
 
The list goes on and on, and new formats continue to be invented. There is a lot of specialized knowledge in this area (what formats can contain hidden executable code [hint: many CD/optical disc images can—with serious consequences]? what formats can store NTFS alternate data streams, POSIX extended attributes, Mac OS resource forks, etc.? do some of these formats allow for generalized metadata? how do the formats select code pages or character sets?), so it is not realistic for all this registration activity to go on with one RFC.

So…shall we schedule APPSAWG time? BoF? Direct to new WG? Some of the three?

Best regards,

Sean

On Sep 29, 2014, at 1:36 PM, Murray S. Kucherawy <[email-masked]> wrote:

> Colleagues,
> 
> The window is closed for us to request a meeting slot for Toronto.  We have requested our usual APPSAWG/APPAREA Monday morning 9:30 slot with the usual conflict set.
> 
> Please propose agenda items for this meeting in response to this thread.  We'll have our usual updates from the co-chairs and ADs and will be inviting chairs of BoFs and newly formed working groups to give short presentations on what's happening during the week.
> 
> If you are working on a document in APPSAWG that requires face time to resolve some issues, or would like to make or request a presentation on a particular topic, please let us know ASAP.  Our preliminary agenda is due to the Secretariat on Friday, October 27th, which is also the final date to be able to submit drafts to the datatracker before the meeting.
> 
> -MSK, APPSAWG co-chair
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Sep 2014 22:03:35 -0700

> So…shall we schedule APPSAWG time? BoF? Direct to new WG? Some of the
I think we need to wait until the BoF decision is made before allocating
APPAREA time (it's not APPSAWG, unless there's a draft up for
consideration).

-MSK

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Sep 2014 06:03:41 -0400

--On Monday, September 29, 2014 14:46 -0700 Sean Leonard
<[email-masked]> wrote:

> Topic: Archive TLMT
>...
> Here are some of the issues to be considered, which I put on
> the proposed BoF agenda: Agenda
> Identify types of archives and whether these types of archives
> should all go in, e.g.: archiving only, multi-function,
> software packaging, disk images, backup Identify formats in
>...

Hi.

I had planned to sit this one out because I see some value in
the general idea and probably little harm.  I also agree with
Ned that things have evolved in a way that probably makes this
reasonable and that there is little justification for trying to
invent a complex architectural process before adding one new
type.

However, unless my memory is failing me, there is one historical
tidbit about which people should be aware.  Ned wrote "There
used to be a strong reluctance to register media types for
archive formats".   My recollection is that it was a bit more
than that, that archives (particularly of the zip and tar
persuasions) were explicitly discussed and believed to be
orthogonal to Content-type and Content-transfer-encoding,
inappropriate for top-level Content-types (now Media types)
unless we expected email clients to actually take some action on
them, e.g., by exploding them or having some other specific
action routines for them.  That is where the analogy to
multipart/ (or even message/) breaks down a bit because we have
precisely that expectation of those top level aggregate and
potentially aggregate types.  By contrast, archive/ would really
be an aggregate identifier for components that, at least with
the two or three most popular archive formats, do not have media
types except by naming convention.  

If the intent is merely to identify the content, rather than
expecting action and to create another top-level type that, like
application/ is expected to be opaque to the mail system,
perhaps we should be generalizing and considering "container/"
or, to borrow a note from X.400, even "FileTransfer/", rather
than thinking there is something extra-special about archives.

On the other hand, there is something extra-special, which is
frequency of use, and things have changed a lot since
Content/Media types were first defined in the current contexts,
so this is just something to think about rather than a strong
alternate suggestion.

     john