Re: Atom 1.0?
In a message dated 10/05/2005 03:29:16 GMT Daylight Time, [EMAIL PROTECTED] writes: Question: how do we refer to the product of this WG once it has an RFC number? We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3, which is widely enough deployed that it'll be with us for a while. Per WG consensus, an Atom doc has no version stamp. So there'll be no actual spec-based reason to call our product "Atom 1.0". But, we could just go ahead and do it anyhow. Anyone have a better idea? --Tim "Atom 1.0" was the term we (Danny Ayers and I) used to refer forward to the just-about-to-be version of Atom in Beginning RSS Atom Programming. And "Atom 0.3" was the term used to refer to the existing version. Given the existence of that version, and assuming that the intention is still to use the term "Atom" at all (I assume it is) then a version number is essential in my opinion to distinguish the pukka stuff from Atom 0.3. So "Atom 1.0" would get my vote. BTW where did the "WB consensus" of avoiding a version number come from? At first sight that seems a daft idea. It also conveys a hint of immodesty and a lack of foresight as if the WG hadn't envisaged that its work could ever be improved upon, that nobody would ever want to change it. Totally unrealistic in my view. Andrew Watt
Re: PaceFeedIdOrSelf
On 10 May 2005, at 04:23, Antone Roundy wrote: On Monday, May 9, 2005, at 07:52 PM, Eric Scheid wrote: rel=self is in no way a substitute for an identifier Why not? the uri can change. Yes, I acknowledged that a little after why not?. So we have a tradeoff--greater permanence vs. greater resistance to spoofing. In my opinion, protection against spoofing is more valuable, in part because I expect most feed URIs to be stable enough that their changing won't be a significant issue. Also because things like the volume of SPAM that gets sent to me convince me that people WILL exploit atom:id's spoofability to DOS others' entries. I'm open to experience and reasoning to the contrary, but at this point, that's my position. I am starting agree a little hesitantly with that position. For either a feed or an entry there has to be a url that is used to DELETE, PUT, or GET it. These actions being available automatically give clients a handle on the identity of the resource. If the id is just a string to be shoved around with no means of verifying it in this way, making it possible to be spoofed, then all trust in it will vanish and inevitably the role of identity will go to whatever enables actions such as DELETE, PUT and GET. Now perhaps in a p2p world it makes sense to GET a url such as tag:example.org,2003:3.2397 and so that our language is just being open to new protocols. (Can a P2P network allows PUTs and DELETE on such a url?) I say I am agreeing hesitantly, because the idea of having an id that would allow one to move one's feed or entry from one server to another seems very appealing. But perhaps there will be other methods of noting such a move that will be more effective. One such way would be for the old moved url to send http redirects to the new one. One could also choose one's blog service provider by asking for a contract where they agree to provide such a redirect on all one's entries in case one wishes to move. Henry
Re: Atom 1.0?
* Tim Bray [EMAIL PROTECTED] [2005-05-10 04:40]: We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3 there'll be no actual spec-based reason to call our product Atom 1.0. But, we could just go ahead and do it anyhow. +1 for Atom 1.0 since a lot of people have already used that, and given the provenance of Atom 0.3. But it should remain colloquial usage. I would argue that another, probably equally colloquial term should be introduced meanwhile, so that in the long term, the 1.0 disappears from common usage. That would probably work best if this new term includes an otherwise redundant qualifier that people will eventually discard. I am thinking IETF Atom might just fit the bill. Regards, -- Aristotle
Re: PaceFeedIdOrSelf
On 10 May 2005, at 2:12 am, Antone Roundy wrote: Why not? Because: a) It's not possible to compare an atom:id with a rel=self link. It's perfectly possible for the URI in atom:id to be the same as the rel=self in a different feed (unlikely, but possible). It's also possible for the same feed to switch from having an atom:id with one value, to having a rel=self with the a different value. b) rel=self can change c) rel=self offers no guarantee of uniqueness Unless you can explain how multiple different feeds can be obtained via one URI As I explained on a thread last week, rel=self doesn't necessarily correspond with the address the feed is being served from. Stop making this mistake. Graham
Re: PaceOptionalSummary
Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Don't worry about how it might be worded for now, just the principal. Graham
Re: Atom 1.0?
On 10/5/05 7:27 PM, Graham [EMAIL PROTECTED] wrote: Which sounds better? Atom 1.0 released Atom is finished Atom is ready e.
Re: PaceOptionalSummary
Robert Sayre wrote: On 5/9/05, Sam Ruby [EMAIL PROTECTED] wrote: I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. I believe the secretary significantly hampered discourse on this subject for *months*, by claiming the issue had consensus and was closed. It appears that the scorched earth campaign is destined to continue unabated. It is an interesting theory, now lets explore the facts. The secretary's job is to schedule the discussion of Paces. PaceOptionalSummary was authored on 2005/04/30, and scheduled on 2005/05/05. PaceOptionalSummary was preceded by PaceCoConstraintsAreBad, which was authored on 2005/04/06. It, too, was scheduled in the very next round of paces. I agree with Robert; it conflicts with PaceOptionalSummary and I doubt it would exist if PaceOptionalSummary had not make the cut. -1 as well. Doesn't solve a technical problem. It's just gamesmanship. Alternate theory. After months of foreshadowing, PaceOptionalSummary was exquisitely timed to coincide with last call. Along with a diversionary burst of fire concerning alleged process issues. Here's where SHOULD comes in. We're lucky that we have an example of what happens when a SHOULD is violated. I'm sure most of you saw the nasty arguments, accusations, and all-around busted software that happen this week with Google Web Accelerator and Ruby On Rails.[0] Ugly, right? This WG should be proud that we've kept the SHOULDs to a minimum. Interesting analogy, let's see how it pans out. The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. Or they could have made idempotency a MAY, slamming the door shut not only things like Google's WebAccelerator, but also on all web crawlers. Instead, they decided to make idempotency a SHOULD, opening the door for web crawlers by putting servers on notice that in the event of a conflict, the onus is on them. - - - Back to Atom. If a entry in a feed does not include a title, and Firefox's Live Bookmark support choses not to display it, who is the onus on? If an entry in a feed contains neither a textual content nor a summary, and Walter's search engine choses not to index it, who is the onus on? Simply put, PaceOptionalSummary is incomplete. Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible. How can they be if their outcomes are so different? In my note yesterday morning, I made it abundantly clear what I objected to. It wasn't the text between the ==Proposal== and ==Impacts== markers. - - - The W3C got it right. And so should we. Answer the two questions above. Without hysterics like burst into fire. What we actually are talking about here is aggregators that drop information on the floor. Should we warn producers about this? - Sam Ruby
Re: PaceOptionalSummary
Sam Ruby wrote: ... The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. ... Not true. Quoting RFC2616: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. ... Best regards, Julian
Re: PaceOptionalSummary
On 5/10/05, Sam Ruby [EMAIL PROTECTED] wrote: Back to Atom. If a entry in a feed does not include a title, and Firefox's Live Bookmark support choses not to display it, who is the onus on? No one. The spec doesn't say anything about what must be displayed. If an entry in a feed contains neither a textual content nor a summary, and Walter's search engine choses not to index it, who is the onus on? No one. The spec doesn't say anything about what must be persisted. Should we warn producers about this? No. These are application-specific issues. Every application is different. Robert Sayre
Re: PaceOptionalSummary
On Tuesday, May 10, 2005, at 05:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes. Note that I also recognize the legitimacy of publishing a feed without the summary, even if available, in some circumstances--hopefully in an alternative version of the feed (ie., hopefully there's a version of the feed with summaries or content, and a special-purpose one without). That'd lead to a SHOULD, right?
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
On 8 May 2005, at 4:30 am, Walter Underwood wrote: White space is not particularly meaningful in some of these languages, so we cannot expect them to suddenly pay attention to that just so they can use Atom. There will be plenty of content from other formats with this linguistically meaningless white space. So the idea is that whitespace should not appear at all in certain texts, and you'd like it to be stripped out at the consumer? There are only three possible ways for this to happen: 1) The consumer removes all whitespace, even in western texts 2) The consumer recognizes these languages and removes the whitespace automatically 3) The consumer is told what to do by an attribute (1) is obviously not plausible, but included for completeness. (2) is impractical. (3) is plausible, but may or may not end up being implemented in all consumers, making it kind of useless. I don't see how there's a better solution than texts that shouldn't be shown with whitespace not containing whitespace in the first place, which is what we have. Graham
Re: PaceFeedIdOrSelf
On 10 May 2005, at 2:42 pm, Antone Roundy wrote: Both the proposed text and the text that made it in say that the URI (or IRI) identifies or SHOULD identify the feed. The proposal says that the feed SHOULD be available from that xRI. OK, fair enough. But the other reasons I gave are far more important. Was not self added largely/primarily to enable feed readers that didn't get the information about the IRI from which a feed was retrieved to subscribe to it? Did we not discuss standard behavior when obtaining a feed from a different IRI being automatically switching to the self value when accessing it in the future? See http://www.imc.org/atom-syntax/mail-archive/msg12176.html for example. The model was that the browser downloaded the file, and the OS sent a system event to the feed reader asking it to open the file. If I received such a system event, I'd look for the rel=self in the file and subscribe to that address. This all works without looking at self in feeds that are already subscribed to, which would be entirely separate functionality and (apart from that message) hasn't been discussed on the list, as far as I remember. Graham
Re: Atom 1.0?
On May 10, 2005, at 05:29, Tim Bray wrote: Atom 1.0 +1 for Atom 1.0 in order to distinguish from 0.3. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceOptionalSummary
On May 10, 2005, at 4:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes, but I'd go further; I'd like to encourage, in general, producers to put more than less stuff in feeds, and provide a summary whenever they possibly can. My only angst at this moment is whether the canonical SHOULD is the right tool to do that. -Tim
Re: PaceOptionalSummary
Tim Bray wrote: On May 10, 2005, at 4:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes, but I'd go further; I'd like to encourage, in general, producers to put more than less stuff in feeds, and provide a summary whenever they possibly can. My only angst at this moment is whether the canonical SHOULD is the right tool to do that. -Tim MAY is the requirement level I would choose for something like a summary, which isn't a control code or interoperability hotspot. My sense of things, based on the paces and discussion I've seen, is that MAY won't accord sufficient moral obligation to gain consensus here. Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. cheers Bill
RE: Last Call: 'The Atom Syndication Format' to Proposed Standard
--On May 10, 2005 8:57:47 AM -0400 Scott Hollenbeck [EMAIL PROTECTED] wrote: I have to agree with Paul. I don't believe that the issue of white space in the syndicated content is really an Atompub issue. It might be an issue for the content creator. It might be an issue for the reader. As long as the pipe between the two passes the content as submitted, though, the pipe has done its job. If publishers and subscribers have obstacles to using Atom, that sounds like a problem to me. Everyone has this problem is not a good reason to ignore it. Someone has to be the first to solve it, might as well be us. It is not acceptable to build formats for the English Wide Web. That doesn't exist any more. wunder -- Walter Underwood Principal Architect, Verity
Re: Autodiscovery paces
On 5/9/05, Nikolas Coukouma [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceAnchorSupport Autodicovery elements MAY appear in either the head or the body of the document. I believe this is incorrect. IIRC, link elements may only appear in the head, and a elements may only appear in the body. Other than that, +1 on PaceAnchorSupport. http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +0. Part of my newfound personal definition of a life well-lived is to never again argue about semantics, markup, or the correct way to use them. This Pace will break every aggregator on the planet, but then again, so will Atom 1.0 feeds, so... +0. -- Cheers, -Mark
Re: Autodiscovery paces
Nikolas Coukouma wrote: http://www.intertwingly.net/wiki/pie/PaceAnchorSupport +1 with the same remark as Mark Pilgrim. http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +1 if it is extended to support alternate as well when the feed really is the alternate version of the page. That would be a requirement for page authors. Feed readers don't have to check that and can fetch every feed with either a feed or alternate REL attribute value. -- Anne van Kesteren http://annevankesteren.nl/
Re: Autodiscovery paces
Robert Sayre wrote: http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +1 if it is extended to support alternate as well when the feed really is the alternate version of the page. That would be a requirement for page authors. Feed readers don't have to check that and can fetch every feed with either a feed or alternate REL attribute value. I don't understand what the feed relation indicates. What benefit does it have over a href=... type=application/atom+xml.../a ? That it can be used for *any* feed regardless its MIME type. Another advantage is that I can say: 'Look, an a href=link type=application/atom+xmlAtom feed/a that is well-formed', without making feed readers discover it. -- Anne van Kesteren http://annevankesteren.nl/
Re: Atom 1.0?
At 9:09 PM -0700 5/9/05, Walter Underwood wrote: Seriously, I don't mind Atom 1.0 as long as the next version is Atom 2.0. +12 --Paul Hoffman, Director --Internet Mail Consortium
RE: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 8:16 AM -0700 5/10/05, Walter Underwood wrote: If publishers and subscribers have obstacles to using Atom, that sounds like a problem to me. It is a problem, of course. Everyone has this problem is not a good reason to ignore it. No one is ignoring it. This thread started because the format draft pointed out at least one aspect of the problem, which is more than most other RFCs do. Someone has to be the first to solve it, might as well be us. May I suggest that there are groups with more experience in the area than ours that would be more appropriate? In specific, since this problem affects all internationalized text, the Unicode Consortium has a much higher chance of solving the problem than an IETF Working Group who is focused on a syndication format. If you have a proposed solution to the problem (you didn't include one in your message to the WG), the Unicode Consortium is quite open to outside input on this type of thing. It is not acceptable to build formats for the English Wide Web. That doesn't exist any more. That is both grossly insulting to those of us have spent a great deal of time trying to make the Internet internationalization-friendly, and is also grossly technically inaccurate, unless you consider every written language other than Chinese, Japanese Kanji, Burmese, Khmer, Thai, Tagalog, Lao, and Tibetan to be English. (The folks who speak all the other languages might find you calling them English to be insulting too, of course.) --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceOptionalSummary
* Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe its something for the implemetors guide as opposed to the spec, then? Regards, -- Aristotle
Re: Autodiscovery paces
On 10 May 2005, at 3:38 am, Nikolas Coukouma wrote: http://www.intertwingly.net/wiki/pie/PaceAnchorSupport -1 I also don't want to implement it. http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue -1 I mainly don't see the point of changing it. Also, while alternate expressly says the feed corresponds in some way to the content of the current page, feed simply says here is a feed of some kind, and isn't a relationship at all. Graham
Re: PaceOptionalSummary
On 5/10/05, Bill de hÓra [EMAIL PROTECTED] wrote: MAY won't accord sufficient moral obligation to gain consensus here. Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Or, we could figure out a way to let the client ask for the amount of information it desires, rather than legislate morality. http://www.franklinmint.fm/blog/archives/000381.html After all, we're not having discussions on how many entries there should be in a feed. The amount of work on content negotiation/instance manipulation of feed resources should indicate there is no right answer to these questions. Robert Sayre
Re: Autodiscovery paces
On 11/5/05 1:41 AM, Robert Sayre [EMAIL PROTECTED] wrote: I don't understand what the feed relation indicates. What benefit does it have over a href=... type=application/atom+xml.../a It indicates that the @href resource is a feed in the sense that it is a source of notifications of updated content (and is the place to watch for updates the current page) to which one might wish to subscribe, and furthermore it suggests that the resource of @type=application/atom+xml is an Atom Feed Document, and not an Atom Entry Document. Links you might *not* want to use @rel=feed on would be... a href=...example of a broken feed/a a href=...archives for June 2002/a a href=...Tom's feed, very interesting/a Without @rel=feed, a browser with autodiscovery support might well suggest those links as being worthy of subscription. (The third case iffy -- I rule it not @rel=feed because Tom is quite unlikely to include an entry which is an alternate for this particular page). e.
Re: PaceOptionalSummary
A. Pagaltzis wrote: * Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe its something for the implemetors guide as opposed to the spec, then? I raised that question already: http://www.mail-archive.com/atom-syntax@mail.imc.org/msg02809.html the WG didn't discuss it in follow-up (I think). cheers Bill
RE: Atom 1.0?
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-atom- [EMAIL PROTECTED] On Behalf Of Graham On 10 May 2005, at 3:29 am, Tim Bray wrote: Question: how do we refer to the product of this WG once it has an RFC number? Just Atom, no version number. No one refers to HTTP or SMTP or POP or XML by their version numbers unless they have to. Including the version number makes it sound like their are other versions that matter, and for the moment, they're aren't. Which sounds better? Atom 1.0 released Atom is finished Graham I think we should distinguish the technical conversation from the marketing/evangelism name. I'd suggest Atom 1.0 for circumstances where it's relevant (distinguishing within technical documentation) and Atom by itself everywhere else, such as on the AtomEnabled site or on sidebar buttons linking to a feed. If you see Atom 1.0 somewhere, it should only be in contexts where someone knows what XML stands for, without having it explained. Anil __ Anil Dash +1 646 541 5843
Re: PaceOptionalSummary
On 5/10/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Bill de hÓra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe it's something for the implemetor's guide as opposed to the spec, then? That's one option. If the implementor's guide were a BCP RFC, it would be easy to flag in a feed validator. The validator at feedvalidator.org spits out a pretty scary warning when it decides to warn (example: javascript in html content). Many people mistake the warnings for an error, because the little 'valid' badge is buried under the warning message and source code. A BCP RFC could be used as fodder for a less-scary looking warning. Something like This feed may not follow established best practices. Another option would be to give title-only entries an intimidating name in the spec. Something like Entries that lack both an atom:summary and an atom:content are termed 'Content-Free'. Or we could do both. Robert Sayre
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
Scott == Scott Hollenbeck [EMAIL PROTECTED] writes: I'm not asking for a lot of text; probably something about as long as this message. I believe that it can be a lot shorter: given the rationale above, it's not a problem for Atompub or any other XML-using protocol. For that matter, it's not really and XML problem at all: it affects text formats like HTML and RFC 2822 as well. Scott I have to agree with Paul. I don't believe that the issue Scott of white space in the syndicated content is really an Scott Atompub issue. It might be an issue for the content Scott creator. It might be an issue for the reader. As long as Scott the pipe between the two passes the content as submitted, Scott though, the pipe has done its job. Except that we try to build deployable protocols. If there aren't content creation tools that can do the right thing then it becomes a deployment issue for atompub. A perfectly reasonable response would be that you've thought about and understood the problem and there are sufficient tools available that can work with your proposed pipe that you don't need to care about the issue. --Sam
RE: Last Call: 'The Atom Syndication Format' to Proposed Standard
A perfectly reasonable response would be that you've thought about and understood the problem and there are sufficient tools available that can work with your proposed pipe that you don't need to care about the issue. Paul described text that's in the document to describe what MAY be done. I would argue that the existing text is evidence of the thought that has gone into understanding the issue and the alleged problem. -Scott-
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 2:14 PM -0400 5/10/05, Sam Hartman wrote: Except that we try to build deployable protocols. If there aren't content creation tools that can do the right thing then it becomes a deployment issue for atompub. True. Fortunately, there have been plenty of text editing tools that work with the no spaces between words languages for at least 20 years in the case of Chinese and Japanese Kanji (probably 15 years for the other languages). A perfectly reasonable response would be that you've thought about and understood the problem and there are sufficient tools available that can work with your proposed pipe that you don't need to care about the issue. I'll make that response. :-) --Paul Hoffman, Director --Internet Mail Consortium
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: Atom 1.0?
--On Tuesday, May 10, 2005 09:12:09 AM -0700 Paul Hoffman [EMAIL PROTECTED] wrote: At 9:09 PM -0700 5/9/05, Walter Underwood wrote: Seriously, I don't mind Atom 1.0 as long as the next version is Atom 2.0. +12 I'd also be happy with just Atom and saying RFC Atom when pressed for a version. Even with Atom 1.0 we'll need to say which RFC. If we choose a specific name, it *must* be in the RFC. Because the RFC must be a hit for that search. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Re: Atom 1.0?
On 5/10/05, Walter Underwood [EMAIL PROTECTED] wrote: If we choose a specific name, it *must* be in the RFC. Because the RFC must be a hit for that search. Walter, that's a good point. How about: Marketing: Atom Technical: Atom (RFC) ? Robert Sayre
Re: I-D ACTION:draft-ietf-atompub-autodiscovery-01.txt
On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-01.txt And a more pleasant one is: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html or for your two words on every page? yay. pleasure: http://philringnalda.com/rfc/diff-00-01.txt Phil Ringnalda
Re: Atom 1.0?
On 10 May 2005, at 9:27 pm, Robert Sayre wrote: Walter, that's a good point. How about: Marketing: Atom Technical: Atom (RFC) Around Dave Winer: RFC The only real problem with dropping the version number is making it clear there've been major changes since 0.3. Graham
Re: Atom 1.0?
Walter Underwood wrote: I'd also be happy with just Atom and saying RFC Atom when pressed for a version. +1 - Sam Ruby
Re: Atom 1.0?
Le 05-05-09 à 23:48, Robert Sayre a écrit : I like Atom. Fear the non versioning. And yes there will be new version. I would even go as far to be sure to be able to identify the language in the document itself. The namespace should be enough for that. CSS was defined without versioning in mind and it's now a mess for tools developers. +1 to the suggestion of Atom 1.0 -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Atom 1.0?
Walter Underwood wrote: If we choose a specific name, it *must* be in the RFC. Because the RFC must be a hit for that search. We can Google-bomb that string I guess. (Atom 1.0.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Autodiscovery paces
Eric Scheid wrote: On 11/5/05 1:41 AM, Robert Sayre [EMAIL PROTECTED] wrote: I don't understand what the feed relation indicates. What benefit does it have over a href=... type=application/atom+xml.../a It indicates that the @href resource is a feed in the sense that it is a source of notifications of updated content (and is the place to watch for updates the current page) to which one might wish to subscribe, and furthermore it suggests that the resource of @type=application/atom+xml is an Atom Feed Document, and not an Atom Entry Document. Links you might *not* want to use @rel=feed on would be... a href=...example of a broken feed/a a href=...archives for June 2002/a a href=...Tom's feed, very interesting/a Without @rel=feed, a browser with autodiscovery support might well suggest those links as being worthy of subscription. (The third case iffy -- I rule it not @rel=feed because Tom is quite unlikely to include an entry which is an alternate for this particular page). IMO, autodiscovery should occur only when a @rel (or @rev) is provided (and, ideally, understood). Don't forget HTML does not define a default value for @rel or @rev when they are not provided. This is a link to an Atom document: a href=... type=application/atom+xml.../a These are links to Atom documents which indicate a relation between the containing document and the feed pointed to by the @href and should therefor trigger autodiscovery: Linking to the news feed from the news page: a href=... rel=alternate type=application/atom+xml.../a Linking to the news feed from another page (e.g. the Mozilla home): a href=... rel=related type=application/atom+xml.../a -- Thomas Broyer
Re: PaceOriginalAttribute
-1 An entry only needs one identifier. The way to solve this problem (if it needs solving) is allowing duplicate ids under some or all circumstances. Graham
Re: Autodiscovery paces
There's no reason for any of the ideas in this thread to be in the same draft as the concepts outlined in autodiscovery-01. Stamp Out Creativity Now. I'm strongly opposed to letting this draft turn into a vast metropolis of bikesheds, where we have 60-message threads on the right way to use HTML @rel values. The WG has limited resources and time. Those resources are most needed by the protocol draft. Bolting fancy new appendages on the autodiscovery draft is a waste of time. You don't need a standards action to add a link relation. Just do it. Robert Sayre
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: the atom:copyright element
At 01:08 05/05/09, Tim Bray wrote: On May 7, 2005, at 3:29 PM, Robin Cover wrote: The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. +1 +1 here too.Regards, Martin.
Re: extensions -- Atom NS and unprefixed attributes
Hello Paul, What's the difference between IETF consensus (for which you gave a -1) and it's up to the IESG (which seems what you think we should let happen)? In my view, IETF consensus is another way of saying the IESG has the last word. If there is a better way to express this in the spec, then what would that be? Or would we say that because the atom namespace appears in an IETF spec, it's obvious that only the IETF (thus ultimately the IESG) can add stuff, but we don't have to say so? Regards, Martin. At 11:57 05/05/10, Paul Hoffman wrote: At 7:22 PM -0700 5/9/05, Tim Bray wrote: On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceOriginalAttribute
On 5/10/05, Graham [EMAIL PROTECTED] wrote: On 11 May 2005, at 1:22 am, Robert Sayre wrote: Hmm. I'd be curious to hear what you think the problem is. Every system I can think of that does forwarding or versioning assigns multiple identifiers. Perhaps you have an example system in mind? atompub-format-08: When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change. No, I mean a deployed system. Robert Sayre
Re: draft-ietf-atompub-protocol-04.txt
Joe, Thanks for your comments on my comments ;-) 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. 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. In the current specification draft (04), it looks like the entry and generic both specify identical actions (in the table showing Body/No body versus GET/PUT/DELETE/POST. So the real difference between the two is in the Content-types that each can handle: generic is unspecified, while entry is only defined as application/atom+xml or application/soap+xml. In addition, the PROTOCOL specifies which ATOM elements are Roundtrip. The advantage of specifying Content-Types as opposed to contents attribute of entry and generic (and further definitions): 1) immediately gain the ability of the client to discern acceptable Content-Types, something sorely missing from the current specification. 2) immediately gain the advantage of the client being able to determine if it can talk to the ATOM URI. (Graphic applications can talk to ATOM APP that accept image/*, audio applications=audio/*, etc) 3) Do not have to amend a specification (or create a new one) in order to handle every single Content-Type. 4) Adding different Content-Types to the allowable formats immediately opens the specification to a wide range of fairly obvious uses in the podcasting, videocasting, *casting. And even in corporate use, building in the parsing of Content-Types makes available any kind of syndicated content whatsoever using the same tools built around the APP specification. The current use of contents attribute still may have its place (in resolving duplicate Content-Type applications such as application/atom+xml templates vs. application/atom+xml entries -- but I'm not fully convinced of this example, however, there may be others). And then to cover the other specification listed under contents=entry: you could specify that all application/atom+xml entries provide Roundtrip atom:updated and atom:id elements. I don't *think* that this would adversly impact other uses of atom or APP. Again, just thoughts that I'm happy to debate. I don't want to step on anyone's toes here. Greg Smith Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
Re: Autodiscovery paces
On 11/5/05 2:24 AM, Graham [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue -1 I mainly don't see the point of changing it. The point is that just using 'alternate' is hideously ambiguous, and leads to interoperability problems because you cannot rely on the value of @type to accurately guess whether @href points to a feed or some other document. In the history of feed autodiscovery, the exact syntax was corrected within days of being first announced. Since then it's become popular, even without official documentation in a specification. During that time people have come to realise that there is a problem with 'alternate' ... consider that pre-spec time as being a beta test period ... and now that we are on the verge of releasing a fully documented specification it is our last real opportunity to fix any mistakes. Robert says anyone can mint new @rel types, but seriously, in the face of popular usage of 'alternate' being backed up by a RFC specification, does anyone think 'feed' would have a chance? Put it in the spec and we are saying use of 'alternate' is flawed, the preferred option is 'feed', and it will have more potency. Also, while alternate expressly says the feed corresponds in some way to the content of the current page, feed simply says here is a feed of some kind, and isn't a relationship at all. Depends on how you read the word 'feed'. It can indicate a relationship, that being this is the feed in which an entry representing this page (or portion thereof) was once found, and may again be found. I, like some, feel uncomfortable with those usage of autodiscovery links to point to just any feed, from any page. Links to feed resource documents are not necessarily links to feeds. e.
Re: Autodiscovery paces
On 11/5/05 1:20 PM, Eric Scheid [EMAIL PROTECTED] wrote: Also, while alternate expressly says the feed corresponds in some way to the content of the current page, feed simply says here is a feed of some kind, and isn't a relationship at all. Depends on how you read the word 'feed'. It can indicate a relationship, that being this is the feed in which an entry representing this page (or portion thereof) was once found, and may again be found. I, like some, feel uncomfortable with those usage of autodiscovery links to point to just any feed, from any page. Links to feed resource documents are not necessarily links to feeds. On reflection, I thought I'd better check what the spec says... http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html 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. There is also this in section 6 The order of the autodiscovery elements is significant. The first element SHOULD point to the publisher's preferred feed for the document. ... thus [1] auto-discovery is *not* for the general case of linking to just *any* feed resource, but specifically the one associated to the current page/site. Which is a specific relationship, one we can name 'feed' (or 'fred', or 'barney' ... but 'feed' gets my vote). e. [1] I conclude ... and so might any reader of the spec who is ignorant of the full backstory.
Re: Autodiscovery paces
On 11/5/05 1:18 AM, Mark Pilgrim [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +0. Part of my newfound personal definition of a life well-lived is to never again argue about semantics, markup, or the correct way to use them. This Pace will break every aggregator on the planet, but then again, so will Atom 1.0 feeds, so... +0. :-) My belief is that RSS/Atom is at the point of crossing the chasm [1] and going mainstream, and as such if we want the momentum to continue we should be mindful of two things: * adding features/functions/tweaks which appeal to geeks and other 'insiders' is counter-productive * not fixing any warts or bugs which non-geeks won't understand why they get broken behaviour is counter-productive. There is thus a filter to be applied to any suggestions for improvements. Changing 'alternative' to 'feed' fits the second criteria, but adding a/ fits the first. So, +1 to PaceDifferentRelValue, -1 to PaceAnchorSupport. e. [1] http://en.wikipedia.org/wiki/Crossing_the_Chasm
Re: extensions -- Atom NS and unprefixed attributes
On 5/9/05, Robert Sayre [EMAIL PROTECTED] wrote: I am fine with that. I am concerned that the current draft fails to differentiate between foreign markup and markup that requires IESG approval. I am going to try this again, because it's important. entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? Maybe I've read it too many times and I'm missing something. Common sense would seem to outlaw it, but that's not good enough. Robert Sayre
