I've written this up in a longer post[1]. Quick summary: I'm thinking
that authentication/authorization and RSS/Atom feeds present an ideal
test case for delegation to automated services. How should OpenID be
extended to handle this case? Could we work through a specfic use case
where (say
There were strong suggestions at the time, I think, that this was part
of HTML and should belong to the WHAT-WG.
So is there a WHAT-WG document to look at?
Also, is there a standard way to discover the collection associated with
a feed? (Given that, if there is an IETF or WHAT-WG way to disco
here.
Thanks,
--
John
Panzer
System Architect
http://abstractioneer.org
alternate representation of the HTML document.
Agreed, in an ideal world.
--
John
Panzer
System Architect
http://abstractioneer.org
Tim Bray wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid
breaking those existing implementations which follow the existing RFC's.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter opt
Tim Bray wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid
breaking those existing implementations which follow the existing RFC's.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter opt
EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2006 9:42 PM
To: John Panzer
Cc: Lisa Dusseault; Atom Protocol; Atom
Subject: Re: In San Francisco/Bay Area
I'll be there at 6:30pm then. I imagine people will not be wanting to
stay very late.
Henry
On 28 Nov 2006, at 21:31, John Panzer
wrote:
Any of those would be good for me. Be careful of the deep fried onion
rings at Tied House, though.
Henry Story wrote:
It has been suggested that a good meeting location might be Tied
House in Mountain
So this needs a decision tree:
+1 to having some way to modify type= (either new media type, or
appending ";type=entry", +0 to either)
+1 to application/atom.entry+xml if new media type is used
+1 to doing this outside of APP (but concerned about deprecating...)
My use case: A web page tha
month. Would
anyone in the area be up for a group meeting?
Henry
Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me
--
John
Panzer
System Architect
http://abstractioneer.org
Sylvain Hellegouarch wrote:
Tim Bray wrote:
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author
If I were implementing the server, in this scenario I'd reject the post
with an error messa
en&lr=&q=lang%3Ac%23+application%2Fatom%5C%2Bxml&btnG=Search
(9 results)
--
John Panzer
System Architect, AOL
http://abstractioneer.org
+1 to removing the MUST.
+0 to changing it to SHOULD.
Tim Bray wrote:
Please see the dialogue below.
(Eric's point seems plausible to me; personally I'd be inclined to a
+1.)
Can we have some feedback from the WG ASAP? We want to take
protocol-11 to the IETF.
-Tim
On Sep 26,
engineering, which allows extension while maintaining desirable
invariants (in this case, the ability to what one would naturally expect
to do with a feed).
[1] http://en.wikipedia.org/wiki/Liskov_substitution_principle
-John Panzer
http://abstractioneer.org
[EMAIL PROTECTED] wrote:
Le 7 sept. 06 à 01:29, John Panzer a écrit :
This is a critical point. Without this, implementors cannot safely
ignore licenses they don't understand (falling back to things like
"fair use" if they can't find any licenses that grant additio
;re doing with content is allowable, if the
feed provider adds a license, it is still allowable.
-John Panzer
ntent:
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG
but not to the same content communicated through an indirect link?
"http://example.org/catpicture001.gif"/>
(I'm deliberately picking a GIF picture as I believe there's no good
solution for embedding license metadata inside GIFs. )
-John Panzer
hings we can promote to help do that.
Attempting to deal with people who choose not to play by the rules is a
different, much larger, much less tractable problem. I'm not trying to
tackle that one, though feed licenses might be a building block.
--
John Panzer
System Architect
http://abstractioneer.org
Yes, I intended to refer to James' feed license extension:
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
(James, I think you meant "feed license draft" rather than "feed thread
draft", right? :) )
James M Snell wrote:
I don't want to speak for John, but in the feed t
Elliotte Harold wrote:
John Panzer wrote:
I'm attempting to promote the use of explicit licenses in feeds, and
Creative Commons is one great source of predefined licenses suitable
for the kinds of things that people want to use feeds for today:
Creative Commons only covers a very
ble. A
stable technical underpinning is one of the things that's necessary here.
--
John Panzer
System Architect, AOL
http://abstractioneer.org
James Holderness wrote:
Mark Nottingham wrote:
Our of curiosity, do you know of *any* client applications that
actually support feed paging?
I think most of the use cases for paging have to do with things like
GData, OpenSearch, etc -- i.e., query results. That sort of thing
isn't tar
hat all of the various
distinctions can be properly handled by a single attribute. With this
in mind, it *seems* that given the existing RDF route promoted by
CreativeCommons covers all of the necessary pieces to allow for such
things, this would by far be the best route to promote to content
pr
Mark Nottingham wrote:
I've been talking to a number of people face-to-face about Feed
History and the use cases for it, and I've come to a position where I
believe there are two major use cases out there for putting together
multiple feeds to form one big, virtual feed.
1) So-called "
;alternate"
representation, or perhaps an "index" to the full feed, or perhaps a
new relation (or two) is needed.
Thoughts?
--
John
Panzer
System Architect
http://abstractioneer.org
little value in the 'thr' attributes overall.
- Sylvain
--
John Panzer
System Architect, AOL
http://abstractioneer.org
Experience report: Our implementation of comments for AOL blogs
includes the count information in a proprietary extension
(aj:commentCount), precisely because we need the information for UI
purposes. We've found it useful and we'd like to use a more standard
extension to help enable intero
Robert Sayre wrote:
.. Are there any
WG members left who were around at that phase? I joined right around
then...
*Holds up hand. Shrugs. Goes back to work.*
A. Pagaltzis wrote:
Hi Aleks,
* Aleks Totic <[EMAIL PROTECTED]> [2006-02-23 00:15]:
For authenticated sites, if your login cookies are not there,
you get back a login page. In Thunderbird there is no way to
fill in the login page, as all browsing requests are redirected
to Firefox
my parser impl. The paging works great. However, I
nearly cried when I saw aj:commentCount ;-)
- James
John Panzer wrote:
We just deployed support for [EMAIL PROTECTED]"previous" et al. for AOL
Journals. If anyone has a client that makes use of these links, please
let me
/abstractioneer/atom.xml
Thanks,
--
John
Panzer
System Architect
http://abstractioneer.org
...is Atom: http://code.google.com/apis/gdata/calendar.html
Interesting that Google is leveraging Atom extensively in the "GData"
generic read/write protocols.
The supported authentication scheme is also interesting.
Google Calendar has launched (and there was much rejoicing). It uses
Atom feeds for public calendar information:
http://www.google.com/calendar/feeds/111sesssuutl03vh7c25avs35s%40group.calendar.google.com/public/full
It validates, with a handful of warnings.
They're using some namespaced ext
s in which they
> happen to appear.
>
> - James
>
> John Panzer wrote:
> > I'd like to support this in our products, and I'm curious as to why the
> > feed licence isn't inherited (by default) by the entries within a feed.
> > Seems like this would r
actly the
same licence. It's not a huge issue but if there's a good reason why
this rule is in place it would be good to know.
-John Panzer
James M Snell wrote on 1/27/2006, 4:17 PM:
>
> Just an editorial clean up of the draft. No significant technical
> changes. T
Elliotte Harold wrote:
John Panzer wrote:
All -- I'm starting a discussion about feed licencing which might be
of interest to members of this mailing list, and which will hopefully
help form the technical extensions that AOL uses to deal with feed
licencing. I'd welcome any
nt to this list, I'm
tentatively advocating adopting James Snell's RelLicense extension for
Atom, and looking for equivalent mechanisms for RSS.
Link:
http://journals.aol.com/panzerjohn/abstractioneer/entries/1281
Thanks,
--
John Panzer
System Architect
http://journals.aol.com/panzerjohn/abstractioneer
A. Pagaltzis wrote on 2/1/2006, 1:39 PM:
>
> * John Panzer <[EMAIL PROTECTED]> [2006-01-30 22:05]:
> >This means that users might possibly end up subscribing to
> >something of type application/xml if they copy and paste URL
> >#3... but we could also make
xample!) and only if that fails, offer to download.
John Panzer wrote:
(1) All links from within feeds go to a
resource of type "application/atom+xml".
(2) Header links () in web pages to to a resource
as in #1.
(3) Feed links displayed in web pages, which a user in a web b
Tim Bray wrote:
On Jan 30, 2006, at 8:23 AM, James M Snell wrote:
+1. Serving atom up at application/xml is perfectly acceptable
It is *not*. Atom has a registered Internet media type (application/
atom+xml); using anything else is a bug. -Tim
Here's my 'best effort' suggestion tha
Thomas Broyer wrote:
...
(and if possible click on a link to lead them to the
site's browser-dedicated pages); those people should just use a
rel=nofollow" on the "direct links" to their feeds.
"I don't think that means what you think it means". At least, if you
mean for search engines no
I have a use case where I think the Atom syntax works well, but it's not
an APP scenario.
I want to provide a web service which renders arbitrary (X)HTML content
'safe' for rendering on web pages. This would basically mean applying
an element/attribute whitelist filter and also transforming
To clarify my +1 to "Ship it": At AOL, we are using Atom internally as
a data exchange format (and just converted to 1.0 syntax). We are using
an early version of the introspection document as well, but only for
limited internal use as it's nonstandard and likely to change. When the
dust s
+1 to "ship it".
--
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer
current page,
at best. It's also not unreasonable to want to have a way to find an
individual Atom entry associated with this page. This would intuitively
seem to be a reasonable 'alternate' since it contains the same
information in a different format.
--
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer
oritative.
So implementors who follow HTTP 1.1 content negotiation should be fine,
those who don't will get whatever your default type is. Or should.
--
John Panzer
Sr Technical Manager, AOL
http://journals.aol.com/panzerjohn/abstractioneer
A. Pagaltzis wrote:
* John Panzer <[EMAIL PROTECTED]> [2005-10-13 18:45]:
If I recall, I believe this is because some people wanted to be
able to package multiple pieces of content together in a single
entry, and other people did not want to have to imply a
requirement fo
James Holderness wrote:
A. Pagaltzis wrote:
And deviously, you can inline the image data inside the feed too,
by using a data: URI with one of these methods.
However, shipping blobs around inside a feed is not a bright idea
with the currently common feed use cases.
There's also the probl
if this will not delay things.
--
John Panzer
Sr Technical Manager, AOL
http://journals.aol.com/panzerjohn/abstractioneer
Eric Scheid wrote:
An Atom Entry can have XML content, right...
Consider this example:
http://...atom";>
...
the minimal Atom Entry
A minimal entry has only ...
...
Or perhaps:
Graham wrote:
On 5 May 2005, at 5:38 pm, Eric Scheid wrote:
Many wiki's offer options in displaying their change log with either
most
recent changes only, or all changes. Both models are commonly supported
because some people want to see notifications of all changes, while
others
just want to
I assume an HTTP Expires header for Atom content will work and play well
with caches such as the Google Accelerator
(http://webaccelerator.google.com/). I'd also guess that a syntax-level
tag won't. Is this important?
The HTML solution for people who could not implement Expires: seems to
be
Eric Scheid wrote:
On 2/5/05 1:51 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
I would +1 allowing identical IDs if it was required that the
entries sharing an ID had different sources.
perhaps we need to explain the concept of 'entries' (as resources), as
distinct fro
Regarding the privacy facet: True privacy probably requires access
control, which requires authentication. In fact this is one of the
major use cases for authenticated Atom feeds in AOL Journals.
-John
Nikolas 'Atrus' Coukouma wrote on 4/19/05, 8:50 PM:
>
> Some pertinent quotes from the
subscribe to
without the "self" link inside the data.
--
John Panzer
Sr. Technical Manager, AOL
http://journals.aol.com/panzerjohn/abstractioneer
Bob Wyman wrote:
Henry Story wrote:
Yahoo! search launching a creative commons search engine ... it would be
very helpful if there were a machine readable way to set copyright
policy on entries.
..
So, in summary, let's not go down the DRM path. It is a snake pit
from
+1. Low cost, good benefits for interoperability.
-1 to the Pace. The current syntax sufficiently meets the 'support for
archives' charter, and extensions are possible.
-John
Robert Sayre wrote:
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
We have feed documents. A series of feed documents makes an archive. I
don't see why we
Eric Scheid wrote:
On 7/2/05 8:58 AM, "John Panzer" <[EMAIL PROTECTED]> wrote:
...
I didn't specifically define "set" to be the more limited mathematical
definition. Think dining room set -- a collection of otherwise identical
items (chair
Eric Scheid wrote:
On 7/2/05 6:20 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
In this particular debate, the core issue is "What is a Feed
Document?" I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have said that a Feed Document is "a
re
headaches.
So I'm +1 on picking one and documenting it.
John Panzer
http://journals.aol.com/panzerjohn/abstractioneer
something to live with; but one might
reasonably expect an archive format to be able to archive an entry plus
its comments together, and if it claims to archive historical changes,
to be able to get to a 'state of the site' on demand.
Finally, how does one obtain an archive docume
Tim Bray wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that each adds to the base specification. -Tim
+1.
ad elements MUST contain at least one atom:link element with a
>rel attribute value of "alternate".
>
>atom:head elements MUST NOT contain more than one atom:link element
>with a rel attribute value of "alternate" that has the same type
>a
least one atom:link element with a
>rel attribute value of "alternate".
>
>atom:head elements MUST NOT contain more than one atom:link element
>with a rel attribute value of "alternate" that has the same type
>attribute value.
>
>
66 matches
Mail list logo
