Subject: Re: [apps-discuss] IETF 91 scheduling

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 1 Oct 2014 13:38:08 +0000

On 9/30/14, 10:03 AM, "John C Klensin" <[email-masked]> wrote:

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

Virus scanning seems like a reasonable thing that you would want to do to 
all archives, regardless of subtype.  The content type is used by several 
more actors than just the MUA now.

-- 
Joe Hildebrand

---

From: Dave Cridland <[email-masked]>
Date: Wed, 1 Oct 2014 14:45:45 +0100

> more actors than just the MUA now.

Would a virus scanner forego scanning anything that didn't mark itself as
an archive? Are we expecting viruses in archives to be clearly marked as
archives?

If media types are reliable, then a top-level media type of malware would
solve all our problems.

I'm not against archive as a top-level type, it seems generally reasonable,
but I don't see any security advantage in it.

Dave.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 1 Oct 2014 14:28:42 +0000

>an archive? Are we expecting viruses in archives to be clearly marked as 

It might block content that was an archive/ type that it didn't know how 
to explode.

>If media types are reliable, then a top-level media type of malware would 

Sure.  That's just a straightforward extension of RFC 3514.  We could 
probably get such an RFC published by the end of March.

>I'm not against archive as a top-level type, it seems generally 
>reasonable, but I don't see any security advantage in it.

I'm not claiming any security advantage.  Just pointing out some changes 
to the underlying assumptions of the system since the last time we had 
this conversation.  Namely, more things on-path process the media type now.

-- 
Joe Hildebrand

---

From: Sean Leonard <[email-masked]>
Date: Wed, 01 Oct 2014 08:39:41 -0700

On 9/30/2014 3:03 AM, John C Klensin wrote:
> [SNIP]
> 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.

A lot has changed with the world since RFC 2045 in '96. MIME types -> 
Internet media types are not limited to e-mail; essentially they have 
become the de-facto, vendor neutral way to identify formats that ever 
might be destined for Internet transport. They are used in HTTP, and 
therefore affect how HTTP clients and servers behave; they are also used 
by lots of applications that touch HTTP in some way, such as content 
management systems (CMSes). They are used by "online" file systems such 
as Dropbox and Google Drive to manipulate behavior. Some "offline" file 
systems (such as Apple Mac OS X / HFS+) use media types directly, or 
have provisions for their use (Uniform Type Identifier 
public.mime-type). Some version control systems (e.g., Subversion 
svn:mime-type) also use them directly.

Additionally, some modern e-mail clients provide facilities to view 
archives directly. Outlook 2007+ has attachment previewers 
<https://support.office.com/en-US/Article/Find-attachment-previewers-23c5f60e-2e09-4cfa-b2b8-a42942835cd2?ui=en-US&rs=en-US&ad=US> 
and there are preview handlers for ZIP files specifically 
<http://kb.winzip.com/help/courier/WhatsNew.htm>, not to mention other 
types.

Since filename extensions are not standardized (and there are many 
instances of content that are not file-oriented), the overall gist is 
that media types are becoming the de-facto vendor-neutral way to 
identify different types of content.

Sean

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Oct 2014 08:56:38 -0700

> more actors than just the MUA now.

Not just regardless of subtype.  Also regardless of top-level type.

Problematic archives are /less/ likely to be located in a place that
explicitly identifies the data as an archive.

This line of issue is probably similar to the concern for placing adult
content under hosts with .xxx domain names...

That is, there might be benefit for good actors in the system, but
there's not likely to be any benefit in identifying bad actors (who have
an incentive to hide their presence.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Sean Leonard <[email-masked]>
Date: Wed, 1 Oct 2014 11:32:34 -0700

On Oct 1, 2014, at 6:45 AM, Dave Cridland <[email-masked]> wrote:

> On 1 October 2014 14:38, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
> 
> Would a virus scanner forego scanning anything that didn't mark itself as an archive? Are we expecting viruses in archives to be clearly marked as archives?

The intuition about malware is correct…but one should add a bit of finesse.

First of all any scanner worth its salt should be scanning all things saved to disk (that includes inline content) for viruses and things.

The issue comes down to properly labeling different types of content between security domains, namely the Internet domain (where file extensions are not reliable or are not supplied) and the local computer (where file extensions usually determine some default action).

