Subject: Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

From: Mark Baker <[email-masked]>
Date: Fri, 17 Jun 2005 10:05:42 -0400

Martin,

> The general idea seems to be that conversion to HTML is good for
> human consumption with a browser, and for human navigation in an
> archive. message/rfc822 is the original, and may be very good for
> reuse in a mailer (e.g. for replying), except that mailers don't
> support it much at the moment.
> 
> <atom:content type="message/rfc822"
> src="http://www.example.org/lists/list/archive/12345"/>

Unfortunately, that's bad Atom.  Section 4.1.3.1 of the format spec
says;

  On the atom:content element, the value of the "type" attribute MAY be
  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

where "composite type" is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the "src" attribute to include the data by reference rather than by
value.

I'm sorry that I didn't notice this earlier. 8-(

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

---

From: Tim Bray <[email-masked]>
Date: Fri, 17 Jun 2005 10:14:38 -0700

Uh, has Mark spotted a dumb bug here that we should fix?  Do we care  
if *remote* content is of a composite MIME type?  My feeling was that  
we ruled out composite types in *local* content, for fairly obvious  
reasons.  The fix is obvious, in 4.1.3.1

"Failing that, it MUST be a MIME media type.  If the "src" attribute  
is not provided, i.e. the content is local, the value of the "type"  
attribute MUST NOT be a composite type... "

-Tim

---

From: James M Snell <[email-masked]>
Date: Fri, 17 Jun 2005 11:01:39 -0700

Appears that way.  +1 to making composite types in remote content legal. 

Another question while we're discussing this part of the spec (stemming 
from the XML Enc discussion):  currently there appears to be no language 
about what should happen if an Atom processor encounters a content media 
type that it doesn't understand.  Should it ignore the content? Does it 
report an error?  Should it try to process the content somehow (e.g. 
defer to some external processor)?

---

From: Eric Scheid <[email-masked]>
Date: Sat, 18 Jun 2005 04:03:37 +1000

> attribute MUST NOT be a composite type... "

+1

---

From: Sam Ruby <[email-masked]>
Date: Fri, 17 Jun 2005 14:16:50 -0400

Tim Bray wrote:
> 
> Uh, has Mark spotted a dumb bug here that we should fix?  Do we care  if 
> *remote* content is of a composite MIME type?  My feeling was that  we 
> ruled out composite types in *local* content, for fairly obvious  
> "Failing that, it MUST be a MIME media type.  If the "src" attribute  is 
> not provided, i.e. the content is local, the value of the "type"  

I have no objection, but I will point out that for the forseeable future 
the number of tools that are likely to support this is likely to be 
vanishingly small.

- Sam Ruby

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 17 Jun 2005 20:56:54 +0200

* James M Snell <[email-masked]> [2005-06-17 20:15]:
> currently there appears to be no language about what should
> happen if an Atom processor encounters a content media type
> that it doesn't understand.  Should it ignore the content? Does
> it report an error?  Should it try to process the content
> somehow (e.g. defer to some external processor)? 

The spec is supposed to explain what the bits means, but not to
tell anyone what to do with them, so there’s nothing it can
really mandate here. Certainly it can’t usefully *enforce*
anything.

This might be something that the implementor’s guide should
contain recommendations for. But even then, I don’t think that
doing more than suggesting a few best practices for a handful
of situations is feasible.

I expect that many newsreaders will simply ignore things they
don’t understand.

Personally, in the aggregator I occasionally work on, I plan to
pass the data to a whatever application the user’s mailcap says
is responsible for it. (I suppose you’d use the registry in
Windows; I don’t know what mechanism OS X provides.)

On the other hand, many scenarios will (hopefully!) involve Atom
feeds intended solely for consumption by machines rather humans.
I imagine that in at least a few of those, unexpected content
types should set off alarms.

