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 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. co-chair-modeIn 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./co-chair-mode +1 to what Bob said. -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: 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
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
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: 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, 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: 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: 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, 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 link 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, 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: 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: 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: 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. entry x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry 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: 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: 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/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/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/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, 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/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, 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 feed xmlns=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/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: 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, 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: 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: 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: 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: 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: 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: 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: 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 1:51 PM, Tim Bray [EMAIL PROTECTED] wrote: OK, I observe a lot of people speaking up for link-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 link. 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: 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: 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
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 ietf-announce@ietf.org Cc: Internet Architecture Board iab@iab.org, RFC Editor rfc-editor@rfc-editor.org The IESG has approved the following document: - 'The 'tag' URI scheme ' draft-kindberg-tag-uri-07.txt 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: 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: [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: dereferencability of link?
On Sun, 06 Feb 2005 16:21:25 +1100, Eric Scheid [EMAIL PROTECTED] wrote: consider link href=tag:example.com,2005:/2005/02/musings / 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: 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: 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: 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: atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name Well yes, and there's always: atom 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 ... /atom 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: 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
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: 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
PaceFormatSecurity
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: 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: 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: 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: 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: 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: 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: 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: 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: PaceFeedState
On Wed, 24 Nov 2004 08:09:26 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: Hi Joe, I think a simple link rel=prev/ 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
