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
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
.
Thanks,
--
John
Panzer
System Architect
http://abstractioneer.org
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.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the
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.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the
]]
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 5 Dec 2006
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 View [1
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 that
. 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
(9 results)
--
John Panzer
System Architect, AOL
http://abstractioneer.org
+1 to removing the MUST.
+0 to changing it to SHOULD.
Tim Bray wrote:
co-chair-mode
Please see the dialogue below.
/co-chair-mode
(Eric's point seems plausible to me; personally I'd be inclined to a
+1.)
co-chair-mode
Can we have some feedback from the WG ASAP? We want to take
[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 additional
copying rights
, 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
content is allowable, if the
feed provider adds a license, it is still allowable.
-John Panzer
(I'm deliberately picking a GIF picture as I believe there's no good
solution for embedding license metadata inside GIFs. )
-John Panzer
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
underpinning is one of the things that's necessary here.
--
John Panzer
System Architect, AOL
http://abstractioneer.org
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 small
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
e only" feed is an "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
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
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
producers.
Thoughts?
On 6/6/06, John Panzer [EMAIL PROTECTED] wrote:
All,
Some sites offer two versions of feeds; one is a 'headline only
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
--
John Panzer
System Architect, AOL
http://abstractioneer.org
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.
ractioneer/atom.xml
Thanks,
--
John
Panzer
System Architect
http://abstractioneer.org
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
...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
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. This draft should now be considered complete
, that would mean that you would end up
distributing my content under a different license than what I had
originally intended, which you, of course, have no right to do.
Therefore, entries are licensed independently of the feeds in which they
happen to appear.
- James
John Panzer wrote
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
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 input
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 this client dependent so
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 not to
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
.
John Panzer wrote:
(1) All links from within feeds go to a
resource of type "application/atom+xml".
(2) Header links (link rel...) in web pages to to a resource
as in #1.
(3) Feed links displayed in web pages, which a user in a web browser
might click on, go to a resour
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
+1 to ship it.
--
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer
of the 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
type is authoritative.
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
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
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 for MIME
.
--
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:
feed xmlns=http://...atom;
...
entry
titlethe minimal Atom Entry/title
summaryA minimal entry has only .../summary
content type=application/atom+xml
entry
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
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
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
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
-1 to the Pace. The current syntax sufficiently meets the 'support for
archives' charter, and extensions are possible.
-John
+1. Low cost, good benefits for interoperability.
NOT contain more than one atom:link element
with a rel attribute value of alternate that has the same type
attribute value.
[1] http://danja.typepad.com/uncooked/2005/01/life_the_univer.html
--
http://dannyayers.com
--
John Panzer | Sr Technical Manager, AOL
Blog
55 matches
Mail list logo
