Re: I-D ACTION:draft-ietf-atompub-protocol-13.txt
On 2/13/07, Julian Reschke <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] schrieb: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > ... Hmmm, didn't we have agreement to change 'application/atomserv+xml' to 'application/atomsvc+xml'? A consensus call was asked for [1] but I didn't receive one from the chairs, even after asking off-list, so I left it unchanged. [1] http://www.imc.org/atom-protocol/mail-archive/msg07457.html Sorry, -joe -- Joe Gregoriohttp://bitworking.org
Re: Fwd: Atom format interpretation question
On 1/5/07, Bob Wyman <[EMAIL PROTECTED]> wrote: On 1/4/07, James M Snell <[EMAIL PROTECTED]> wrote: > If the NewsML folks want to be able to use a proper > mediatype to identify their stuff AND treat it as XML, > they should come upwith an appropriate media type > registration (e.g.application/newsml+xml, etc). Did the "+xml" convention ever get formalized in some RFC? I know we all *think* that tacking "+xml" onto the end of something means that it is some use of XML, however, if I remember correctly, this little bit of syntax has never actually been formalized... Or have I missed something? Is there an RFC that defines what "+xml" means? http://www.ietf.org/rfc/rfc3023.txt ""This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities."" -joe -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/15/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used "AtomFu" client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. Other users running "AtomFu" will see that information and nobody else needs to upgrade -- not servers, not other clients. Eventually if other clients see this as a useful feature they'll make the additional markup visible. Servers probably would never need to upgrade to use or touch that markup. A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. I do not see the ability of clients to unilaterally extend the APP using XML as a requirement. But implementors of client software are innovative, too. You can't stop them from putting cool information in entries -- they'll just put it in a place where the server decides it's just natural-language or some other component that it does allow the client to create unmodified. So maybe instead of seeing track name, album and artist in XML elements, we'll see them in square brackets or some other format in the blog entry "text". You say that as if it's a bad thing. Personally I like microformats. And besides, just because *your* client stuffs a track name, album and artist into some XML does not automatically make it interoperable; every client can, and will, choose to encode that data differently. This will hurt interoperability to a certain extent, as there is no standard way of extending the machine-parsable information within the *text* of an entry. See microformats. It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Like I stated previously, this has been discussed ad infinitum on the list and the consensus supports it. -joe -- Joe Gregoriohttp://bitworking.org
Re: Atom Entry Documents
On 12/10/06, James M Snell <[EMAIL PROTECTED]> wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D this week. Please let me know which of the two approaches below y'all prefer... Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: Atom Entry docs
On 12/14/06, Tim Bray <[EMAIL PROTECTED]> 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 option. If a few people were to put up their hands and say "yeah what Bob said" your co-chairs would probably do a hasty consensus grab. +1 to what Bob said. -joe -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/14/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. "Well, the spec doesn't require me to accept link relations which point to other servers." Finger-pointing rather than interoperability. Older versions of the spec had this wording: http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3 "This RFC does not specify the form of the URIs that are used. The URI space of each server is controlled, as defined by HTTP, by the server alone. What this RFC does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files." Something along those lines could be added back in. Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. This happens *all the time* in the real world. Many blog comment systems have 'Preview' buttons. Why? Because you never know how the server is going to handle your text. Yes, it might be nice, in the future, to add a way for a server to advertise its capabilities, but we do not have the real world experience with the protocol to know what that should look like. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. I'm sorry but we've already argued this to death on the list and there is nothing in HTTP which supports that view [1]. We've even reviewed the scenario you are talking about and came to the opposite conclusion: http://www.imc.org/atom-protocol/mail-archive/msg05415.html This is the documented consensus of the WG. The next draft will have verbage that makes this position clearer. If some implementations find that too loose and want octet-for-octet storage they can use always WebDAV. [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/14/06, Sam Ruby <[EMAIL PROTECTED]> wrote: I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. http://www.imc.org/atom-protocol/mail-archive/msg05425.html In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
for). This so that my blog editing tool can show me not only all the entries and media resources (all discoverable from the introspection doc already) but also where the blog is published, so that I can copy that link to my friends when telling them about my blog. Extensions When the client puts extension elements in a MER, MUST the server store those unrecognized extension elements? No. I think the answer to this is actually that servers often do not and should not be required to do so. That makes it hard for clients to extend AtomPub's syntax in ways that other clients will understand but servers don't care about. Consider the consequences: when some enterprising client developer decides to do something cool and useful and encounters servers that don't store their metadata in the obvious place, the client developer is going to quickly work around that by storing in some unobvious place. For example in HTML comments in the atom entry content, or microformats, etc. Is that all cool? (Aside: an example of clients working around servers like this is that some WebDAV servers in the very early days didn't actually allow clients to PROPPATCH custom properties as the authors clearly intended. Some client wanted to put extra structured information on a resource when it was locked. Instead of putting it in properties, since that didn't work reliably, the client instead put it in the LOCK entry's "owner" element! Of course that didn't reliably interoperate either because some servers overwrote the "owner" element with authoritative information -- the lock's actual owner as known by the server. So the workaround solution was also harmful to interoperability, only it was discovered after the client had shipped.) Workspaces What are workspaces? I would like to see a definition. I believe I understand that basically, a workspace corresponds to a single published feed; that a workspace contains the collections with the content authored for that feed. I know the WG discussed this so maybe I can suggest wording at some point or simply register my vote for saying what it *is*. I'll make you a deal, you define what a "web site" is and then I'll define a workspace :) I think this is murky sematic territory best handled by the W3C TAG. Besides the definition, I also wonder about workspace titles. That seems redundant with the title of the entry collection and possibly also the title of the feed (inside the main feed document). Is there any understanding of some of these values being identical, or any understanding of what different purpose they serve if they're not identical? OPTIONS response HTTP is unclear about where PUT and POST show up in Allow headers. WebDAV ran into this as an interoperability problem -- some clients assumed that if they didn't see PUT in the Allow header for a collection, they couldn't write to that collection (the client might be checking for permissions or policy, having already established that the server was a WebDAV server but not certain if PUT would be allowed to this particular place). Some servers had PUT in the Allow header value for a collection, some servers didn't, based on the literal reading that you couldn't actually PUT straight to a collection URL. Clients had to end up with the OPTIONS Allow: header response being useless in this case. With somebody else's hindsight, Atom doesn't have to leave this ambiguous for the special kinds of resources it defines... Cookie support, sessions, authentication Is there an assumption that clients MUST support cookies? without such a requirement explicitly stated, some clients won't, for reasonable security concerns. Instead, is there an assumption that clients MUST repeat authentication headers with each request? Or will servers effectively end up constantly "reminding" clients (through 401 errors) to authenticate? This might seem obvious but it definitely differs from regular HTTP practice where clients authenticate once and then stop sending authentication information automatically and it just works because of cookies. Also we'd experienced this as an interoperability problem in WebDAV interoperability tests where some server implementors insisted that certain WebDAV clients were completely broken in not supporting cookies. Are there assumptions that sessions will be maintained through persistent connections? I believe there should be none. That is, if you're a client implementor thinking that the first request will contain authorization and subsequent requests on the same connection have no authorization, think again. I've stated my piece on authentication and the IETF requirements. Just let me know the boiler plate that needs to be put in there and i'll do it. I have no more energy for the subject. ANCHOR sections It's not clear to me that the RFC Editor will know what to do with all the [[anchor... ]] sections. Most difficult of all, "anchor37" says "incomplete section". For the rest, sometimes the RFC Editor may need to know what to replace with what on publication. I'm sure the doc editors know what they meant but I personally was left guessing. Agreed, will clean up. Lisa Thanks again for the close reading. -joe -- Joe Gregoriohttp://bitworking.org
Re: Searching for Atom-enabled code
How dare you slight my favorite language :) http://google.com/codesearch?hl=en&lr=&q=lang%3Apython+application%2Fatom%5C%2Bxml&btnG=Search (100 results) Python -joe On 10/5/06, John Panzer <[EMAIL PROTECTED]> wrote: Using Google codesearch: Java: http://google.com/codesearch?hl=en&lr=&q=lang%3Ajava+application%2Fatom%5C%2Bxml&btnG=Search (50 results) C++: http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%2B%2B+application%2Fatom%5C%2Bxml&btnG=Search (10 results) Ruby: http://google.com/codesearch?hl=en&lr=&q=lang%3Aruby+application%2Fatom%5C%2Bxml&btnG=Search (50 results) Perl: http://google.com/codesearch?hl=en&lr=&q=lang%3Aperl+application%2Fatom%5C%2Bxml&btnG=Search (100 results) C#: http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%23+application%2Fatom%5C%2Bxml&btnG=Search (9 results) -- John Panzer System Architect, AOL http://abstractioneer.org -- Joe Gregoriohttp://bitworking.org
Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
I think Robert is referring to this: http://tinyurl.com/l2uop -joe On 5/18/06, Paul Hoffman <[EMAIL PROTECTED]> wrote: At 1:58 AM +0200 5/19/06, Robert Sayre wrote: >On 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: >> >>This announcement is for a document that will obsolete RFC3548, which is >>referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax >>(RFC4287). > >Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for >a revision. I'm confused. What breaks? --Paul Hoffman, Director --Internet Mail Consortium -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, John Panzer <[EMAIL PROTECTED]> wrote: > > What autodiscovery links should I do on a web page that displays a > single blog entry, like this one? > > http://journals.aol.com/panzerjohn/abstractioneer/entries/1238 Actually on my blog each page has a feed associated with it that is a feed of all the comments on that page. Regardless, the current spec is unambiguous, it points to feeds. If we want it to point to something besides a feed it has to be changed. If we were to change something, one way to disambiguate feeds from entries would be to add a parameter to the mime-type: application/atom+xml; doc=entry -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, Phil Ringnalda <[EMAIL PROTECTED]> wrote:
>
> On 1/19/06, Joe Gregorio <[EMAIL PROTECTED]> wrote:
> > Because rel is a space separated list of link types:
> >
> > http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
> > https://mail.google.com/mail/
> > I.e. the values are all orthogonal.
>
> Though at this point in this discussion, someone is always duty-bound
> to point out that the only use of that HTML actually specifies,
> for stylesheets, treats them as not orthogonal ("alternate stylesheet"
> is not "alternate" and a "stylesheet", it's an
> "alternate-stylesheet"), and further assigns meaning to the presence
> (though not, exactly, the content) of a title attribute.
Marvelous.
Are you suggesting we promulgate that behaviour in
the face of autodiscovery for RSS that already uses
"alternate"?
-joe
--
Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid <[EMAIL PROTECTED]> wrote: > > On 20/1/06 8:08 AM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote: > > > """ > > The purpose of Atom autodiscovery is for clients who know the URI of a > > web page to find the location of that page's associated Atom feed. > > """ > > > > Not an entry but a feed. The autodiscovery is unambiguous on what such > > a link points to. > > Unambiguous? The autodiscovery spec does not outlaw using > [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry > documents. It only says that such links may be used to find Atom Feed > Documents. This is a subtle nuance. That is not a subtle nuance but an incorrect interpretation. By that same logic it does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] to point to an RSS feed, or a PNG. The autodiscovery spec would be the only RFC that defines the behaviour of [EMAIL PROTECTED]/atom+xml,@rel=alternate], and the verbage in the autodiscovery spec is unambiguous about that fact that it is talking about feeds and not entries. -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, James M Snell <[EMAIL PROTECTED]> wrote: > > Why wouldn't this work? > > rel="alternate feed" > rel="alternate entry" > rel="alternate replies" (see [1]) Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel I.e. the values are all orthogonal. -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid <[EMAIL PROTECTED]> wrote: > The existing behaviour is based on the various incarnations of RSS where the > only document type involved are feeds. RFC 4287 introduces a new document > type, the Atom Entry Document, which autodiscovery-01 fails to take into > consideration. That doesn't meet my definition of "well-written". """ The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. """ Not an entry but a feed. The autodiscovery is unambiguous on what such a link points to. Now to match RFC 4287 that 'feed' ought to be 'Feed', but that is a rather minor change. -joe -- Joe Gregoriohttp://bitworking.org
Re: app:updated ordering in Collections
Sorry, that URI should have been: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html -joe On 10/31/05, Joe Gregorio <[EMAIL PROTECTED]> wrote: > The latest draft is -06 and is available here: > > > http://bitworking.org/projects/atom/atomapi/draft-ietf-atompub-protocol-06.html > > Section 9 uses atom:updated for the ordering of collections. > >-joe > > On 10/31/05, Manuzhai <[EMAIL PROTECTED]> wrote: > > > > Hi there, > > > > I'm a bit of a n00b when it comes to this stuff, so please don't slap > > me with a large trout or anything. > > > > As I refactored my custom weblogging engine over the weekend I decided > > to look at supporting the Atom protocol. I thought it was still named > > Atom API, but after I could only find the spec drafts from 2003 on > > atomenabled.org and remembering that I saw something newer I looked > > around some more and I found draft 5 for the atompub spec [1, > > obviously]. So, as I understand it, the Atom API effort was converted > > into a more serious atompub-protocol effort. Point: should this maybe > > be explained somewhere on the atomenabled.org site? Good to know. > > > > Next, I started actually reading the spec. One question I have right > > now, and it might be stupid since I haven't read all of the mailing > > list archives just yet: the spec mentions in the intro of section 8 > > that Collection items are ordered by their app:updated element. I > > wonder: why isn't the atom:updated element used for that? That would > > obviate the need for a Collection-specific app:updated where the Feed > > already uses atom:updated. If app:updated was used because items of > > Generic Collections also need this ordering, it could still be > > mandated that Entry Collections use atom:updated while Generic > > Collections need app:updated. > > > > That may seem like a minor nit, but it just seems, well, illogical. > > > > Hope this is not too stupid, > > > > Manuzhai > > > > [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-05.txt > > > > > > > -- > Joe Gregoriohttp://bitworking.org > -- Joe Gregoriohttp://bitworking.org
Re: app:updated ordering in Collections
The latest draft is -06 and is available here: http://bitworking.org/projects/atom/atomapi/draft-ietf-atompub-protocol-06.html Section 9 uses atom:updated for the ordering of collections. -joe On 10/31/05, Manuzhai <[EMAIL PROTECTED]> wrote: > > Hi there, > > I'm a bit of a n00b when it comes to this stuff, so please don't slap > me with a large trout or anything. > > As I refactored my custom weblogging engine over the weekend I decided > to look at supporting the Atom protocol. I thought it was still named > Atom API, but after I could only find the spec drafts from 2003 on > atomenabled.org and remembering that I saw something newer I looked > around some more and I found draft 5 for the atompub spec [1, > obviously]. So, as I understand it, the Atom API effort was converted > into a more serious atompub-protocol effort. Point: should this maybe > be explained somewhere on the atomenabled.org site? Good to know. > > Next, I started actually reading the spec. One question I have right > now, and it might be stupid since I haven't read all of the mailing > list archives just yet: the spec mentions in the intro of section 8 > that Collection items are ordered by their app:updated element. I > wonder: why isn't the atom:updated element used for that? That would > obviate the need for a Collection-specific app:updated where the Feed > already uses atom:updated. If app:updated was used because items of > Generic Collections also need this ordering, it could still be > mandated that Entry Collections use atom:updated while Generic > Collections need app:updated. > > That may seem like a minor nit, but it just seems, well, illogical. > > Hope this is not too stupid, > > Manuzhai > > [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-05.txt > > -- Joe Gregoriohttp://bitworking.org
Re: Profile links
On 10/24/05, James M Snell <[EMAIL PROTECTED]> wrote: > Joe Gregorio wrote: > > > >I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry > >with (X)HTML, in particular the microformat use of such > >link elements to point at XMDP documents[1]. > > > > -joe > > > >[1] http://www.gmpg.org/xmdp/ > > > > > > > I thought that head[profile='list-o-uris"] was the right approach for > XHTML profiles? Ok, that will teach me to whip out a quick response :) You are correct that it is head[profile='list-o-uris"] and not a link element as my poorly worded message would imply. What I was trying to stress was the pointing at XMDP documents, not so much the link element. -joe -- Joe Gregoriohttp://bitworking.org
Re: Profile links
On 10/22/05, James M Snell <[EMAIL PROTECTED]> wrote: > Hmm.. the more I think about this and the more we discuss it, the less I > think I like link[rel="profile"]. While the URI of the profile > reference should be dereferenceable, most of the time the profile value > is going to be used as an identifier. > > > http://example.com/profiles/weblog > http://example.com/profiles/podcast > I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry with (X)HTML, in particular the microformat use of such link elements to point at XMDP documents[1]. -joe [1] http://www.gmpg.org/xmdp/ -- Joe Gregoriohttp://bitworking.org
Re: General/Specific [was: Feed History / Protocol overlap]
On 10/19/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > Perhaps people could +1/-1 the following options: > > * Reconstructing a feed should use: > a) a specific relation, e.g., "prev-archive" -1 > b) a generic relation, e.g., "previous" +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: Feed History -04
On 10/14/05, Antone Roundy <[EMAIL PROTECTED]> wrote: > > On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote: > > On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote: > >> I have a suggestion that may work. The issue of defining what is > >> "prev" and "next" with respect to a time ordered sequence seems to > >> be a problem. How about defining the link relationships in terms > >> of time - such as "newer" and "older" or something like that. That > >> way, the collection returned should be either "newer" (more recent > >> updated time) or "older" (later updated time) with respect to the > >> current collection doc. > > > > A feed isn't necessarily a time-ordered sequence. Even a feed > > reconstructed using fh:prev (or a similar mechanism) could have its > > constituent parts generated on the fly, e.g., in response to a > > search query. > > > The OpenSearch case mentioned by Thomas is what convinced me that > terms related to temporal ordering aren't appropriate (what a pity, > since "newer" and "older" are the perfect terms for time ordered > sequences of feed documents!) > > "Previous" and "next" suffer from the fact that they could easily be > interpreted differently in different use cases. For example, for > OpenSearch results "pages", clearly "prev" points to the search > results that come up "on top" and "next" to the lower results. But in > a conventional syndication feed, "next" could easily be taken to mean > either "the next batch of entries as you track back towards the > beginning of time from where you started (which is usually going to > be the growing end of the feed)", or "a batch of entries containing > the entries that were published next after the ones in this batch." > I'd have to look at the document to remind myself of which "next" > means, because either makes just as much sense to me. True, but I don't think that means that the terms have to be abandoned, but that these examples need to be supported by spec text. That is, define 'next' as pointing to the next document in a series of documents, the whole series of documents containing a series of Atom Entries whose order is specific to the service providing it. -joe -- Joe Gregoriohttp://bitworking.org
Re: Feed History -04
On 10/13/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > On 14/10/05 9:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote: > > > Excellent. If this works out, there is an opportunity to merge the > > paging behavior of Feed History, OpenSearch and APP collections into a > > single set of paging link relations (next/previous/first/last). > > 'first' or 'start'? > > Do we need to define what 'first' means though? I recall a dissenting > opinion on the wiki that the 'first' entry could be at either end of the > list, which could surprise some. Eric, It's like deja-vu all over again. http://bitworking.org/news/Atom_Auto_Sub_How_To :) -joe -- Joe Gregoriohttp://bitworking.org
Re: Feed History -04
On 10/10/05, James M Snell <[EMAIL PROTECTED]> wrote: > > I've been considering asking the Opensearch folks if they would be > willing to separate their next/previous/first/last link relations out to > a separate spec that could be made a working group draft. The paging > functionality they offer provides a solution to paging in the protocol > and are generally useful across a broad variety of feed application > cases. Regardless, it would be very good to see these registered. +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: Feed History -04
On 10/9/05, Henry Story <[EMAIL PROTECTED]> wrote: > > It occurred to me that I should think a little more before speaking. > > There seems to be a history of the atom spec here: > > http://bitworking.org/projects/atom/ > > I could not find the prev link in any of the specs. So I guess I was > mistaken. It's in there: http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.5.4.1 So -1 to draft-nottingham-atompub-feed-history-04.txt for not using a link tag of rel="prev". -joe -- Joe Gregoriohttp://bitworking.org
Re: AtomPubIssuesList for 2005/09/05
Obviously I'm +1 on PaceSimplifyCollections. I believe something like PaceAppDocuments is needed even if PaceSimplifyCollections is accepted, so +1 with the caveat of it being rewritten to accomodate PaceSimplifyCollections if that pace is accepted. In writing PaceSimplifyCollections I tried to incorporate the work that James and I did on PaceCollectionClasses. I believe PaceSimplifyCollections includes all the functionality of PaceCollectionClasses, please let me know if I am wrong. Thanks, -joe On 9/8/05, James M Snell <[EMAIL PROTECTED]> wrote: > > PaceAppDocuments is generally nothing more than a proposal to rework the > protocol spec so that it's structure and organization is consistent with > the Format spec. That said, there are a couple of new things that it > introduces: > > 1. xml:base in collection documents. If we go with the > PaceSimplifyCollections approach, this may be unnecessary. If we stick > with the current approach, this should be required > 2. xml:lang in collection documents. this should be a no-brainer > > Regarding PaceAppDocuments2 (which I wrote) and PaceCollectionClasses > (put together by Joe and I), I will gladly retract both in favor of the > direction of PaceSimplifyCollections with the caveat that I believe > PaceSimplifyCollections needs quite a bit more work before it is > entirely acceptable. I will post a separate note detailing what I think > needs to be done to fix PaceSimplifyCollections. > > - James > > Sam Ruby wrote: > > >A lot of work is going on in the area of collections - in at least two > >different directions. Depending on which direction we select, a number > >of existing paces may become obsolete. Accordingly, I'm scheduling: > > > > PaceAppDocuments2 > > PaceSimplifyCollections > > > >And the two paces prereqed by PaceAppDocuments2: > > > > PaceAppDocuments > > PaceCollectionClasses > > > >As always, discussion of these paces should occur on the atom protocol > >list, with a subject line identifying which pace you are expressing an > >opinion on. > > > >- Sam Ruby > > > > > > > > > > -- Joe Gregoriohttp://bitworking.org
Re: Don't Aggregrate Me
On 8/29/05, Walter Underwood <[EMAIL PROTECTED]> wrote: > That was me. I think it makes perfect sense as a PI. But I think reuse > via namespaces is oversold. For example, we didn't even try to use > Dublin Core tags in Atom. Speak for yourself :) http://bitworking.org/news/Not_Invented_Here -joe -- Joe Gregoriohttp://bitworking.org
Re: Don't Aggregrate Me
On 8/25/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Up to this point, the vast majority of use cases for Atom feeds is the > traditional syndicated content case. A bunch of content updates that > are designed to be distributed and aggregated within Feed readers or > online aggregators, etc. But with Atom providing a much more flexible > content model that allows for data that may not be suitable for display > within a feed reader or online aggregator, I'm wondering what the best > way would be for a publisher to indicate that a feed should not be > aggregated? > > For example, suppose I build an application that depends on an Atom feed > containing binary content (e.g. a software update feed). I don't really > want aggregators pulling and indexing that feed and attempting to > display it within a traditional feed reader. What can I do? First, on this scenario, I would be inclined to make the firmware an enclosure and not included base64. But I still can see a scenario you might be serving up queries via Atom and those queries could be 'heavy'. There are, of course, several things you could do: 1. Cache the results. 2. Support ETags 3. Support ETags and 'fake' them so that they change only once a day, maybe once a week even. There are undoubtedly others, but the more important part is that your 'do not aggregate' doesn't really solve the problem. I could, for example, take one of your heavy search feeds, convert it to HTML via XSLT and include that via iframe in my home page. *That* traffic is going to be a lot worse than an aggregator subscription and wouldn't fit the definition of 'aggregation'. -joe -- Joe Gregoriohttp://bitworking.org
Re: If you want "Fat Pings" just use Atom!
On 8/22/05, Justin Fletcher <[EMAIL PROTECTED]> wrote: > > On Mon, 22 Aug 2005, Tim Bray wrote: > > > On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: > > > >>> Essentially, LiveJournal is making this data available to anybody who > >>> wishes to access it, without any need to register or to invent a unique > >>> API. > >> > >> Ahh, I had thought this was a more dedicated ping traffic stream. The > >> never ending Atom document makes much more sense now. > > > > It's got another advantage. You connect and ask for the feed. You get > > > > http://www.w3.org/2005/Atom";> > > ... goes on forever > > > > and none of the entry documents need to redeclare the Atom namespace, which > > saves quite a few bytes after the first hundred thousand or so entries. -Tim > > I'm a little confused by all this discussion of never-ending XML > documents, mainly because my understanding is that without the > well-formedness checks the content might as well be free form, and the > elements within the document may rely on parts that have 'yet to arrive'. Not at all: """The "atom:feed" element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed. Its element children consist of metadata elements *followed by* zero or more atom:entry child elements.""" http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.1.1 -joe -- Joe Gregoriohttp://bitworking.org
Re: If you want "Fat Pings" just use Atom!
On 8/22/05, James M Snell <[EMAIL PROTECTED]> wrote: > +1.. this seems a very elegant solution. +1. Indeed both solutions, the never ending feed, and the FF separated entries both have their advantages. The FF separated stream has the advantage of being able to synchronize mid-stream. The never ending feed has the advantage that you are only initializing a SAX parser instance just once. Interestingly enough the FF separated entries method would also work when storing a large quantity of entries in a single flat file where appending an entry needs to be fast. -joe -- Joe Gregoriohttp://bitworking.org
Re: If you want "Fat Pings" just use Atom!
On 8/22/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > Joe Gregorio wrote: > > Why not POST the Atom Entry, ala the Atom Publishing Protocol? > > Essentially, LiveJournal is making this data available to anybody who > wishes to access it, without any need to register or to invent a unique API. Ahh, I had thought this was a more dedicated ping traffic stream. The never ending Atom document makes much more sense now. Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: If you want "Fat Pings" just use Atom!
On 8/21/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > Joe Gregorio wrote: > > Why not POST the Atom Entry, ala the Atom Publishing Protocol? > This would be an excellent idea if what we were talking about was a > low volume site. However, a site like LiveJournal generates hundreds of > updates per minute. Right now, on a Sunday evening, they are updating at the > rate of 349 entries per minute. During peak periods, they generate much more > traffic. Generating 349 POST messages per minute to perhaps 10 or 15 > different services means that they would be pumping out thousands of these > things per minute. It just isn't reasonable. > Using an open TCP/IP socket to carry a stream of Atom Entries > results in much greater efficiencies with much reduced bandwidth and > processing requirements. Why can't you keep that socket open, that is the default behavior for HTTP 1.1. -joe -- Joe Gregoriohttp://bitworking.org
Re: If you want "Fat Pings" just use Atom!
Why not POST the Atom Entry, ala the Atom Publishing Protocol? -joe -- Joe Gregoriohttp://bitworking.org
Re: Finishing up on whitespace in IRIs and dates
On 8/12/05, Walter Underwood <[EMAIL PROTECTED]> wrote: > > --On August 11, 2005 9:04:21 PM -0700 Paul Hoffman <[EMAIL PROTECTED]> wrote: > > > Note that there MUST be no whitespace in a Date construct or in any IRI. > > Some XML-emitting implementations erroneously insert whitespace around > > values by default, and such implementations will emit invalid Atom. > > Nice clear wording. > > +1 with "MUST be no" changed to "MUST NOT be", as suggested by Aristotle. +1 with the MUST NOT change incorporated. -joe -- Joe Gregoriohttp://bitworking.org
Re: spec bug: can we fix for draft-11?
On 8/4/05, Danny Ayers <[EMAIL PROTECTED]> wrote: > I don't really understand why this should be treated any differently > than the numerous other problematic things that could happen if one > doesn't take the spec literally. (I'd suggest spec prose trumps RNG > grammar, as there's a lot of other stuff not expressable in the > grammar). "Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance. A complete schema appears in Appendix B." This is quoted directly from Section 1.3. This whitespace issue is a good illustration of why the schema isn't normative ;) I would vote for leaving the text as is and having the validator give errors on whitespace. We have the same issue with dates and believe they should be flagged likewise, i.e. errors on whitespace. -joe > > But now the issue has been raised, it does seem reasonable to add a > note (assuming the process is ok for that) to the effect that stray > whitespace in content is an error. I can't see how it can be desirable > to allow it (though am not given to lying in the road). > > At the application level we're back to Postel again - publishers > shouldn't pump this stuff out, but liberal clients may find it useful > to trim whitespace from IRI and date fields. But surely that's outside > the scope of the format spec itself. > > Cheers, > Danny. > > -- > > http://dannyayers.com > > -- Joe Gregoriohttp://bitworking.org
Re: Polling Sucks! (was RE: Atom feed synchronization)
On 6/17/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > P.S. Why is this on atom-sytax? Is there a concrete proposal we are > talking about here? Is there likely to be? Were you expecting [atom-syntax] to vanish in a puff of smoke once we have a couple RFCs under our belt? Given the technology, and the participants, I would expect [atom-syntax] to have the longevity of [xml-dev]. -joe -- Joe Gregoriohttp://bitworking.org
Re: Polling Sucks! (was RE: Atom feed synchronization)
On 6/17/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > Joe Gregorio wrote: > > The one thing missing from the analysis is the overhead, and > > practicality, of switching protocols (HTTP to XMPP). > I'm not aware of anything that might be called "overhead." I was referring to switching both the client and server from running HTTP to running XMPP. That may not be practical or even possible for some people. Yes, I understand that you run this right now. Yes, I understand that you run a business doing this right now. Yes, I agree that your solution is one way to solve the problem. Do you agree that 99.99% of all syndication is done via HTTP today and also offering an HTTP based solution would be of value? -joe -- Joe Gregoriohttp://bitworking.org
Re: Polling Sucks! (was RE: Atom feed synchronization)
On 6/17/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > Let's keep Atom as it is now -- without the "first" and "next" tags > and encourage folk who need to keep up with high volume streams to use Atom > over XMPP. -1 Let's keep Atom as it is now explain to folks who need to keep up with high volume streams the two options they have, either streaming over XMPP or "next" links. > Lowered bandwidth utilization, reduced latency and simplicity are > good things. The one thing missing from the analysis is the overhead, and practicality, of switching protocols (HTTP to XMPP). Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: Editorial: rules based on MIME media types in @type attributes
On 5/20/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > > I'd like to raise this up one more time: > http://www.imc.org/atom-syntax/mail-archive/msg14247.html > > Atom defines rules based on MIME media types in @type attributes, and I'm > not sure they are actually accurate... > They also don't explain the actual meaning behind the technical rules. > > In 4.1.3.2: > [ >If the value of type begins with "text/" or ends with "+xml", the >content SHOULD be local; that is to say, no "src" attribute should be >provided. > ] > > Replace with: > [ >If the value of type is a text or XML media type, that is, if it begins >with "text/", is one the XML Media Types [XMLMIME] or ends with "+xml", >the content SHOULD be local; that is to say, no "src" attribute should >be provided. > ] To be completely accurate, the part before the '/' is called the type, the part after the '/' is called the sub-type, so to rephrase your re-phrasing: If the value of is a text or XML media type, that is, if the type component of the mime-type is equal to "text", or if the mime-type is one the XML Media Types [XMLMIME], or the mime-type's sub-type ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided. -joe -- Joe Gregoriohttp://bitworking.org
Re: draft-ietf-atompub-protocol-04.txt
Greg, All excellent observations and comments. My replies are inline. On 5/10/05, Greg Smith <[EMAIL PROTECTED]> wrote: > > In reference to draft-ietf-atompub-protocol-04.txt > > Just a quick readthrough and I have a few comments: > > 4.2 Discovery: good description and "easing" into the > meat of the document. > > 6. Should probably reference "see section > 8.1.1.3.1.1". Good points. I have started an errata page for this draft on the wiki: http://www.intertwingly.net/wiki/pie/ProtocolDraft04Errata > > 6.1 In the table, what does "x" mean? Not allowed? > Seems like it means something else, but not explicitly > stated. > > I'm concerned about the ability of a client, given a > Service Document (whether Autodiscovered or not), to > determine what the Service Document covers. I think > this is where the "entry" and "generic" types are > going, but it seems like it might be advantageous to > tie the Service Document to Content-Types. Suppose I > am a blog hosting service and I allow direct photo, > video, audio, and text blogs. By "direct" I mean I > allow someone to post a photo directly to a photo blog > without any text or metadata in it whatsoever. > > I will probably want a "public" service document that > lists the hrefreadonly links for viewers and a > "private" service document for my posting clients. If > I do this, and then provide a series of collections > within the service document, there is no way to > automatically sort out what kind of content to post to > each of the collections. If I want you to be able to > program "dumb" clients that provide little or no > metadata (like directly from a camera or mp3 recorder > or phone), then it would be nice to provide a "photo" > collection to POST my photos to. > > While we could create a whole series of "entry", > "generic", and other types, it might be better to > consider listing for each collection, the acceptable > Content-Types. > > Right now, it looks like a client has to trial and > error the Content-Types to determine the allowed > Content-Types. It would even be nice to provide a > "preferred" Content-Type for each collection as well, > but I'm not sure that would be necessary. This document is just the 'basic' protocol, where we are describing the basic mechanisms and collection types. We are expecting to produce a further specification that covers editing collections of other types of documents, such as templates, etc. Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: I-D ACTION:draft-ietf-atompub-protocol-04.txt
As usual, the HTML and XML versions are available here: http://bitworking.org/projects/atom/ As an indication of how much has changed from -03 to -04, there are no diffs available, the tool we use to automatically generate the diffs threw up its hands and produced nothing useful. Thanks, -joe On 5/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Atom Publishing Format and Protocol Working > Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : R. Sayre, J. Gregorio > Filename: draft-ietf-atompub-protocol-04.txt > Pages : 36 > Date: 2005-5-10 > > This memo presents a protocol for using XML (Extensible Markup >Language) and HTTP (HyperText Transport Protocol) to edit content. > >The Atom Publishing Protocol is an application-level protocol for >publishing and editing Web resources belonging to periodically >updated websites. The protocol at its core is the HTTP transport of >Atom-formatted representations. The Atom format is documented in the >Atom Syndication Format (draft-ietf-atompub-format-06.txt). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt > > To remove yourself from the I-D Announcement list, send a message to > [EMAIL PROTECTED] with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > [EMAIL PROTECTED] > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > -- Joe Gregoriohttp://bitworking.org
Re: Autodiscovery
On 5/4/05, Robert Sayre <[EMAIL PROTECTED]> wrote: > Mark's draft does an excellent job of documenting that reality. +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: Autodiscovery
On 5/4/05, Robert Sayre <[EMAIL PROTECTED]> wrote: > > On 5/4/05, fantasai <[EMAIL PROTECTED]> wrote: > > > > > Who's to say we can't overload it a little for this case? > > > > You are not writing the HTML 4.01 spec, you're writing an autodiscovery > > spec that takes advantage of the syntax *and semantics* given in HTML 4. > > Your specification should be consistent with HTML 4, not contradictory > > to it. > > The autodiscovery spec is a reasonable interpretation of the *one > line* definition of the 'alternate' relation. It is not contradictory. +1 -- Joe Gregoriohttp://bitworking.org
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Apr 11, 2005 3:23 PM, Norman Walsh <[EMAIL PROTECTED]> wrote: > I don't really want to have to rev the Atom format > spec when XHTML 2.0 comes out. +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: Why is alternate link a MUST?
On Apr 3, 2005 11:59 PM, Robert Sayre <[EMAIL PROTECTED]> wrote: > > Paul Hoffman wrote: > > > > > What is the technical reasons for the SHOULDs and MUSTs? Where is the > > interoperability issues within the protocol (not with readers that don't > > know what the protocol looks like)? What are the potentials for causing > > harm? I'm not saying there are none; I'm saying let's choose our levels > > based on what we are supposed to be choosing from. > > If none of them are MUST, there is no social recourse when tracking down > problems or seeking social understanding. Where did this feed come from? > Who makes alternates? What's this all about? +1 Of course, if [EMAIL PROTECTED] is not the identifier and it falls to atom:id then we may end up having to add more verbage to the spec. For example, today some feeds are full-content, others are abbreviated. If I produce both kinds of feeds, do I use the same atom:id for both? What if one feed is delivered via email and the other via HTTP, should they both use the same atom:id? -joe -- Joe Gregoriohttp://bitworking.org
Re: Why is alternate link a MUST?
On Apr 3, 2005 7:04 PM, Bill de hÓra <[EMAIL PROTECTED]> wrote: > Tim Bray wrote: > > > > On Apr 3, 2005, at 12:45 PM, Graham wrote: > > > >> So do you have an argument here as to why it should be required? All > >> I'm seeing is that it's easy to workaround when the publisher omits it. > > > > > > Agreed. Joe, that wasn't very convincing. I repeat, we've seen several > > very believable use-cases for why someone might want this, and no good > > arguments (that I can remember) that it would break anything. Sam has > > pointed out that no previous version of RSS has done this, which is a > > reasonable argument; except for we have use-cases, and nobody's shown > > that the cost is non-zero. -Tim > > The top level feed stuff doesn't make a lot of sense to me. That > @alternate is mandatory while @self and atom:id are not isn't very > convincing either: > > atom:[EMAIL PROTECTED]'alternate'] : MUST >atom:[EMAIL PROTECTED]'self'] : SHOULD > atom:id : MAY > > You can't have a useful discussion about @alternate without talking > about @self or atom:id. > > Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or > atom:id is lifted to MUST. If either are lifted to must I'm 0 on > downgrading @alternate. At that stage @alternate doesn't matter a whole lot. For me David Nesting's example of an Atom document as an email attachment was the most convincing that @alternate doesn't need to be a MUST. I agree here with Bill and personally prefer to see atom:id lifted to a MUST. -joe -- Joe Gregoriohttp://bitworking.org
Re: Why is alternate link a MUST?
On Apr 3, 2005 1:51 PM, Tim Bray <[EMAIL PROTECTED]> wrote: > > OK, I observe a lot of people speaking up for -less feeds, > presenting some plausible use cases. I observe only Sam speaking up > for retaining the compulsory link. I observe at least one person > speaking up saying "if it's compulsory I'll generate a fake one", which > seems significant to me. > > I'm starting to smell possible consensus; are there more people here > who agree with Sam? If so, speak up. I agree with Sam, +1 to the required . The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not, ala: http://www.rss2html.com/ I can also generate an XSLT sheet that transforms Atom into HTML then use the W3C XLST service to transform an Atom feed into HTML: http://www.w3.org/2001/05/xslt Now the generated HTML may not be optimal but I hope this shows that barrier to generating an HTML 'alternate' is not onerous, and that the link should remain a MUST. Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: Date accuracy
On Fri, 25 Mar 2005 13:47:29 +, Graham <[EMAIL PROTECTED]> wrote: > > There are several RSS feeds out there that have dates where the day is > accurate but the time is always the same (usually 10am for some > reason), regardless of the time of publication, which completely messes > up sorting the day's entries. Currently the Atom spec implies that this > is bad practice by requiring a time, but could we make it explicit? > > Proposal: Add to Date Construct section: > "Date values must have a granularity of one second" The current format of the date has a granularity of one second. Are you requesting that dates SHOULD be *accurate* to the second by whatever process is generating the Atom document? If that is correct, how does adding this restriction increase interop? -joe -- Joe Gregoriohttp://bitworking.org
Re: I-D ACTION:draft-ietf-atompub-protocol-03.txt
The non-normative HTML and XML versions, as well as diffs between -02 and -03 are available here: http://bitworking.org/projects/atom/ Thanks, -joe On Wed, 23 Mar 2005 16:09:50 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Atom Publishing Format and Protocol Working > Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : J. Gregorio, R. Sayre > Filename: draft-ietf-atompub-protocol-03.txt > Pages : 22 > Date: 2005-3-23 > > This memo presents a protocol for using XML (Extensible Markup >Language) and HTTP (HyperText Transport Protocol) to edit content. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-03.txt > > To remove yourself from the I-D Announcement list, send a message to > [EMAIL PROTECTED] with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > [EMAIL PROTECTED] > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > -- Joe Gregoriohttp://bitworking.org
draft-ietf-atompub-format-06 - value of link @rel.
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.2.9
"The value of "rel" MUST be either a name that is non-empty and does
not contain any colon (":") characters, or a IRI [RFC3987]."
Shouldt we explicitly disallow *any* reserved [1] characters?
-joe
[1] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#reserved
--
Joe Gregoriohttp://bitworking.org
Re: s/url/web/
On Thu, 17 Mar 2005 19:38:55 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > Tim Bray wrote: > > > > EDITORIAL: > > > > There are a couple of places where we use "uri" in the markup, > > specifically the "atom:uri" element (3.2.2) and the "uri" attribute of > > "atom:generator" (4.2.5). > > > > In both cases they're not actually URIs, they're IRIs, so the name is > > WRONG, > > Keeping the name atom:uri is exactly what Martin, author of RFC3987 and > PaceIRI, suggested. This is the reason I'm +1 on keeping it 'atom:uri'. -joe -- Joe Gregoriohttp://bitworking.org
Re: xml:base and xml:lang
On Wed, 16 Mar 2005 16:25:29 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > Or maybe what we're really saying is that any *Atom* element may have > an xml:base/xml:lang? -Tim +1 That's how I initially read it, but I see how the current wording could be read to allow xml:base/xml:lang on any element regardless of the namespace the element sits in. -joe -- Joe Gregoriohttp://bitworking.org
The 'tag' URI scheme' to Informational RFC
Just as a point of information to the group, that tag: URI scheme has been approved as an Information RFC. See below. Thanks, -joe -- Forwarded message -- From: The IESG <[EMAIL PROTECTED]> Date: Thu, 24 Feb 2005 11:04:33 -0500 Subject: Document Action: 'The 'tag' URI scheme' to Informational RFC To: IETF-Announce Cc: Internet Architecture Board , RFC Editor The IESG has approved the following document: - 'The 'tag' URI scheme ' as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. Technical Summary The authors propose a "tag" Uniform Resource Identifier (URI) scheme and describe its syntax. Tag URIs (also known as "tags") are designed to be unique across space and time. There is no authoritative resolution mechanism for tag URIs; they may, however, be used as entity identifiers. Working Group Summary This is not the product of a working group, though discussion of it did occur on the [EMAIL PROTECTED] mailing list. Protocol Quality At the 2004URI BoF discussion on the appropriate registration mechanism for URIs came to consensus on a shift to a pure registration model, since attempts to discourage minting of new schemes has not resulted in fewer URI schemes, only in a larger number of unregistered ones. In the absence of a new registration document, new schemes which have been proposed as internet-drafts are being processed with limited review. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Joe Gregoriohttp://bitworking.org
Re: [Fwd: draft-reschke-http-addmember-00]
On Thu, 17 Feb 2005 09:41:55 -0800, Lisa Dusseault <[EMAIL PROTECTED]> wrote: > > > On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote: > > > > > I think What Would Make The World A Better Place is a mechanism that > > generic clients can discover POST service points where they can > > persist new entities. There is nothing wrong with POST, it is just > > that a client cannot discover if and where a server supports that > > feature. > > > > Atom solves this problem by embedding the POST service uri into the > > feed document. That is fine, but > > a) has low reusablity for other protocols/applications > > b) has no usability from the view of a generic client > > Not only that, the Atom approach makes it very difficult for a client > to synchronize a set of items such as a blog in such a way that the > blog can be authored offline and synched with both local changes and > server changes. It might be possible for a specialized Atom client but > certainly not for an out-of-the-box WebDAV client. There is no possibility for a WebDAV client to work with an Atom server, so this comment is rather puzzling. > > That's what concerns me for the feature of adding a new resource and > letting the server choose a location -- it would be nice for a tool > like Sitecopy to still be able to work. I'm using that more and more > to get content to and from sites like ietf.webav.org. While it might be interesting to compare and constrast Atom and WebDAV, please realize the Atom Publishing Protocol was always intended to be a lightweight protocol that did one thing and did it well. -joe -- Joe Gregoriohttp://bitworking.org
Re: TEXT, HTML, and XHTML
On Thu, 17 Feb 2005 12:12:49 -0500, Norman Walsh <[EMAIL PROTECTED]> wrote: > Any chance we could change those attribute values to "text", "html", > and "xhtml"? +1 -joe -- Joe Gregoriohttp://bitworking.org
Re: dereferencability of ?
On Sun, 06 Feb 2005 16:21:25 +1100, Eric Scheid <[EMAIL PROTECTED]> wrote: > > consider > > > > assume for the moment that is a valid scheme > > is that kind of URI something we want to allow in link/@href? I see no problem with the above example. The usage of a URI in no way mandates 'dereferenceability'. -joe -- Joe Gregoriohttp://bitworking.org
Re: Posted PaceEntryOrder (was Entry order)
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > My preference would be something like > > This specification assigns no significance to the order of atom:entry > elements within an Atom Feed Document. Atom Processors MAY present > entries in any order, unless a specific ordering is required by an > extension. > > (I.e., I could come up with the UseLexicalOrdering extension, and > require processors to understand it to use the feed, assuming our > extensibility model supports that, which I very much hope it will). -1 Atom is a Must Ignore format. I would prefer: """The order of atom:entry elements is typically in reverse chronological order, though feeds MAY be constructed with entries in any order, and this specification assigns no significance to the order of atom:entry elements within an Atom Feed Document.""" There is no reason to even mention how the CLIENT presents the order of the entries in this spec. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceRemoveVersionAttr
On Thu, 03 Feb 2005 19:56:32 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: > For me, I'd like the comfort of knowing that a V1.0 feed will continue > to be valid with respect to future versions of the specifications, and > that tools written to consume V1.0 feeds will continue to work with > subsequent versions of the specification. > > RSS 0.9x (including 2.0) is evidence that the former is possible (I can > cite some minor incompatibilities, but these are merely exceptions that > prove the rule). I do believe that the latter is also possible. > > Without ever changing the namespace. +1 And +1 to PaceRemoveVersionAttr, particularly in light of Atom being a Must Understand vocabulary. -- Joe Gregoriohttp://bitworking.org
Re: Format spec vs Protocol spec
On Tue, 01 Feb 2005 22:05:17 +0100, Julian Reschke <[EMAIL PROTECTED]> wrote: > One alternative I'd like to mention is to remove all references to the > protocol spec from the document spec including the service URI > definitions, and to move the latter as extension elements into the > protocol spec. This would essentially de-couple the publication process. +1 -- Joe Gregoriohttp://bitworking.org
Re: PaceExtendingAtom
On Wed, 2 Feb 2005 18:06:53 +0100, Henry Story <[EMAIL PROTECTED]> wrote: > > -1. At least I don't see why there should be limitations at all on > where extensions can appear. > I am for a general must ignore rule. > > On the other hand I think a much more ambitious extension spec would be > one Atom were defined by > something similar to the RELAX NG description we currently have and an > OWL ontology. This would > be helpful and very useful. PaceExtendingAtom as it currently is stated > is restrictive without > being useful. How is PaceExtendingAtom restrictive? It only spells out a Must Ignore policy and nothing else. Am I missing something? -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceRemoveInfoAndHost
+1 On Wed, 02 Feb 2005 13:29:23 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost > > Proposal > --- > Remove atom:info and atom:host from The Atom Syndication Format. > > Remove atom:host > --- > No one seems to like the atom:host element. It doesn't do what its > original proponents wanted and many of its detractors still oppose it. > Design by committee at its worst. > > Remove atom:info > --- > Back when we were arguing about IETF vs. W3C, mnot said "in the IETF, > it's easier to shut down a solo raving loony." In the threads on > atom:info, it seems I am playing the role of solo raving loony. So, > let's have the process take over. > > Robert Sayre > > -- Joe Gregoriohttp://bitworking.org
Re: PaceFormatSecurity to be updated?
On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > 10.1 HTML and XHTML Content > > Text Constructs and atom:content allow the delivery of HTML and XHTML > into a client application. Many elements are considered 'unsafe' in that > they open clients to one or more types of attack. Every Atom Processor > should carefully consider their handling of every type of element when > processing incoming (X)HTML in Atom documents. See the security sections > of RFC 2854 and HTML 4.01 for some guidance on many types of attack. As I've stated before, referencing the security sections of these two documents will not be helpful to an implementer. Also, you have dropped all references to CSS. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceFormatSecurity to be updated?
I had updated PaceFormatSecuruty based on feedback, removing all the proscriptive prose about removing elements and just pointing out potential security problems. -joe -- Joe Gregoriohttp://bitworking.org
Re: atom:host [was: Comments on format-05]
On Tue, 1 Feb 2005 10:58:52 +0100, Danny Ayers <[EMAIL PROTECTED]> wrote: > On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio <[EMAIL PROTECTED]> wrote: > > > Anonymous (from IP: aaa.bbb.ccc.) > > Well yes, and there's always: > > > The title of this feed is "The Stuff" and the first entry it contains > is titled "Hello World" from 1st February, and that has the content > "... > > > What did you end up implementing for the Wiki? I punted and put myself as the author. I will probably go back and change it to use Anonymous as I outlined above. -joe -- Joe Gregoriohttp://bitworking.org
Re: Dereferencing Identity Constructs
On Sun, 30 Jan 2005 22:30:16 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > Paul Hoffman wrote: > > > > At 5:11 PM + 1/30/05, Graham wrote: > >> > >> The content of an Identity construct SHOULD NOT be dereferenced, > >> even when it comes from a > >> normally dereferencable scheme. There is no requirement for the > >> content to represent a URI > >> where a version of the feed or entry may be found. > > > > > > I'm +1 on this, but would be fine if the WG doesn't want to change. > > Graham's wording is more useful to an implementer who wasn't on the > > mailing list last year (or was on and skipped over the permathreads). > > > > Well, it seems silly to use a dereferencable scheme if you don't want > the URI dereferenced. Secondly, I fail to see how dereferencing a URI > would cause interop problems. I disagree with Graham in that someone may come up with a good thing to stick at the resource that an Identity construct points at (the lessons of XML namespaces not withstanding). But I do believe that we need to be explicit about dereferencability, even if it means we state: ""This specification makes no assertions as to the content of any resources pointed to via Identity constructs that come from a dereferencable scheme. In the normal processing of Atom documents the Identity Construct URI is only used in character by character comparisons and does not require the dereferencing of such a URI."" We could go further and state: ""Atom generators should realize that consumers may not always be dedicated Atom parsers and as a matter of course could dereference Identity URIs. As such, Identity Construct URIs MUST be constructed in a manner that dereferencing such URIs MUST NOT cause any ill effects."" But I'm not sure if that belongs in the security section, or if we even skip it completely and just lean on the reference to the security section of RFC 3986. -joe -- Joe Gregoriohttp://bitworking.org
Re: atom:host [was: Comments on format-05]
On Sun, 30 Jan 2005 18:11:56 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > I'm not going to lie down in the road to get rid of atom:host, if there > are a lot of people that want it badly. However, it should be more > completely specified; i.e., some mention in security considerations, > and also, more information about the association. > > Right now, it's just "domain name or network address associated with an > entry's origin." What is that association? It feels very much like > atom:date, when it had a date, but no indication of what the date > represented; i.e., it's just a datatype (in this case, a hostname or ip > address), but no information about *how* it relates to the entry or > feed. I believe atom:host is the long lost descendent of atom:ipaddr, which came from the problem I had implementing Atom on wiki, where the 'author' of an entry can be difficult to pin down and the ip address may be the only information available. If atom:host is what the 'solution' has morphed into, than I'd rather see it dropped. When putting together a feed for a wiki in Atom I could just as easily set the atom:name element to: Anonymous or Anonymous (from IP: aaa.bbb.ccc.) -joe -- Joe Gregoriohttp://bitworking.org
Re: URI canonicalization
On Sun, 30 Jan 2005 14:06:49 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: > > Paraphrasing Tim [1] "I'm definitely -1 on losing 3.5.1, the > canonicalization warning is a hard-won compromise and seems to cause > no-one any pain." > > We discussed this at extreme length, and no new arguments have been > brought forward. Rough consensus does not mean absolute consensus. +1 -joe -- Joe Gregoriohttp://bitworking.org
PaceFormatSecurity Updated
On Sat, 29 Jan 2005 06:06:54 +0100, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote: > On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > > Whereas you could technically get by with warning-by-reference, I think > > that it's OK and fact probably essential to point out that and > >
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 15:55:10 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > Graham wrote: > > > I don't like stuff like: > > "All SCRIPT elements should be stripped from Text Constructs or all > > native > > scripting support of the (X)HTML display engine should be disabled." > > > > I don't think you need to should do any more than outline the threat > > model from each tech. Proscribing how to deal with it is not on, > > especially when they're this drastic. > > Agree w/ Graham. We don't know what kind of relationship the publisher > and consumer have. > > I would strike all the details on HTML, leave the first paragraph, and > refer to the security sections of RFC 2854 and HTML 4.01. Those two references are woefully inadequate, just compare the threats they outline versus the ones I outline in the Pace. If there were a good reference of all the problems that HTML can cause when used in email, *that* would be more in line with what we need, but I was unable to find such a reference myself. Maybe someone else has better google-fu than me. -joe -- Joe Gregoriohttp://bitworking.org
PaceFormatSecurity
of an Atom feed will be processing IRIs, the security concerns for handling IRIs must also be taken into account. See Section 8 of RFC 3987. }}} == Impacts == == Notes == CategoryProposals Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceXhtmlNamespaceDiv posted
On Thu, 27 Jan 2005 13:30:40 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: > As far as the question of CSS and/or elements/tags everywhere, I'd > think that would be a matter for the security considerations section > (protecting against the Raging Platypus, for example). Whatever > restrictions we may pronounce, consumers will still have to include > code to protect against abuses. And these issues apply equally to HTML > as to XHTML. > > I'm not in favor of mandating restrictions, because there are probably > legitimate uses for anything we might try to protect people against. +1, and the same goes for 'id', just leave it as an item for the security considerations. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceAttributesNamespace status
On Tue, 25 Jan 2005 02:57:42 +0100, Henry Story <[EMAIL PROTECTED]> wrote: > The point is to allow a very clear structure for Atom extensibility to > be defined, as > specified by the Atom working group charter. See AtomAsRDF and AtomOWL. > The point > of the exercise is to make this as invisible as possible to anyone > other than those > who need to write extensions. The intention is for this to have minimal > impact on the > spec. So if you don't care about writing or parsing atom extension, > then you need not worry. I was looking for concrete examples beyond RDF, which, as I asserted, can be covered by an XSLT transformation. Since no others have been supplied I'll stick to my -1. -joe > > Henry Story > > On 25 Jan 2005, at 02:25, Joe Gregorio wrote: > > -1 Ick. > > > > The only example given of a case where this may cause others problems > > is RDF, and I thought we were going to have a non-normative Atom -> > > RDF XSLT? Are there other cases I am unaware of? > > > > -joe > > > > On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray <[EMAIL PROTECTED]> > > 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 it adds to the base specification. -Tim > >> > >> > > > > > > -- > > Joe Gregoriohttp://bitworking.org > > > > -- Joe Gregoriohttp://bitworking.org
Re: PaceExtensionConstruct status
On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: > Joe Gregorio wrote: > > +1 to the general Pace, but I would prefer to see > > the 'Simple Extension' dropped. It adds a level of complexity > > that isn't requried. and for no discernable benefit. > > > > For example, the Pace states that " A Simple Extension construct MUST > > NOT have any attributes or child elements." Does that mean that a > > Simple Extension can't use xml:lang? Does a formerly Simple Extension > > become a Structured Extension if it requires internationalization? > > I work best with specific example. How should wfw:comment be handled? As a Structured Extension. Is there a benefit to being a 'Simple Extension' that I am missing? -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceSyntaxGuidelines status
On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote: > > > It reads like more of a guideline than a Pace. Inspecting the format > > for conformance to these guidelines and generating Paces for > > non-conformances seems like a better way to proceed than to actually > > add this text to the spec. > > Actually, take a closer look, I got fooled too it first glance: It's > talking about how *extensions* should use syntax, not how the spec > should. -Tim In that case +1. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceAttributesNamespace status
-1 Ick. The only example given of a case where this may cause others problems is RDF, and I thought we were going to have a non-normative Atom -> RDF XSLT? Are there other cases I am unaware of? -joe On Mon, 24 Jan 2005 16:17:53 -0800, Tim Bray <[EMAIL PROTECTED]> 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 it adds to the base specification. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceExtendingAtom status
+1 for making Atom a 'Must Ignore' language. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: This is the result of a lot of > discussion around "Must Ignore" and has in various drafts received lots > of friendly remarks and suggestions for improvement, which have been > incorporated. Absent some convincing -1s, it probably goes in. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceEnclosuresAndPix status
+1 Should there be a suggested size for images? -joe On Mon, 24 Jan 2005 16:18:00 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: Got no -1's, seems useful, needed > for feature parity with RSS2, will likely go in absent some objections. > -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PacePersonLinks status
-1 If I understand all the Paces correctly, couldn't you get the same effect by including foaf as a Structured Extension of Person? -joe On Mon, 24 Jan 2005 16:17:39 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: Has failed to get anywhere near > enough support to call rough consensus in previous go-arounds. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceFeedLink status
+1 The alternative is that blasted feed:// URI type... -joe On Mon, 24 Jan 2005 16:17:44 -0800, Tim Bray <[EMAIL PROTECTED]> 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 > > -- Joe Gregoriohttp://bitworking.org
Re: PaceMustBeWellFormed status
It's good work but it belongs in a primer or best practices document. -joe On Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: The WG completely failed to > converge to consensus on these issues last time around. Consensus can > still be found here. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceFeedState status
I am +1 on the //atom:head/atom:[EMAIL PROTECTED]'prev'], but -1 on //atom:head/atom:[EMAIL PROTECTED]'wholefeed'] and -1 on any of the verbage that makes demands on clients, for example, "Atom consumers MUST warn users when they do not have the complete state of a feed " -joe On Mon, 24 Jan 2005 16:17:42 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: Like PaceSupersede, this model of > publishing does not (so far) enjoy consensus support. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceSyntaxGuidelines status
It reads like more of a guideline than a Pace. Inspecting the format for conformance to these guidelines and generating Paces for non-conformances seems like a better way to proceed than to actually add this text to the spec. -joe On Mon, 24 Jan 2005 16:17:36 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: Hasn't got enough support so far, > but also has had no opposition we can find. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceExtensionConstruct status
+1 to the general Pace, but I would prefer to see the 'Simple Extension' dropped. It adds a level of complexity that isn't requried. and for no discernable benefit. For example, the Pace states that " A Simple Extension construct MUST NOT have any attributes or child elements." Does that mean that a Simple Extension can't use xml:lang? Does a formerly Simple Extension become a Structured Extension if it requires internationalization? -joe On Mon, 24 Jan 2005 16:17:45 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: This has received no -1s, but also > not a lot of wild enthusiasm. Support at the moment is a bit marginal, > but some +1s from implementors would probably make it a slam-dunk. > -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: PaceEntryDeletion status
-1 Too much of an edge case with no discenable benefit. On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > If there were no further discussion: The earlier discussion for this > was inconclusive. The demand doesn't seem high enough to get it over > the goal line, but if there is a wave of enthusiasm, there didn't seem > to be that much opposition. -Tim > > -- Joe Gregoriohttp://bitworking.org
Re: Feed, know thyself?
On Fri, 14 Jan 2005 12:58:59 -0800, John Panzer <[EMAIL PROTECTED]> wrote: > > Hmmm. Not looking at the spec, but at the feeds we're currently > producting for AOL Journals, our feeds have ...> essentially pointing to themselves, which I yesterday thought was > redundant but perhaps is actually useful. Useful enough to be > mandatory, perhaps? Yes, being mandatory would be helpful: http://bitworking.org/news/Atom_Auto_Sub_How_To -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceMustUnderstandElement
On Thu, 13 Jan 2005 16:16:07 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > On Jan 13, 2005, at 10:36 AM, Tim Bray wrote: > > > +1. > > The other Tim Bray, speaking as co-chair, observes that > PaceMustUnderstandElement is hopelessly dead, with apparently no > support and lots of detractors. Thank you. You may now return to your > regularly scheduled programming. -Tim Yay! I'm glad this goes down with more than me as the lone detractor. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceFeedState
On Wed, 24 Nov 2004 08:09:26 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > Hi Joe, > > > > > I think a simple in the head of a feed which points > > to the 'previous' feed would be all that is required. The client can > > then, at their discretion, keep following 'prev's back until they are > > satisfied. Leave it up to the client what to do with duplicate entry > > id's if it encounters them (but note in the Pace that it could > > happen). > > > > The entire discussion of Feed State Model can be dropped, the heart of > > the Pace being: > [...] > > But I would drop the part about "until it encounters a link to a > > document it already has seen". That may not be a good metric to go by. > > I disagree. If clients have their own criteria for how far back they > should look, or for how they combine the entries they see into a set, > they'll act differently, and consistency is important here. One of the > biggest complaints I have about RSS is that different aggregators have > different concepts of what my feed is. This may be where our point of disagreement hinges on. When I say client I am referring to a much larger range of applications than just 'aggregators'. > By having a well-specified model > of how to reconstruct the feed, as well as a model for what a feed is, > we can assure that all consumers see the same set of entries. > > If we just leave it up to the consumer to decide whether they've seen > all of the entries, they'll use heuristics to do it, and they'll fall > into traps in figuring it out. I'd rather have one algorithm that's > well-tested and known to work. Different aggregators working differently to me isn't such a bad thing. For example, if an item gets updated does the aggregator display the updated item as new? suppress displaying it? display diffs between the versions of the entry? > For example, if a client decides that it's satisfied if the set of > entries is the same as the last time it saw the feed, it won't go and > look one further back. However, what if there were a series of > snapshots that looked like this? > > entry1 > entry2 > entry3 > --- > entry4 > entry5 > entry6 > --- > entry1 > entry2 > entry3 Ok, that veers wildly from what I thought a series of snapshots would look like. I was considering a 'prev' hopping back in time by either week or month. I don't know if the overhead of designing for such a case as you have outlined above is worth the effort. > A client that only saw the first one would look at the last one and > miss the fact that 4,5 and 6 were in the middle. > > Likewise, if we don't say how to combine entries into a set, clients > will use different rules. I actually think we need more guidance here; > e.g., how to detect changed entries. > > > > For example, what if I have my top level feed with the last 10 items > > in it, and each feeds 'prev' link points back to the previous 10 > > entries? That means that if I have 100 entries on my site then I've > > got 9 'prev' links. > > > > http://example.org/feed.cgi?start=100 > > http://example.org/feed.cgi?start=90 > > http://example.org/feed.cgi?start=10 > > > > Now what if I add another entry to my site, 101. Then I have 10 *new* > > 'prev' links: > > > > http://example.org/feed.cgi?start=101 > > http://example.org/feed.cgi?start=91 > > http://example.org/feed.cgi?start=11 > > http://example.org/feed.cgi?start=1 > > > > Not the most efficient mechanism, but certainly plausible and it > > causes problems with your spidering heuristic. > > I agree that this is a problem with the approach I described earlier; > thanks for pointing it out. Rather than take that approach, a "fully > dynamic" server will need to keep a table in this form; > > [ 'snapshot15': ['entry111','entry112'], >'snapshot14': ['entry100' ... 'entry110'], >... > ] > > where each snapshot corresponds to a Feed Document Resource (FDR?). > Once enough entries is added to the most recent snapshot (15 here), > another is created. So, when someone requests the latest feed, it will > get a 'this' of http://www.example.com/feeddb?id=snapshot15 and a > 'prev' of http://www.example.com/feeddb?id=snapshot14. > The part about this that makes me nervous is that this seems to be veering closer to atom protocol stuff and not just syndication. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceFeedState
On Sat, 20 Nov 2004 19:49:19 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > I've made a proposal to fill in the "Managing Feed State" section; > comments / suggestions appreciated. > >http://www.intertwingly.net/wiki/pie/PaceFeedState I like the concept but I believe the Pace goes too far in proscribing client behaviour and also in the complexity of the mechanism. I think a simple in the head of a feed which points to the 'previous' feed would be all that is required. The client can then, at their discretion, keep following 'prev's back until they are satisfied. Leave it up to the client what to do with duplicate entry id's if it encounters them (but note in the Pace that it could happen). The entire discussion of Feed State Model can be dropped, the heart of the Pace being: "To locate previous Atom Feed Documents, consumers can follow the atom:link element in the atom:head with a @rel of "prev", which contains a persistent URI for the previous Atom Feed Document associated with this feed. By following such links progressively backwards and incorporating the changes in each associated Atom Link document, until it encounters a link to a document it already has seen (as identified by the //atom:head/atom:[EMAIL PROTECTED]'this'] element), a consumer can reconstruct the state of a feed reliably." But I would drop the part about "until it encounters a link to a document it already has seen". That may not be a good metric to go by. For example, what if I have my top level feed with the last 10 items in it, and each feeds 'prev' link points back to the previous 10 entries? That means that if I have 100 entries on my site then I've got 9 'prev' links. http://example.org/feed.cgi?start=100 http://example.org/feed.cgi?start=90 http://example.org/feed.cgi?start=10 Now what if I add another entry to my site, 101. Then I have 10 *new* 'prev' links: http://example.org/feed.cgi?start=101 http://example.org/feed.cgi?start=91 http://example.org/feed.cgi?start=11 http://example.org/feed.cgi?start=1 Not the most efficient mechanism, but certainly plausible and it causes problems with your spidering heuristic. Best leave it up to the client. Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: Work Queue Rotation #13
On Tue, 23 Nov 2004 08:09:26 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: > On Monday, November 22, 2004, at 02:10 PM, Tim Bray wrote: > > PaceFieldingLinks: > > * Some positive comments, no -1's > > * Calls for ruling out relative URIs (done) > > * Calls for wording change from Graham based on Cocoa code examples > > didn't get much support. > > * Outstanding calls for language about how rel= values are to be > > compared. A Pace needs to be written if someone cares enough > > * Agreement that if there's consensus on some more rel= values for the > > initial revenue, we should get them in to the format draft, go ahead > > and write Paces. > > ** I believe this has rough consensus and should be accepted. > I'm strongly in favor of accepting this, and writing a Pace to cover > comparison of @rel values. Let's make progress a little at a time > rather than holding back on ANY progress until we've got it perfect. > We've been doing that in some areas for long enough. +1 on the accepting the Pace as is and a big +1 to the sentiment of making progress a little at a time rather than holding back ANY progress until something is perfect. -joe -- Joe Gregoriohttp://bitworking.org
Re: Published extensibility Paces
On Thu, 11 Nov 2004 11:01:31 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > Questions for Joe: > 1. Why do you think this is hard to implement? > 2. Assuming I can persuade you that it's cheap, would you be OK with it > even given the lack of use in SOAP? I thought about this more after we talked about mustUnderstand at XML 2004 and tried to clarify my objection to mustUnderstand. For me it comes down to this: mustUnderstand is a form of validation. For the Atom Format we've already rejected validity constraints and have settled for well-formed documents, and I believe that should hold no matter the validation method, either schema, DTD or mustUnderstand. -joe -- Joe Gregoriohttp://bitworking.org