In the Before Time, “everybody" said:
command file.dat

Now, people say:
<click on> <such-and-such-content>

I.e., acting upon the content, such as double-clicking a file, launching a file, clicking a link, touching a button, etc. does the default thing—the computer figures out what to do by context. It’s been this way since the first GUIs were invented.

I have noticed that a lot of the time, when you send photos in Apple’s iOS Mail, the photo received simply has the name “photo”. The recipient mail client might display the photo; it might also save the photo to disk. Should it save the photo as “photo”, or as “photo.jpg”?

Answer: photo.jpg, because the Content-Type should be image/jpg (this is also a tip to pass it to the image-processor, so that the recipient can see the photo in the message). In the local computing environment, JPEG images are distinguished by .jpg. If the data is GIF and is labeled “photo.jpg”, the most appropriate thing is to name it “photo.jpg.gif” (or “photo.gif”) locally. (In the case of Mac OS X/iOS, it’s acceptable to name it “photo” because the Uniform Type Identifier should be set as “public.jpeg”.)

Now consider a more malicious case, some executable or shell script. This executable or script may be specifically targeted to infect the recipient’s computer, i.e., a spear-phishing attack where the recipient is some corporate executive, FCC commissioner, judge, district attorney, or operator of a nuclear facility in Iran. No matter how good your virus scanner is, it’s unlikely to detect such a specifically and uniquely-crafted executable.

A naive mail client will take the purported name “www.example.com” (or “instructions” with no extension, or “instructions.sh”) and save it to disk—omitting the critical metadata about the media type. If the media type is text/plain, for example, the RIGHT thing to do is to change it to “www.example.com.txt”. Thus if a user launches the file, he’s going to get Notepad, TextEdit, gedit, or emacs; not some shell script execution.

Of course if the sender is malicious, he will not want that behavior—he will want (some/executable) media type. But then an intervening virus scanner can apply extra scrutiny because the media is mislabeled, and use that as a heuristic to reject the message as spam or phishing.

Currently we are in a regime where a lot of archives are transmitted as application/octet-stream. This gives no hint whatsoever to the recipient (or any intervening virus scanner) on how to handle the content. Thus a malicious sender can send something that LOOKS like an archive as “critical-FDA-drug-applicationZIP”, as application/octet-stream, and then when the recipient saves it to disk and tries to use it, they are going to get non-ZIP archive behavior.

Conclusion: setting everything to application/octet-stream is bad because it is information-lossy and requires content-sniffing or user intervention to do the right thing. Unregistered media types (application/x-7z) are as good as application/octet-stream for interoperability. Let’s register things.

Sean

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Oct 2014 12:41:41 -0700

On 29 September 2014 14:46, Sean Leonard <[email-masked]> wrote:
> Topic: Archive TLMT

A topic that would interest me more is whether top level media types
should be abandoned.

I see almost everything ending up in 'application', with occasional
exceptions for 'text' if the content happens to not be binary (or some
other equally inane reason).

The only place I'm aware of that the top-level distinction takes on
special meaning is in describing real-time media ('audio' and 'video')
in SDP.  It could have used other signals equally.  Treating media
type as an opaque blob works best anyway.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 1 Oct 2014 21:47:28 +0200

> other equally inane reason).

I thought application/x-foo is code for "I heard publishing RFC makes you 
spend six months with idnits and discussing the wording of relative 
clauses". If you see what I mean and I think you do.

