Re: I-D ACTION:draft-ietf-atompub-format-09.txt

2005-06-10 Thread Graham 


On 8 Jun 2005, at 9:59 pm, Antone Roundy wrote:


  atom:content MAY have a "src" attribute, whose value MUST be an IRI
   reference [RFC3987].  If the "src" attribute is present,  
atom:content

   MUST be empty.  Atom Processors MAY use the IRI to retrieve the
   content, and MAY NOT process or present remote content in the same
   manner as local content.

It took me a second to realize that MAY NOT means "don't have to"  
rather than "aren't allowed to".  The technical meaning of the  
terms is perfectly clear, but it's quite different from the usual  
meaning of those words, and may be misunderstood.  It might be  
better to say "Atom Processors MAY use the IRI to retrieve the  
content, and MAY process or present remote content in a different  
manner from local content."


+1

"and MAY process or present remote content in a different manner to  
local content"


Graham

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

2005-06-10 Thread Martin Duerst 


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.

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:

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