Subject: [media-types] (arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.txt

From: Sean Leonard <[email-masked]>
Date: Tue, 4 Nov 2014 16:28:17 -0800

Hello Colleagues:

In preparation for the arcmedia BoF, an Internet-Draft, draft-seantek-kerwin-arcmedia-type-00.txt,
has been successfully posted to the IETF repository.

This Internet-Draft was written in a hurry before the deadline, and used RFC 2077 (January 1997) as its basis. Thus, some parts of the draft may look a bit outdated. The main purposes of this draft are to sketch out the purpose of the archive top level media type, and to lay out several areas for further discussion and work.

(This Internet-Draft actually posted last week, but there was a naming snag.)

Name:		draft-seantek-kerwin-arcmedia-type
Revision:	00
Title:		Concise Binary Object Representation (CBOR) Tags for ASN.1 Object Identifiers
Document date:	2014-10-27
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-seantek-kerwin-arcmedia-type-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-kerwin-arcmedia-type-00/
Htmlized:       http://tools.ietf.org/html/draft-seantek-kerwin-arcmedia-type-00

Abstract:
  This document defines a new primary content-type to be known as
  "archive", which defines a fundamental type of content with unique
  presentational, hardware, and processing aspects.

The IETF Secretariat

-Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Nov 2014 16:55:22 -0800

> Title:          Concise Binary Object Representation (CBOR) Tags for ASN.1

Curious title.  Did you actually receive it this way?  Might be some issue
with the tracker if so.

-MSK

---

From: Sean Leonard <[email-masked]>
Date: Tue, 4 Nov 2014 16:57:21 -0800

D’oh. I copied and pasted that part incorrectly (I did not receive an automated notification; it was posted manually). Sorry!

Title:		The Archive Primary Media Type for File Archives

Sean

On Nov 4, 2014, at 4:55 PM, Murray S. Kucherawy <[email-masked]> wrote:

> Curious title.  Did you actually receive it this way?  Might be some issue with the tracker if so.
>  
> -MSK

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 5 Nov 2014 22:05:33 +0000

Good work!

Here are some executable archive formats, btw, as I saw you listed
that as controversial.

https://github.com/taverna/taverna-scufl2 (Taverna Workflow Bundle -
based on .zip)
https://rapidminer.com/ (RapidMiner workflow - based on .zip)
http://www.knime.org/ (KNIME workflow - based on .zip)
https://docs.docker.com/articles/baseimages/#creating-a-simple-base-image-using-scratch
 (Docker virtualized applications - based on .tar)
https://en.wikipedia.org/wiki/JAR_%28file_format%29 (Java library and
application - based on .zip)
https://en.wikipedia.org/wiki/Open_Virtualization_Format (OVA Virtual
Machine - based on .tar)

However for almost all of these one can argue that their main purpose
is not to be an archive, as their constituent files don't make much
sense outside the execution environment, and therefore they would not
want to be under archive/ for the benefit of the user.

It is still interesting for anti-virus engines to investigate such
archives, but then again they would also want to check the actually
executable code as well..

On 5 November 2014 00:57, Sean Leonard <[email-masked]> wrote:
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types
>

-- 
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: Wed, 05 Nov 2014 22:02:24 +0000

It's good to see a proposal on the table, but I shall not be present at the BoF.

If the issue of a common/default fragment identifier syntax is brought up, and 
without prejudice as to whether or not that's a good thing to specifiy, I would 
suggest looking at http://w3ctag.github.io/packaging-on-the-web/ as a candidate 
design (specifically 
http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers).

The 'url=' option described there would, I think, encompass the case of a 
relative URI reference that is resolved relative to the base of the archive, as 
well as MIME-multipart-style mid:/cid: style references.  E.g.

     http:/example.org/my/archive#url=/root/sub/file

or

     http:/example.org/my/archive#url=cid:[email-masked]

I don't claim that the cid: example serves a useful purpose; I'm just noting 
that the 'url=' option can accommodate different forms of reference.

It's not clear to me if the other options described at 
http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers would be 
useful with an archive media type, but if the keyword=value format is used, the 
door can be left open to supporting such options.

(I don't claim that specification is itself a candidate for an archive/ subtype, 
because it serves a different purpose, but it would seem to me to me to make 
sense if there were some commonality of fragment identifier syntax and mechanism 
for accessing components within a composite object.)

#g
--

On 05/11/2014 00:28, Sean Leonard wrote:
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss