Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Sunday, June 19, 2005, 5:43:36 AM, Antone Roundy wrote: On Saturday, June 18, 2005, at 06:28 PM, David Powell wrote: 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. 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. As Robert pointed out, it has been in all drafts since 03, only it was worded differently. My mistake. 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. 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Sunday, June 19, 2005, 5:07:01 AM, you wrote: The prohibition of composite types in the 08 draft (made many months 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. 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
* Antone Roundy [EMAIL PROTECTED] [2005-06-19 06:55]:
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.
Neither will all user agents have a Zip or tar decompressor.
Shouldnt 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. Shouldnt 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 were shooting/have shot ourselves in the foot with this
restriction by disallowing a range of applications that could
have benefitted from Atom but wont.
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 doesnt, then the Atom
processor certainly wont care one way or the other.
Funnily enough, thats exactly the same treatment that any other
known or unknown MIME type receives.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
* Graham [EMAIL PROTECTED] [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, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On Sat, Jun 18, 2005 at 10:43:36PM -0600, Antone Roundy wrote: 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 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. 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 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. 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. 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 PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Friday, June 17, 2005, 6:14:38 PM, you 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 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 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Saturday, June 18, 2005, 1:40:52 PM, Sam Ruby wrote: 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. 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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 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... 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
* David Powell [EMAIL PROTECTED] [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 *dont* 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, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On Jun 18, 2005, at 8:00 AM, David Powell wrote: 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. co-chair-modeI 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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:titleMessage Subjectatom:title atom:authoratom:nameAn author/atom:name/atom:author atom:content !-- Translating the email headers to Atom -- atom:titleMessage Subjectatom:title atom:authoratom:nameAn author/atom:name/atom:author atom:contentMessage 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On Saturday, June 18, 2005, at 01:36 PM, Graham wrote: 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 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 reference the messages. 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.
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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 On Jun 17, 2005, at 7:05 AM, Mark Baker wrote: 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.
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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)? 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 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 On Jun 17, 2005, at 7:05 AM, Mark Baker wrote: 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.
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
* James M Snell [EMAIL PROTECTED] [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 theres nothing it can really mandate here. Certainly it cant usefully *enforce* anything. This might be something that the implementors guide should contain recommendations for. But even then, I dont 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 dont understand. Personally, in the aggregator I occasionally work on, I plan to pass the data to a whatever application the users mailcap says is responsible for it. (I suppose youd use the registry in Windows; I dont 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 dont 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. (Id 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/
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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. A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [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 theres nothing it can really mandate here. Certainly it cant usefully *enforce* anything. This might be something that the implementors guide should contain recommendations for. But even then, I dont 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 dont understand. Personally, in the aggregator I occasionally work on, I plan to pass the data to a whatever application the users mailcap says is responsible for it. (I suppose youd use the registry in Windows; I dont 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 dont 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. (Id 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,
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Mark Baker wrote: 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-( 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
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
On 18/6/05 7:42 AM, Thomas Broyer [EMAIL PROTECTED] wrote: 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. +1
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Hello Andreas, There was quite some discussion between Keith Moore and me and a few others about how to serve email in the context of draft-duerst-archived-at-XX. See e.g. http://www.imc.org/ietf-822/mail-archive/msg05486.html and many older threads in the same archive. 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/ looks perfectly okay to me if that's what you want to do. The average atom software may have difficulties treating the message in a good way, but special applications could do very interesting things with it. If the spec prohibits it, that should maybe be fixed in the long term. To show that there are good uses for it, and working implementations, is the best start in that direction. Regards,Martin. At 10:19 05/06/09, Andreas Sewe wrote: I have a question regarding a specific Atom use case: What is the preferred way to set up an Atom feed listing the contents of a mailing list's archive, given that composite media types (in particular message/rfc822) are disallowed for atom:content's type attribute? This prevents me from doing something like the following, serving the archived mails as-is via HTTP: atom:content type=message/rfc822 src=http://www.example.org/lists/list/archive/12345/ But then again there might be something more fundamentally wrong with serving mails as message/rfc822 via HTTP than I currently realize -- and I should better serve the mails as text/plain or convert them to HTML first (which is the way the atom-syntax archive works). Nevertheless, any advice on this issue would be greatly appreciated. Regards, Andreas Sewe