So I don’t think there is any one course of action that we can
recommend for everyone; let alone mandate, if such a thing even
was in the scope of the spec. The best we could do is to
informally suggest certain practices for certain situations. (I’d
like to see desktop aggregators widely support what I am planning
to do with mine, f.ex; then putting stuff other than HTML in
feeds would have a chance to catch on.) And that too is probably
something the guide should do, not the spec.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Fri, 17 Jun 2005 12:15:51 -0700

Well, what I'm going for more is an understanding of what should happen 
during parsing.  For example, in Section 5 we dictate that "Atom 
Processors MUST NOT reject an Atom Document containing ... a signature 
because they are not capable of verifying it"... the MOST I think could 
be done in the core spec is a similar statement saying "Atom Processors 
MUST NOT reject an Atom Document containing a content media type that it 
doesn't understand".  Whatever else the processor does with it (e.g. 
ignore it, display a warning to the user, attempt to find an application 
to handle the content, etc) is up to the implementation.

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 17 Jun 2005 23:42:55 +0200

>I'm sorry that I didn't notice this earlier. 8-(

Er, and it seems there's another (related) problem:
In 4.1.3.1:
[
If the type attribute is not provided, Atom Processors MUST behave as 
though it were present with a value of "text".
]
Just below, in 4.1.3.2:
[
If the "src" attribute is present, the "type" attribute SHOULD be 
provided and MUST be a MIME media type [MIMEREG], rather than "text", 
"html", or "xhtml".
]

So what if I provide a "src" attribute but no "type" attribute?
The "type" attribute would "default" to "text", but "text" is forbidden 
if "src" is provided...

I suggest that if src is provided but not type, there is no "type 
value", as this value is just advisory and not authoritative. However, 
if src is not provided (the content is local), processors must "behave 
as though it were present with a value of text".

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Sat, 18 Jun 2005 12:06:22 +1000

+1

---

From: David Powell <[email-masked]>
Date: Sat, 18 Jun 2005 12:50:58 +0100

> -Tim

Can somebody give me a link to where we discussed the requirement that
atom:content MUST NOT contain a composite type? I've tried searching my
archive but I couldn't find anything at all. The change was introduced
in draft-08.

I can't agree that this is a mere spec bug until I can find where it
was discussed, and what the intent for this ban was.

I don't really see why we are banning these MIME types from either
local or remote content.

-- 
Dave

---

From: Sam Ruby <[email-masked]>
Date: Sat, 18 Jun 2005 08:40:52 -0400

> I don't really see why we are banning these MIME types from either

http://www.intertwingly.net/wiki/pie/PaceReformedContent3

- Sam Ruby

---

From: David Powell <[email-masked]>
Date: Sat, 18 Jun 2005 15:39:07 +0100

> http://www.intertwingly.net/wiki/pie/PaceReformedContent3

Thanks, but is that really the same discussion? That proposal was
incorporated into draft-03. The prohibition of "composite types"
wasn't introduced until draft-08.

One of the main effects of PaceReformedContent3 was banning the
Atom-0.3-style "multipart/alternative" envelope that allowed multiple
<content> elements to be embedded.

Fair enough - but I don't see how this is related to the prohibition
of message/* and multipart/*?

Was this a heavy-handed attempt to prevent people from using Atom 0.3-
style alternatives in Atom 1.0, perhaps?

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Sat, 18 Jun 2005 16:00:49 +0100

Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:

> My feeling was that we ruled out composite types in *local* content
> [...]

I'm still looking, but my suspicion is that we never did rule them
out, and that this restriction crept in during some editorial
rephrasing.

> [...] for fairly obvious reasons.

I don't know what the obvious reasons are...

Lack of client support? - hardly seems a reason to ban a MIME type,
else there is a huge list of ones that we should ban at IANA.

We are defining a data format here. If publishers want to publish
entries as text, message/rfc-822, application/msword, image/jp2, or
whatever, then that is up to them. I don't see how we can justify a
MUST NOT requirement for "composite types".

> The fix is obvious, in 4.1.3.1

> attribute MUST NOT be a composite type... "

I'm in favour of replacing:

  "Failing that, it MUST be a MIME media type, but MUST NOT be a
  composite type (see Section 4.2.6 of [MIMEREG])."

with:

  "Failing that, it MUST be a MIME media type."

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sat, 18 Jun 2005 11:40:54 -0400

> out, and that this restriction crept in during some editorial

Incorrect. Multipart content presents an accessibility issue because
the entry metadata is no longer sufficiently granular. There would
have to be Atom metadata for each part.[0]

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg09357.html

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 18 Jun 2005 18:04:19 +0200

* David Powell <[email-masked]> [2005-06-18 17:15]:
> We are defining a data format here. If publishers want to
> publish entries as text, message/rfc-822, application/msword,
> image/jp2, or whatever, then that is up to them. I don't see
> how we can justify a MUST NOT requirement for "composite
> types".

I *do* see a problem with how Atom 0.3 overloaded the MIME type
to mean something completely different than “this is data that
you can feed a MIME envelope parser.”

I *don’t* see why composite types should be banned, rather than
handled the exact same way any other non-XML types are. I can
imagine this is because part of a multipart document could be an
XML document and there should not be a way for people to cheat
their way out of the restrictions on XML media types.

But that is only one of many use cases for envelopes. If that
really is reason enough for a blanket ban, then the other use
cases need to be accomodated somehow. E.g. how do I decompose
a message/rfc-822 in such a way that it can be stored in Atom?
And this mechanism should be explicitly designated in the spec as
the suggested way to deal with composite types. Unless we want
people to stick to RSS(+extension?) for that sort of thing…

Regards,

---

From: Tim Bray <[email-masked]>
Date: Sat, 18 Jun 2005 11:16:50 -0700

> out, and that this restriction crept in during some editorial

<co-chair-mode>I disagree.  Atom 0.3 had explicit built-in support  
for multipart, and there was strong (not rough) consensus support for  
retiring that and replacing it with the language in the current draft.

My recollection of the debate is that it was exclusively focused on  
the problems of multipart in the document, thus I proposed to the WG  
that we did not in fact have consensus of banning it in external  
content; the feedback so far is supportive of the notion that that's  
a bug in the spec.
</co-chair-mode>

---

From: Graham <[email-masked]>
Date: Sat, 18 Jun 2005 20:36:20 +0100

On 17 Jun 2005, at 6:14 pm, Tim Bray wrote:

> Uh, has Mark spotted a dumb bug here that we should fix?  Do we  
> care if *remote* content is of a composite MIME type?  My feeling  
> was that we ruled out composite types in *local* content, for  
> fairly obvious reasons.  The fix is obvious, in 4.1.3.1

I don't think it's a dumb bug. A composite type is more than a single  
piece of content. Using atom:content this way is wrong, since  
conceptually it produces this:

<atom:entry>
   <atom:title>Message Subject<atom:title>
   <atom:author><atom:name>An author</atom:name></atom:author>
   <atom:content>
<!-- Translating the email headers to Atom -->
     <atom:title>Message Subject<atom:title>
     <atom:author><atom:name>An author</atom:name></atom:author>
     <atom:content>Message body</atom:content>
   </atom:content>
</atom:entry>

The better way to do this is to use <atom:link rel="alternate"> to  
reference the messages.

-1 to the proposal, at least for this use case.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Sat, 18 Jun 2005 14:59:51 -0600

>> reasons.  The fix is obvious, in 4.1.3.1
I would have no objection to this, since the spec already creates the 
expectation that remote content will be less widely supported than 
local content.

> The better way to do this is to use <atom:link rel="alternate"> to 
This is certainly a better solution than multipart local content, and 
would hope that people would do remote content this way too unless they 
have a really good reason for multipart remote content.  But I could 
live with allowing multipart remote content if it's really needed in 
some case.

---

From: David Powell <[email-masked]>
Date: Sun, 19 Jun 2005 01:28:29 +0100

> retiring that and replacing it with the language in the current draft.

<process-objection>

I disagree with the co-chair's call.

Yes, the Atom 0.3 "support" for multipart was broken and there was
strong consensus for removing it, as in the text of drafts 03 to 07.

But, there doesn't seem to have been any discussion or consensus
whatsoever for the prohibition of composite MIME types in content,
such as message/*, that was introduced in 08.

In fact the conclusion of the debate that Robert pointed to [1], was
that the types allowed by atom:content remained unrestricted.

</process-objection>

Atom 0.3 multiparts forced a dubious and complex processing model on
everyone wanting to process Atom documents. This problem was solved by
their removal in the 03 to 07 drafts.

The prohibition of composite types in the 08 draft (made many months
later) is something quite different. Composite types don't impose any
change in the processing model of user-agents, they are just blobs
that get passed to a MIME processor; there is no justification for
restricting Atom payloads to a subset of the MIME type space.

The restriction is just arbitrary: it disallows MHTML Word documents
and RFC822 emails, but allows application/msword Word documents and
application/zip.

Let's be clear: composites probably won't be used by bloggers, or
supported by blogging aggregators; but this isn't an excuse for this
explicit blanket ban.

> content; the feedback so far is supportive of the notion that that's  

The earlier debate was on the problems in the 02 draft, which were
solved in the 03 draft. The restriction on the payload of atom:content
made in the 08 draft is a different issue, so the context of the
earlier debate isn't relevant.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09357.html

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Sun, 19 Jun 2005 01:37:15 +0100

> have to be Atom metadata for each part.[0]

A message/rfc822 email or an MHTML document with embedded images isn't
any more or less granular than an HTML document with linked images or
an application/zip file.

The granularity problem came from Atom 0.3 allowing multiple payloads,
this is different from allowing a single composite payload.

The earlier discussion was about the rejection of Atom-0.3's multiple
content elements, and the quirky multipart/alternative thing for
nesting content elements.

The conclusion was to reject multiple atom:content elements, and to
require text or html in text fields such as title and summary, leaving
atom:content unrestricted.

Placing a restriction on the MIME types that can be contained as the
payload of atom:content is contrary to the earlier conclusion.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sun, 19 Jun 2005 00:07:01 -0400

On 6/18/05, David Powell <[email-masked]> wrote:
> ...
> later) ....

Um, no. One of the drafts reworded the requirement in terms of the new
MIME draft. Previously, the draft cited RFC2045's "discrete type".
From format-03:

"Failing that, it MUST be a MIME media type [RFC2045] in which, to use
the terminology of Section 5 of [RFC2045], the top level is a discrete
type."

We had to, you know, make an editorial change because the new MIME
draft doesn't use the term "discrete type" anymore.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Sat, 18 Jun 2005 22:43:36 -0600

On Saturday, June 18, 2005, at 06:28  PM, David Powell wrote:
> later) is something quite different.
I haven't combed through the archives for messages to support this, but 
had you asked me, I would have thought that we had explicitly decided 
to disallow composite types, not just to get rid of 0.3's multipart 
stuff.

> Composite types don't impose any
Not all user-agents have a "MIME processor".  Given the potential 
complexity and messiness of composite types, I'm opposed to leaving the 
door open for them, since they won't, I think, be needed by a 
significant proportion of Atom users. This brings back bad memories of 
some really ugly data I saw coming out of Cyber Dog when I was working 
on Claris Emailer (Japanese)--a very convoluted and in fact buggy mess 
of multipart/alternative and multipart/mixed with lots of duplicated 
data which forced us to handle composite types incorrectly to avoid 
losing data.  Yes, that's just one anecdote.  But it's an example of 
the kinds of ugliness that can spill over from one bad implementation 
and mess things up for everybody.  Unless there's a use case that meets 
the so-called 80/20 threshold, I'd be in favor of requiring publishers 
to keep things a little simpler within Atom feeds. If somebody really 
needs composite types, they can use an extension, and user-agent 
developers can decide whether to support it.

---

From: David Powell <[email-masked]>
Date: Sun, 19 Jun 2005 08:39:10 +0100

> to disallow composite types, not just to get rid of 0.3's multipart 

As Robert pointed out, it has been in all drafts since 03, only it was
worded differently.  My mistake.

> Not all user-agents have a "MIME processor".

Well they all do something with atom:content. They may choose only to
allow the built in types: text, html, and xhtml to be processed; they
may support a fixed set of additional MIME types: image/jpeg and
image/gif; or they may support all MIME types by handing them off to
another component (eg via an OBJECT tag, or just as a download link).
composite types should be dealt with by processors in exactly the same
way as any other unsupported MIME type.

I'm not suggesting that Atom processors do anything with the
composite, like select alternates or present attachments somehow. They
should just treat it as they would any other exotic MIME type, just
like HTTP does.

It is unlikely that desktop aggregators would do anything special with
composite types, but we aren't defining a protocol for desktop
agregators, we are defining a document format and documenting what it
means so that publishers and subscribers have a shared understanding
of it. Allowing message/rfc822 would not cause any additional
interpretability problems, so it is unsuitable for it to be banned
with a MUST level constraint.

> Given the potential complexity and messiness of composite types, I'm
> opposed to leaving the door open for them, since they won't, I
> think, be needed by a significant proportion of Atom users. This
> brings back bad memories of some really ugly data I saw coming out
> of Cyber Dog when I was working on Claris Emailer (Japanese)--a very
> convoluted and in fact buggy mess of multipart/alternative and
> multipart/mixed with lots of duplicated data which forced us to
> handle composite types incorrectly to avoid losing data. Yes, that's
> just one anecdote. But it's an example of the kinds of ugliness that
> can spill over from one bad implementation and mess things up for
> everybody. Unless there's a use case that meets the so-called 80/20
> threshold, I'd be in favor of requiring publishers to keep things a
> little simpler within Atom feeds. If somebody really needs composite
> types, they can use an extension, and user-agent developers can
> decide whether to support it.

Mail user-agents need to unwrap and process composite types (the one
I'm using now does it in a recursive panels and tabs way which works
quite well).

Atom user-agents don't need to unwrap and process composite types
though. They should just treat them as data. If they don't support
them themselves then they should just treat them as they would if they
saw any other MIME type that they don't support.

As I said in another reply, I'm not too bothered about us banning
multipart/* because they aren't really standalone types, but we really
shouldn't ban publishers from including message/rfc822 data, there
isn't any good reason.

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Sun, 19 Jun 2005 08:36:43 +0100

> draft doesn't use the term "discrete type" anymore.

Ah, thanks. I don't know how I missed that.

OK, process-objection withdrawn, but the problem that Mark highlighted
still exists: Atom prohibits message/rfc822; I don't think that it
should. I'd prefer the solution to be to lift the restriction
completely, than to only lift the restriction for remote content.

It is worth looking what HTTP says about composite types in RFC 2616:

> In general, HTTP treats a multipart message-body no differently than
> any other media type: strictly as payload.

message/rfc822 isn't mentioned at all by HTTP, and is therefore also
treated as just data. It is pretty commonly used too, for both email
(eg: Download from webmail interfaces), and for MHTML content (such as
the format that can be saved by Word 2000 (I think?)).

To be honest, I'm not bothered about mulipart/* being banned. I don't
think that it is particularly useful, but I still don't think that we
need to ban it. What if some really useful multipart/* type gets
defined in future - something on the lines of multipart/appledouble
[1], where the multipart is a blob of content that can be passed to
helper applications as a discrete unit.

message/rfc822 is definitely useful though. There is no reason to ban
it, certainly not with a MUST level constraint. Conceptually it is no
more composite than an application/msword document is composite.

[1] http://www.iana.org/assignments/media-types/multipart/appledouble

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 19 Jun 2005 14:50:44 +0200

* Antone Roundy <[email-masked]> [2005-06-19 06:55]:
> Not all user-agents have a "MIME processor".  Given the
> potential complexity and messiness of composite types, I'm
> think, be needed by a significant proportion of Atom users.

Neither will all user agents have a Zip or tar decompressor.
Shouldn’t we ban application/x-tar and application/zip? What
about MSWord documents with embedded images and OLE objects?
Or PDF documents with images? All of these are conceptually
compound documents, and all of these are likely not to be
processible by most user agents. Shouldn’t these MIME types be
banned as well then?

On the other hand, some automated consumers that use Atom for
something completely different from content syndication, like
maybe logging agents, might not even have any support for
@type=('text','html','xhtml') at the application level, instead
only supporting some form of specific XML envelope document or
maybe a binary blob.

If someone wants to use Atom as an archival format for mailing
lists, and wants to stick message/rfc-822 into the atom:content,
why should the spec stop him?

If someone wants to use Atom as an envelope format for machine
consumption in a company-internal application, and he wants to
push multipart/* around, and he has control of the consumers and
can endow them with a MIME parser – then why should the Atom
format spec stop him?

Of course, the spec is not really stopping him as long as he has
control of all the end points, in which case he can just send
application/octet-stream, and can assume that his feed producers
mean something more specific than “non-descript blob of data” and
that his feed consumers know what to do about it – so instead of
stopping him, the spec has just made him put junk data in his
documents.

I think we’re shooting/have shot ourselves in the foot with this
restriction by disallowing a range of applications that could
have benefitted from Atom but won’t.

> This brings back bad memories of some really ugly data I saw
> coming out of Cyber Dog when I was working on Claris Emailer
> (Japanese)--a very convoluted and in fact buggy mess of
> multipart/alternative and multipart/mixed with lots of
> duplicated data which forced us to handle composite types
> incorrectly to avoid losing data.

How is that relevant? An Atom processor is not a mailer. It is
under no obligation whatesoever to treat a multipart/* or
message/* payload any differently from application/octet-stream.

Composite types should impose no particular duties upon the Atom
processor itself. If the application attached to it which
receives these payloads from the processor knows what to do with
multipart/*, then great. But if it doesn’t, then the Atom
processor certainly won’t care one way or the other.

Funnily enough, that’s exactly the same treatment that any other
known or unknown MIME type receives.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 19 Jun 2005 14:51:55 +0200

* Graham <[email-masked]> [2005-06-18 21:50]:
> The better way to do this is to use <atom:link rel="alternate">
> to reference the messages.

Is there any verbiage that would preclude a data: URI with a
multipart payload in atom:link?

Regards,

---

From: David Nesting <[email-masked]>
Date: Sun, 19 Jun 2005 16:40:32 -0500

> significant proportion of Atom users. This brings back bad memories of 

But is it really necessary to FORBID using Atom for purposes that might
entail using these media types?

What exactly is the prohibition trying to prevent?

If it's trying to prohibit anything except what the most common Atom
processors are likely to understand, then we should eliminate the ability
to specify arbitrary media types entirely and stick with the most common
Atom uses we've already specified.

If it's trying to prevent compound documents of any kind, while still
allowing flexibility in selecting an appropriate "single-part" media type
based on the application, then it needs to do that better.  Currently it
forbids compound media types but allows other more widely used and less
widely known methods for including compound objects into the content.

If it's trying simply to prevent the use of one class of media types
for reasons not mentioned above, then I think it would help everyone to
have that reason documented.

At this point, I'm with the other posters in that this seems like an
artificial constraint in the absense of more meaningful verbiage.

> and mess things up for everybody.  Unless there's a use case that meets 

Perhaps a SHOULD-level requirement should be introduced to encourage
implementers to avoid multipart types since they will be unlikely to
be widely supported.  Maybe this should be a SHOULD-level prohibition
on using arbitrary media types entirely.  People SHOULD stick with the
text/html/xml pseudo-types we've explicitly defined unless they have a
good reason to use something else.

> developers can decide whether to support it.

This seems a little much for an extension.  Specification of a piece of
content is pretty fundamental to Atom.  If I have to do that through
an extension of my own devising, I have to wonder what I'm gaining by
starting with Atom in the first place.

David

-- 
 == David Nesting WL7RO Fastolfe [email-masked] http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01