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. ... ... Legal? Which

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

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

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 cann

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 desc

Re: extensions -- Atom NS and unprefixed attributes

At 4:15 PM +0900 5/10/05, Martin Duerst wrote: 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)? From RFC 2434: IESG Approval - New assignments must be approved by the IESG, but ther

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

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

Hello Sam, others, At 22:33 05/05/09, Sam Hartman wrote: > >> "Martin" == Martin Duerst <[EMAIL PROTECTED]> writes: > >Martin> At 17:29 05/05/07, Henri Sivonen wrote: >>> On May 4, 2005, at 04:39, Martin Duerst wrote: >>>> For free-flowing text, however, the line breaks in the sour

Re: PaceOriginalAttribute

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,

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 na

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, t

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 >

Re: PaceOriginalAttribute

On 5/10/05, Graham <[EMAIL PROTECTED]> wrote: > > -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. Hmm. I'd be curious to hear what you think the problem is. Every system I can think of

draft-ietf-atompub-protocol-04.txt

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". 6.1 In the table, what does "x" mean? Not allowed? Seems li

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

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: PaceOriginalAttribute

Tim Bray wrote: +1 I'm not 100% convinced it solves the problems Rob says it does, but it seems cheap, lightweight, and unlikely to cause any harm. -Tim +0.8 It seems to me the proposed wording doesn't accurately reflect the rationale... -- Thomas Broyer

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 ... 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

Re: Atom 1.0?

Question: for what principal usage context(s) is this name being designed? I heard Tim say "quick, snappy label" ... to distinguish it from Atom 0.3" Does this mean "the default name for the spec/product in any context not requiring any attributes other than version number and minimal title-str

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

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

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?

On 5/10/05, Graham <[EMAIL PROTECTED]> wrote: > > Around Dave Winer: RFC Let's not go there, ok? > The only real problem with dropping the version number is making it > clear there've been major changes since 0.3. Who are we trying to make it clear to? I think it will be clear to develope

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: 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

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: 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 ve

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,

Re: Autodiscovery paces

On 10 May 2005, at 8:41 pm, Phil Ringnalda wrote: ... that it will be totally borked if Atom feeds with rel="alternate" autodiscovery turn out to be in a namespace other than the Atom 0.3 one. I just tried it, and it doesn't seem to care about the namespace. Anyone who gets lazy and uses "altern

I-D ACTION:draft-ietf-atompub-autodiscovery-01.txt

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 : Atom Feed Autodiscovery Author(s) : P. Ringnalda, M. Pilgrim Filename

Re: Autodiscovery paces

On 5/10/05, Phil Ringnalda <[EMAIL PROTECTED]> wrote: > > On 5/10/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > > > The need is to not confuse users. Safari under tiger now does RSS > > auto-discovery, which means > > ... that it will be totally borked if Atom feeds with rel="alternate" > autod

I-D ACTION:draft-ietf-atompub-protocol-04.txt

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

Re: Autodiscovery paces

On 5/10/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > The need is to not confuse users. Safari under tiger now does RSS > auto-discovery, which means ... that it will be totally borked if Atom feeds with rel="alternate" autodiscovery turn out to be in a namespace other than the Atom 0.3 one. It

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

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

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 XM

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 > spe

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 refe

Re: Autodiscovery paces

On 11/5/05 3:17 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > Hmm. I can see the merit in your rationale. Does it meet a need? The need is to not confuse users. Safari under tiger now does RSS auto-discovery, which means there will be many totally-non-geek users who might well get upset if the

Re: Autodiscovery paces

On 5/10/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > Without @rel="feed", a browser with autodiscovery support might well suggest > those links as being worthy of subscription. Hmm. I can see the merit in your rationale. Does it meet a need? Why not deploy it and see what happens. There's no

Re: PaceOptionalSummary

A. Pagaltzis 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? I raised that question already: http://www

Re: PaceFeedIdOrSelf

On 10/5/05 3:50 AM, "Eric Scheid" <[EMAIL PROTECTED]> wrote: >> I didn't change the Pace, since such a change could conceivably change >> the opinions of people who've expressed an opinion on it already. But >> I would be interested to know whether people think this would be an >> improvement, m

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 > > ... 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 t

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 o

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 fe

Re: PaceOptionalSummary

* 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? Regards, -- Aristotle

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 dr

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: 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 fee

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

On May 10, 2005, at 18:16, Walter Underwood wrote: "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. I believe the problem shou

Re: Autodiscovery paces

> > 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

RE: Last Call: 'The Atom Syndication Format' to Proposed Standard

> -Original Message- > From: Walter Underwood [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 10, 2005 11:16 AM > To: Scott Hollenbeck; 'Paul Hoffman'; iesg@ietf.org; 'Atom WG' > Subject: RE: Last Call: 'The Atom Syndication Format' to > Proposed Standard > > > > --On May 10, 2005 8:57

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 wo

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 or the of the document." I believe this is incorrect. IIRC, elements may only appear in the , and elements may only appear in the .

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

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,

Re: PaceOptionalSummary

On 5/10/05, Tim Bray <[EMAIL PROTECTED]> wrote: > > 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. Shouldn't we warn producers that this hurts performance in cellphones and Firefox?

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, produ

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: 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 i

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 whi

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 publi

Re: PaceFeedIdOrSelf

On Tuesday, May 10, 2005, at 03:41 AM, Graham wrote: 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. Let's look

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

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 a

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

RE: Last Call: 'The Atom Syndication Format' to Proposed Standard

> >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 affect

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

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: PaceOptionalSummary

> Roger, please don't see this as an attack. Robert: I would have to be one seriously touchy prick to see that as an attack. Don't sweat it. > I don't think there's a scope argument here. That's what I get for using a loaded term. My apologies. Again, I think title-only feeds are reasonable. A

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

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"

Re: Atom 1.0?

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? 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.

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