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
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
* 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.
* 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/
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
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
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
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
* 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
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
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
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
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
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
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
* 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
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
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
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
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
20 matches
Mail list logo