And the whole point is perfectly orthogonal to archive/*.

Armt

---

From: Barry Leiba <[email-masked]>
Date: Wed, 1 Oct 2014 20:52:20 +0100

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

Actually, I did respond one way or another: You requested the BoF *on
the day of the deadline*, and I responded that I was in the air that
day, and that I'd make sure it got into the wiki.

I did, and it did, and we approved the BoF today, for a one hour slot
-- that should be plenty of time.

Of course, it's fine to continue discussing it on this list between
now and then, and I encourage that -- but please use a separate
thread, rather than hijacking Murray's call for agenda items.

Carry on...

Barry

---

From: t.petch <[email-masked]>
Date: Thu, 2 Oct 2014 18:00:39 +0100

----- Original Message -----
From: "Sean Leonard" <[email-masked]>
To: "John C Klensin" <[email-masked]>; "Murray S. Kucherawy"
<[email-masked]>; "Ned Freed" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Wednesday, October 01, 2014 4:39 PM

> archives directly. Outlook 2007+ has attachment previewers
<https://support.office.com/en-US/Article/Find-attachment-previewers-23c
5f60e-2e09-4cfa-b2b8-a42942835cd2?ui=en-US&rs=en-US&ad=US>
> identify different types of content.

which is fine when the storage mechanism caters for metadata and makes
it accessible in a standard way.  Sadly, the DOS directory was not
designed in that way, which is why the vast majority of computer systems
in the world (Windows!) continue to use file extensions:-(

The problem keeps recurring - character sets, i18n, etc - but we do not
progress towards a solution.

Tom Petch

> Sean
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Sean Leonard <[email-masked]>
Date: Fri, 03 Oct 2014 12:33:03 -0700

On 10/2/2014 10:00 AM, t.petch wrote:
> Sean Leonard wrote:

Correct. It is a significant industry-wide problem that nobody wants to 
take charge of.

Apple has addressed the problem well-enough by using extended attributes 
to store a wide range of metadata. For example, OS X uses that for 
Uniform Type Identifiers; for text files, the content encoding is stored 
in the "com.apple.TextEncoding" attribute [1]. Unfortunately, that is 
specific to Apple's use. (Technically "xattr" is from BSD though.) 
Extended attributes are not standardized in POSIX, and other OSes treat 
them differently. In Linux (specifically ext2/3/4 and btrfs 
filesysetms), I believe that extended attributes are limited to one 
filesystem block.

As for Windows...NTFS has alternate data streams (ADS) which are used 
for storing a lot of metadata. Ironically ADS is used "less" (in the 
popular conception) for legitimate purposes, even though compared to the 
Unix world, ADS is considerably more versatile, i.e.: arbitrary data 
streams, can identify the stream as an appendage to the filename. It 
doesn't help that the most common filesystem family for removable media 
is still FAT/FAT32/exFAT, though (which offers no support for extended 
attributes).

It would be nice if there were a universal way to store metadata once it 
leaves the domain of Internet protocols, but that is sort of where the 
IETF's jurisdiction ends. Some folks insist that formats should or must 
include all relevant metadata in the content stream. That is punting the 
problem. Besides, there are formats that were never designed for 
interchange that are now being foisted into the Internet infrastructure, 
and those formats need the extra metadata as "help". Text encoding is a 
prominent example.

I thought about writing an I-D on how to store such metadata in a common 
way by having Internet message header data stored alongside the file, 
either in extended attributes or in an adjacent file, as: 
document.markdown -> document.markdown.headers ([RFC6522] Section 4) or 
document.markdown.u8hdr ([RFC6533] Section 6.3). I still might write it, 
but it's low on the list.

The issues then become:
1. what makes one particular metadata format (Internet message/MIME 
headers) "better" than other metadata formats (RDF, Dublin Core, JSON, 
YAML, Microdata format, blah blah),
2. what about all the corner cases (encoded words),
3. what happens when there are conflicts between other sources of 
metadata (conflict between headers file and extended attributes; 
conflict between HTTP server's desired headers and explicitly set 
headers), and ultimately,
4. "will anybody actually use this".

Sean

[1]: 
http://www.araxis.com/merge/documentation-os-x/working-with-character-encodings.en

---

From: t.petch <[email-masked]>
Date: Sat, 4 Oct 2014 12:20:02 +0100

----- Original Message -----
From: "Sean Leonard" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Friday, October 03, 2014 8:33 PM

The issues then become:

<tp>
Sean

Thank you for a comprehensive survey to my mildly facetious post.  I
could add one or two more proprietary schemes but think you have covered
the field.

The first step to doing anything is to get enough energy here on this
list to do something (the issue of conflicts between file extensions and
media types has surfaced on this list before).

If something, then I would start with a problem description I-D, before
looking for a solution.  I have somewhere a list of some 98 different
interpretations of .dat which I always think sums it up well.

And I wonder if Microsoft or Apple or ... have IPR in this field, but
that is a topic for the future.

Tom Petch

</tp>
Sean

[1]:
http://www.araxis.com/merge/documentation-os-x/working-with-character-en
codings.en

---

From: Graham Klyne <[email-masked]>
Date: Tue, 14 Oct 2014 09:26:27 +0100

John,
all,

One thing that *could* be associated with an archive media type is a fragment 
syntax for URIs to reference components within an archive... I think that 
possibility is new since the old days of being mainly email focused.

(I'm wondering if this could dovetail with the file scheme work...)

(FWIW, there's a URI scheme proposal out there called app: which also wades in 
these waters - http://www.w3.org/TR/app-uri/, and also a W3C community group 
interested in packaged content - http://www.w3.org/community/rosc/, and some 
activity in the W3C TAG - http://w3ctag.github.io/packaging-on-the-web/)

#g
--

On 30/09/2014 11:03, John C Klensin wrote:
>
>
> --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
>> 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
>> ...
>
> 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.
>
> 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.
>
>       john

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Oct 2014 10:15:12 -0400

(note change of subject; should have been done earlier)

--On Tuesday, 14 October, 2014 09:26 +0100 Graham Klyne
<[email-masked]> wrote:

> John,
> all,
> 
> One thing that *could* be associated with an archive media
> type is a fragment syntax for URIs to reference components
> within an archive... I think that possibility is new since the
> old days of being mainly email focused.

Probably true.  Doesn't seem to have much, if anything, to do
with my comments below.  At the risk of replaying some of the
URNBIS discussions, one could also imagine queries to find
things in an archive by content rather than by name, etc.
Whether that would be a good idea or not is an open question on
which I really don't have much opinion.

> (FWIW, there's a URI scheme proposal out there called app:
> which also wades in these waters -
> http://www.w3.org/TR/app-uri/, and also a W3C community group
> interested in packaged content -
> http://www.w3.org/community/rosc/, and some activity in the
> W3C TAG - http://w3ctag.github.io/packaging-on-the-web/)

ack
   john

>>> 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.
>> 
>> 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
>> expecting action and to create another top-level type that,
>> like application/ is expected to be opaque to the mail system,
>> 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
>> 
>>

---

From: Ned Freed <[email-masked]>
Date: Tue, 14 Oct 2014 08:37:31 -0700 (PDT)

Very good point. Do you think it would make sense to define a generic
syntax (which of course could be overridden in specific cases)?

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Wed, 15 Oct 2014 18:05:05 +0100

> syntax (which of course could be overridden in specific cases)?

I think it _could_ be useful and sensible - I've been involved in design 
discussions where URI mechanisms to delve inside a composite package have been 
raised, and it's been tricky to figure out what would also play well in a wider 
web landscape.

I think this could be a challenge to get right, so I wouldn't rush into it 
without some careful thought.  Maybe it's the sort of thing that might usefully 
start out as being experimental. (*)

The challenges are compounded by this being a (sometimes) "level breaking" 
requirement w.r.t. URI usage on the web:  fragment IDs identify "secondary 
resources": with reference some main resource;  the fragment is never presented 
to the server when retrieving the main resource.  OTOH, the secondary resources 
are sometimes also directly accessible as individual web resources in their own 
right, and it would (sometimes) be most useful to be able to relate 
(sub)resources in an archive to free standing ones.

I think any such design attempt should probably also engage with people involved 
in the W3C web applications group (who are proposing the app: scheme mentioned 
previously, which AIUI addresses some similar concerns).

#g
--

(*) a possible approach that occurs to me is to adopt relative URI reference 
syntax (**) for archive fragments, %-escaped as needed; e.g. in a simple case 
"sub1/sub2/file.type" (but also not prohibiting query or even further fragment 
components).  Such a fragment might then be used as a relative reference w.r.t. 
an absolute file: URI base to access components within an archived that has been 
unpacked.  Or, if the unpacked archive is also (effectively) presented by a 
server (a situation I have been involved in discussing), the same relative 
reference could be resolved against an http: base URI.

On a quick look, I think this approach could play well with the proposed app: 
scheme, in that the fragment used as a relative reference w.r.t a (specified or 
implied) app: base URI could mean something like "this resource within the 
current package/archive object" (a bit like file: operates w.r.t. the current 
hosts file system).

(**) e.e. something like

   path-noscheme [ "?" query ] [ "%23" fragment ]

using elements defined at http://tools.ietf.org/html/rfc3986#section-4.2

---

From: Graham Klyne <[email-masked]>
Date: Wed, 15 Oct 2014 18:11:29 +0100

John,

I read your comments as saying, in part, there was previously seen to be no 
value in treating archives as different from any other application/... type. 
I'm suggesting that circumstances may have changed;  also that there is now an 
increased level of interest for having better ways to handle composite objects.

Beyond that, I wasn't attempting to address your more detailed comments.

#g
--

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 16 Oct 2014 10:20:10 +0100

Graham Klyne writes:

> I think it _could_ be useful and sensible - I've been involved in
> design discussions where URI mechanisms to delve inside a composite
> package have been raised, and it's been tricky to figure out what
> would also play well in a wider web landscape.

There has been, and I believe continues to be, _extensive_ discussion
of this topic in the W3C TAG.  A quick search suggests the most recent
discussion was at the F2F in January 2014 [1], which resulted in a
writeup from Jeni Tennison which in turn provoked various
comments [2] [3].

Please review this record and then coordinate any further substantive
work in this area directly with the TAG (of which I am no longer a
member).

ht

[1] http://www.w3.org/2001/tag/2014/01/08-minutes.html#item07
[2] http://lists.w3.org/Archives/Public/www-tag/2014Jan/0133.html
[3] http://lists.w3.org/Archives/Public/www-tag/2014Feb/0030.html
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Graham Klyne <[email-masked]>
Date: Fri, 17 Oct 2014 22:20:09 +0100

Henry,

While we agree that any move in this direction should take account of W3C 
interests, I'm uncertain that the TAG is the best group to engage:

- They are an *architecture* group, and it seems to me this is a design detail 
not architecture.  Jeni's draft (http://w3ctag.github.io/packaging-on-the-web/), 
which I cited previously, addresses a specific issue (delivery of composite web 
content), and provides a fairly comprehensive specification for fragment 
identifiers.  But I'd be concerned that this structure is very biased to the 
particular requirements of packaged web pages, and might be over-complex or 
difficult to apply to other archive formats.  Maybe a subset of that proposal 
could be used?

- I've not been aware of any further TAG discussion since the publication of 
http://w3ctag.github.io/packaging-on-the-web/ in April.

- My sense is that the TAG are currently heavily concerned with 
browser-as-platform issues, and aren't giving much attention to other topics.

The possible web communities of interest that I'm aware of that might have a 
stake in any archive type and/or fragment proposal are:

- W3C TAG, subject to reservations noted above

- web applications: http://www.w3.org/2012/sysapps/ (with what appears to be a 
focus on applications that run in a web browser).  This group produced the app: 
URI scheme proposal, which appears to be a way to define a URI that accesses 
components of an archive in much the same way file: URIs access files in a file 
system.

- a research objects community group, who are interested in composite objects on 
the web as a way of bundling information about research results.  My take is 
that the technical substrate to support this work would be quite similar to that 
which would support the TAG's composite web page objects work.

- parts of the library community who have been working on resource packaging and 
synchronization, notably http://www.openarchives.org.  ORE is specification to 
describe composite archive content, and ResourceSync describes a form of 
packaging for bulk synchronization of web resources.

As far as I can tell, introduction of a top-level archive type would complement, 
not compromise, the work of most of these groups (but the TAG draft currently 
proposes an application/package type).  It would probably need to coexist with 
e.g. application/zip for the foreseeable future, but I don't think that's been a 
problem for (say) XML applications being application/... or text/...

A common default fragment identifier syntax is less obviously independent - as 
noted, there's a proposal for this in the TAG web packaging note.  The app: 
scheme addresses access to archive contents from a different start point and in 
a different way, with which I think any common fragment syntax should aim to 
provide a route to interoperability.  I don't see any conflict with the Research 
Objects work.  There would be some overlap (but not conflict that I can see) 
with aspects of the ResourceSync specification,

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Mon, 27 Oct 2014 12:19:22 +0000

Contrary to what I claimed in my previous email, I see the issue of packaged 
content *is* still live in the W3C TAG.  This call for consensus to publish a 
TAG first public working draft which, if agreed, "the group sends a signal to 
the community to begin reviewing the document":

   http://lists.w3.org/Archives/Public/www-tag/2014Oct/0109.html

I also note that this appears to a joint action between the W3C TAG and Web 
Applications working group.

#g
--