Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

down the entire stack. Although you can come up with some heuristics to determine when you've seen a document before, most (if not all) of them can be fooled by particular sequences of entries. Remembering which ones you've seen (using their 'this' URI) allows you to easily f

Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

Thinking a little more about this, I'm not sure what the "this" link would be used for. The "prev" link seems to be doing all the work, and especially assuming a "batches of 15" sort of model, the "this" link seems likely to end up pointing to a document that's going to disappear soon 14 tim

Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

Let's say we are planning to keep the latest 15 entries in our stateful feed. We publish the first entry, and have a feed with 1 entry in it. It has a "this" link, but no "prev" link. Then we add an entry. The old "this" link can't be used to point to the new instance of the feed, right?

Re: Signature wording

On Wednesday, June 22, 2005, at 11:32 AM, James M Snell wrote: Paul Hoffman wrote: 2) What you are signing is just the set of bits in the entry, or just the set of bits in the feed, with no interpretation of them. No pre-canonicalization is needed, and none is to be expected by the validatin

Re: More on Atom XML signatures and encryption

On Monday, June 20, 2005, at 11:33 PM, James M Snell wrote: OK, so given the arguments I previously posted in my response to Dan + the assertion that digitally signing individual entries will be necessary, the only real possible solution would be to come up with a canonicalization scheme for

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

On Saturday, June 18, 2005, at 06:28 PM, David Powell wrote: Atom 0.3 multiparts forced a dubious and complex processing model on everyone wanting to process Atom documents. This problem was solved by their removal in the 03 to 07 drafts. The prohibition of composite types in the 08 draft (mad

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

On Saturday, June 18, 2005, at 01:36 PM, Graham wrote: On 17 Jun 2005, at 6:14 pm, Tim Bray wrote: Uh, has Mark spotted a dumb bug here that we should fix? Do we care if *remote* content is of a composite MIME type? My feeling was that we ruled out composite types in *local* content, for fa

Re: Polling Sucks! (was RE: Atom feed synchronization)

On Friday, June 17, 2005, at 12:32 PM, Bob Wyman wrote: This is *not* simpler than taking a push feed using Atom over XMPP. For a push feed, all you do is: 1. Open a socket 2. Send a "login" XML Stanza 3. Process the stanzas as they arrive. ... For your

Re: Atom feed synchronization

On Thursday, June 16, 2005, at 04:37 PM, James M Snell wrote: Scenario: A content source is updated 100 times per hour. The Atom feed currently only displays the 20 most recent entries. Users who are not checking the feed every 10 minutes or so are missing entries. How do we address this?

Re: I-D ACTION:draft-ietf-atompub-format-09.txt

4.1.1: o atom:feed elements MUST NOT contain more than one atom:image element. Should be "atom:logo". 4.1.2 says: o atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type a

Re: PaceDuplicateIdsEntryOrigin posted (was Re: Consensus snapshot, 2005/05/25)

On Wednesday, May 25, 2005, at 01:06 PM, Antone Roundy wrote: == Abstract == State the atom:entries from the same feed with the same ID are the same entry, whether simulateously in the feed document or not. I'm retracting this proposal in preference for PaceAtomIdDos, which I like b

Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)

On Thursday, May 26, 2005, at 08:04 AM, A. Pagaltzis wrote: * Graham <[EMAIL PROTECTED]> [2005-05-25 23:00]: How is this a "Denial of service" attack? Isn't it just ordinary spoofing/impersonation? Indeed; I’d like to see this reworded to refer to “spoofing,” as that’s what it is. I presum

Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)

On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote: Ignoring the overhead that it adds for now, isn't this the kind of situation digital signatures are designed to handle? Sure, but how many publishers are going to be using digital signatures in the near term (and more importantly, h

Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)

On Wednesday, May 25, 2005, at 02:49 PM, Graham wrote: On 25 May 2005, at 9:01 pm, Antone Roundy wrote: 8.5 Denial of Service Attacks Atom Processors should be aware of the potential for denial of service attacks where the attacker publishes an atom:entry with the atom:id value of an entry

Re: Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted

On Wednesday, May 25, 2005, at 02:26 PM, Henry Story wrote: Since the referents of "Superman" and "Clark Kent" are the same, what is true of the one, is true of the other. When speaking directly about the world, we can replace any occurrence of Superman with Clark Kent, and still say somethin

PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)

On Wednesday, May 25, 2005, at 01:20 PM, Graham wrote: On 25 May 2005, at 7:35 pm, Antone Roundy wrote: "If multiple atom:entry elements originating in the same Atom feed have the same atom:id value, whether they exist simultaneously in one document or in different instances of the

PaceDuplicateIdsEntryOrigin posted (was Re: Consensus snapshot, 2005/05/25)

On Wednesday, May 25, 2005, at 12:35 PM, Antone Roundy wrote: I'm going to write a Pace right now, in case that will make any difference. Here it is--now comments on that particular detail can be directed at a proper Pace: http://www.intertwingly.net/wiki/pie/PaceDuplicateIdsEntryO

Re: Consensus snapshot, 2005/05/25

On Wednesday, May 25, 2005, at 12:03 PM, Tim Bray wrote: The level of traffic in recent days have been ferocious, and reading through it, we observe the WG has consensus on changing the format draft in a surprisingly small number of areas. Here they are: All looks good (or at least entirely

Re: inheritance issues

On Tuesday, May 24, 2005, at 10:21 AM, Walter Underwood wrote: Inheriting values saves typing. It does not save bandwidth, because HTTP compression will do nearly as well. 6% of the feeds I subscribe to use compression. I don't think we can depend on that yet.

Re: inheritance issues

On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: Simplify, simplify. I am for removing all inheritance mechanisms... I would agree if we had a better way to avoid all the repetition that would lead to. However, the only proposal[0] I can remember that would have done so has been r

Re: PaceClarifyAuthorContributor posted

On Monday, May 23, 2005, at 09:12 AM, Dan Brickley wrote: I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption "Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be?" Possible ans

Re: multiple ids

On Sunday, May 22, 2005, at 07:14 PM, Paul Hoffman wrote: At 2:11 AM -0400 5/21/05, Bob Wyman wrote: "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry." +1. I can live with Tim's original wording because the phrase tha

Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

On Saturday, May 21, 2005, at 09:20 PM, Bob Wyman wrote: Antone Roundy wrote: Unless the "need" for this can be shown, and it can be shown that an extension can't take care of it, I'm -1 on atom:modified. The need is simple and I've stated it dozens of times.

I wanna go home

I'd like to see a fair number of changes from the current draft, but there are very few changes that I want badly enough, and have enough hope of seeing approved to overshadow my desire to finish Atom 1.0 expeditiously. Here's what I'd like to see--small changes that minimally deal with prob

atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

On Saturday, May 21, 2005, at 05:57 PM, Bob Wyman wrote: The second problem is that readers (not publishers) need to be able to distinguish and temporally order entries that have been written by publishers. We may not have been discussing exactly the same details before, but when atom:modifi

Re: Fetch me an author. Now, fetch me another author.

On Saturday, May 21, 2005, at 04:08 PM, Robert Sayre wrote: You think you'll be able to disambiguate entries by adding a more-specific date field, making for two date fields. I think you can disambiguate entries by adding any number of extension fields. That's great. Add extensions. +1 -- thos

Re: Compulsory feed ID?

On Saturday, May 21, 2005, at 12:30 AM, Bob Wyman wrote: Tim Bray wrote: I think the WG basically decided to punt on the DOS scenario. -Tim I believe you are correct in describing the WG's unfortunate disposition towards this issue. (Naturally, I object...) I've tried to get discuss

Re: multiple atom:author elements?

On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote: I see this as a problem... 4.1.2 The "atom:entry" Element * atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom

Re: Compulsory feed ID?

On Thursday, May 19, 2005, at 06:41 AM, Tim Bray wrote: We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement

Why and how to identify a feed (was Re: Consensus call on last raft of issues)

On Wednesday, May 18, 2005, at 10:11 AM, Sam Ruby wrote: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - som

Re: Change Control (was: extensions -- Atom NS and unprefixed attributes)

On Wednesday, May 18, 2005, at 03:17 PM, Henri Sivonen wrote: On May 17, 2005, at 17:47, Antone Roundy wrote: What possible advantage would there be to allowing just anyone to add elements to Atom's namespace, or any other namespace, for that matter? I can't think of any. If you

Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues)

On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote: I supposed the surest way to make it impossible to fake the id, is to specify that by dereferencing the id and doing a GET (whatever the correct method of doing that for the protocol happens to be) one should be able to retrieve the ent

Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues)

On Tuesday, May 17, 2005, at 11:07 PM, Sam Ruby wrote: "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such." IIRC, much of this started due to an objection by Bob Wyman that treating atom

Re: Change Control (was: extensions -- Atom NS and unprefixed attributes)

On Tuesday, May 17, 2005, at 08:22 AM, Robert Sayre wrote: Do we have a situation similar to HTTP headers and methods, where you can extend it as needed, but you had better 'coordinate' if you want to make sure everyone interprets it the same way? That's fine. Or do we have an IETF-administered re

Re: extensions -- Atom NS and unprefixed attributes

On Monday, May 16, 2005, at 10:59 AM, Tim Bray wrote: On May 16, 2005, at 6:27 AM, Robert Sayre wrote: On 5/16/05, Tim Bray <[EMAIL PROTECTED]> wrote: The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that peopl

Re: PaceContentAndSummaryDistinct

On Saturday, May 14, 2005, at 10:36 AM, Kevin Marks wrote: After seeing 'in the wild' what I consider badly-formed Atom feeds, where both the atom:summary and atom:content contain identical abbreviated entry text, I realised that the spec does not make this clear. As this is a key advantage of

Re: Fetch Me A Rock

On Thursday, May 12, 2005, at 02:11 PM, Paul Hoffman wrote: So, if atom:summary is a MAY, then applications MUST be able to deal with feeds whether they have it or not. The text for SHOULD does not call out any such requirements. This omission suggests to me that the intent of SHOULD is to NO

Re: Fetch Me A Rock

On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote: Paul Hoffman wrote: At 7:16 PM +0200 5/12/05, Julian Reschke wrote: A receiving implementation must be able to handle all defined elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what yo

Re: atom:updated vs entry inheritance?

On Thursday, May 12, 2005, at 12:20 PM, Thomas Broyer wrote: Eric Scheid wrote: Gah! What is the true atom:updated for the following entry? 2005-05-12T02:22:59+ ... ... 2005-05-11T01:11:59+ ... ... ... Well, I don't see any problem he

Re: nit: spaces in [EMAIL PROTECTED]

On Thursday, May 12, 2005, at 12:10 PM, Eric Scheid wrote: I believe the intention is that only one value is allowed, and any whitespace included is part of the name of the rel value. Perhaps this should be noted in the spec. Or are you suggesting we adopt the HTML method? perhaps, but it's late,

Re: Last Call: required summary or content?

On Wednesday, May 11, 2005, at 06:09 PM, Robert Sayre wrote: On 5/11/05, Graham <[EMAIL PROTECTED]> wrote: Note no one wants to ban title- only feeds if they come from title-only resources. This is the problem I have. Title-only feeds are perfectly ok from any resource. They are probably not a goo

Re: extensions -- Atom NS and unprefixed attributes

On Wednesday, May 11, 2005, at 12:11 PM, Paul Hoffman wrote: ... ... 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. Hearing from as many people who feel that they

PaceOriginalAttribute (was Re: Fetch Me A Rock)

On Wednesday, May 11, 2005, at 09:38 AM, Robert Sayre wrote: I think the reason there is no "consensus" on-list is because Sam and Graham are trying to make normative requirements without outlining the operational result they are after. What was the operation result you were after with this Pace?

Re: Atom 1.0?

On Wednesday, May 11, 2005, at 09:09 AM, A. Pagaltzis wrote: * Bill de hÓra <[EMAIL PROTECTED]> [2005-05-11 17:05]: ARSS, short for Atom RSS. The marketing possibilities are endless. How about Atom Syndication Standard? So, ASS = Atom Syndication Standard. Or is it Atom Standard for Syndication?

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: Atom 1.0?

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. Per WG consensus, an Atom doc

Re: PaceFeedIdOrSelf

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

Re: PaceFeedIdOrSelf

On Monday, May 9, 2005, at 05:05 PM, Graham wrote: On 4 Apr 2005, at 6:59 pm, Antone Roundy wrote: And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of "self". rel="self" is in no way

Re: PaceOptionalSummary

On Monday, May 9, 2005, at 02:43 PM, Robert Sayre wrote: Did you see this email? Did you notice all the questions about the technical basis of your position? Maybe you should answer them. Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible.

Re: Which is the preferred feed?

On Monday, May 9, 2005, at 10:27 AM, Anne van Kesteren wrote: Bob Wyman wrote: Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requi

PaceRenameImageToLogo

Not having generated any response by suggesting this without a Pace, I've written a Pace. If a miracle happens and no one denounces this idea as certain to destroy the Atom format (or otherwise gives it a -1), but no one but me gives it a +1, would that be enough to call it the consensus opini

PaceFeedIdOrSelf

The pace adds this under atom:feed: atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of "self". That could just as well be: atom:feed elements that contain no child atom:link element with a relation of "self"

Re: the "atom:copyright" element

On Sunday, May 8, 2005, at 10:08 AM, 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

Re: PaceNoAlternateForFeed

On Monday, May 9, 2005, at 08:11 AM, Bill de hÓra wrote: * PaceFeedIdOrSelf: that pace suggests pointing to self in the absence of an atom:[EMAIL PROTECTED]'alternate'] or an atom:id. This pace suggests allowing the publisher to state there is no alternate. Not quite right--that pace requires

Re: PaceOriginalAttribute

On Thursday, May 5, 2005, at 05:21 PM, Robert Sayre wrote: On 5/5/05, Antone Roundy <[EMAIL PROTECTED]> wrote: Yeah, they think they are, or at least claim to think so. But isn't that the same thing that is stated if you see the following in two feeds?

Re: PaceAllowDuplicateIDs alteration

On Friday, May 6, 2005, at 09:16 AM, Bob Wyman wrote: Graham wrote: "If an Atom Feed Document contains multiple entries with the same atom:id, software MUST treat them as multiple versions of the same entry" Are they still the same entry if they have different source elements that identify

Re: PaceAllowDuplicateIDs

On Thursday, May 5, 2005, at 08:44 AM, Antone Roundy wrote: If we accept this Pace, are we going to do anything to address the DOS issue for aggregated feeds? Bob, if I may direct a few question to you, since you have the most experience with this issue: if PaceAllowDuplicateIDs is adopted, how

Re: PaceOriginalAttribute

On Thursday, May 5, 2005, at 10:14 AM, Robert Sayre wrote: On 5/5/05, Antone Roundy <[EMAIL PROTECTED]> wrote: It may help people avoid accidentally generating invalid feeds (if we stick to not to allowing duplication of atom:id within a feed), but it does it by simply shunting the issue of

Re: PaceAllowDuplicateIDs

On Thursday, May 5, 2005, at 09:15 AM, Eric Scheid wrote: Have a look here: http://en.wikipedia.org/w/index.php?title=Main_Page&action=history There you have a reverse chrono list, each with an author, date, and summary. Looks an awful lot like each one is an entry to me. and looks to me like a st

PaceSourceRecs

Looks good, but perhaps the recommendations could be slightly different: Start by calculating the the language of the atom:feed and the atom:entry. Second, if the language of atom:entry isn't the same as the aggregate feed, set it. Third, if the language of atom:feed isn't the same as the ato

PaceOriginalAttribute

-1. I don't see that this solves any problem. It may help people avoid accidentally generating invalid feeds (if we stick to not to allowing duplication of atom:id within a feed), but it does it by simply shunting the issue off into a different element which doesn't have duplication constraint

PaceRecommendPlainTextContent

-1. This is entirely up to the publisher. I think enough publishers are going to want things like links and line/paragraph breaks in their content that this recommendation would be so routinely ignored as to be meaningless.

PaceOptionalSummary

+1. ...oh, and the wording I just suggested for part of PaceTextShouldBeProvided would depend on this also being accepted.

PaceTextShouldBeProvided

+1 except for one thing: In section 4.1.2, I'd suggest something along these lines: atom:entry elements which do not contain an atom:content element, or whose atom:content element's type attribute indicates a MIME media type, SHOULD contain an atom:summary element.

Re: PaceAllowDuplicateIDs

If we accept this Pace, are we going to do anything to address the DOS issue for aggregated feeds?

Re: status paces

On Thursday, May 5, 2005, at 07:13 AM, Robert Sayre wrote: Throw them all back. No reason we can't do this in an extension element. +1

Re: Autodiscovery, real-world examples

On Thursday, May 5, 2005, at 01:27 AM, fantasai wrote: And for linking to other pages.. Here's a real-world example: The mozilla.org main page is an example of where rel="alternate" is a problem. There were three feeds on it: "Announcements", "mozillaZine News", and "Mozi

Re: Autodiscovery

On Wednesday, May 4, 2005, at 04:49 PM, Nikolas 'Atrus' Coukouma wrote: Eric Scheid wrote: On 4/5/05 11:11 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: The autodiscovery spec is a reasonable interpretation of the *one line* definition of the 'alternate' relation. how is a feed of recent entries a

Re: Autodiscovery

On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote: Again, my friend's blog feed is not an Atom version of /my/ web page; linking to it as "alternate" would be wrong. To me, this raises a red flag, suggesting that using an autodiscovery link from your web page to your friend's feed is not wha

Re: Autodiscovery

On Tuesday, May 3, 2005, at 11:41 PM, fantasai wrote: David Nesting wrote: I expect that many of my implementations will utilize content negotiation (using the same URL as an HTML representation, where needed), so I expect that I'll have some links like: Or even That won't work, beca

Re: Getting atom:source right

On Tuesday, May 3, 2005, at 09:04 AM, Asbjørn Ulsberg wrote: On Mon, 02 May 2005 23:13:06 +0200, Antone Roundy <[EMAIL PROTECTED]> wrote: Should we add something like this? If an atom:entry element already containing an atom:source element is copied to another feed, the conte

Re: PaceDuplicateIDWithSource2

On Monday, May 2, 2005, at 07:22 PM, Bob Wyman wrote: Antone Roundy asked: Category feeds: ... Should they, or feeds that combine category feeds present the entries like aggregated feeds? Yes, at least normally. An entry should have only one "source." On a site that has a "master

Re: PaceDuplicateIDWithSource

On Monday, May 2, 2005, at 05:33 PM, Graham wrote: These two statements conflict: It is harder to fake the URI from which a feed is actually read. as identified in a link element (with rel="self") and the atom:id of the entry. rel=self doesn't contain where the feed came from, it contains where

Re: PaceDuplicateIDWithSource2

On Monday, May 2, 2005, at 05:23 PM, Graham wrote: On 2 May 2005, at 10:03 pm, Antone Roundy wrote: The content of an atom:id element MUST be created in a way that, as nearly as possible, assures uniqueness. An atom:id value that has been used with one entry in a particular feed MUST NOT ever

Re: PaceDuplicateIDWithSource

On Monday, May 2, 2005, at 03:37 PM, Bob Wyman wrote: Antone Roundy wrote: multiple representations of the same entry resource could appear in a feed document as long as they were aggregated into the feed by different routes. Two rules: 1. You should only write a source element into an entry if

Re: PaceXhtmlDivSuggestedOnly

On Monday, May 2, 2005, at 03:27 PM, Thomas Broyer wrote: Antone Roundy wrote: I'd support forbidding any attributes other than (a) namespace declaration(s) on container elements...in fact, I'm going to add that to PaceXmlContentWrapper. Won't that complicate validation a l

Getting atom:source right

4.2.11 The "atom:source" Element If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it

PaceDuplicateIDWithSource2

http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2 This is what I thought had been suggested. Hopefully I didn't err in putting two changes into one proposal, but the first seemed a little odd without the acknowledgment provided by the second. Coming up with wording for the first c

Re: PaceDuplicateIDWithSource

On Monday, May 2, 2005, at 12:41 PM, Graham wrote: http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource Graham === Abstract Allow multiple version of an entry within a feed where the source id is different. Status Proposed Rationale The current spec does not allow multiple versions of

Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way!

On Monday, May 2, 2005, at 09:48 AM, Walter Underwood wrote: Counting impressions is essential to their trade, and you'll find that it is industry standard practice. Make that "was essential", and "should be a dying practice." Ads have moved to results-based billing, paying for clickthrough and

Re: PaceExplainDuplicateIds

On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: The proposed compromise to allow duplicate IDs in feeds, on the condition that a source element is present, doesn't address the problem of quick scripts that probably won't group duplicate IDs. I don't understand the last part of this s

Re: PaceXhtmlDivSuggestedOnly

On Saturday, April 30, 2005, at 12:03 PM, Thomas Broyer wrote: Graham wrote: The div is not part of the content, and inline content can safely appear within a div. I'm OK with that but I'm still bothered by putting my titles in a block-level element: because the div is still part of XHTML (even

Re: Cleanup phase - remaining Paces

The following Paces have not had their fate officially decided: PaceOptionalSummary (+1) PaceXmlContentWrapper (+1 -- there was plenty of opposition during the discussion of this one, but it seemed to be directed at both the current spec and the Pace, so I don't think it's clear whether people p

Re: On SHOULD, MUST, and semantics

On Wednesday, April 27, 2005, at 05:11 PM, Graham wrote: On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: My opinion is that ~10 WG members are currently clearly stating their belief that summary/content are optional. You should make clear that most of those people supported a misleading Pace th

Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint

On Wednesday, April 27, 2005, at 10:39 AM, Bob Wyman wrote: Certainly, people could rewrite the links and certainly they will if we modify the existing constraint to require it. However, I expect that at PubSub, we'll insist on verifying the existence the entry in the reputed source before we pu

Re: PaceOptionalSummary

On Wednesday, April 27, 2005, at 08:53 AM, Eric Scheid wrote: why not ... and the client agent can then present these to the user to select from. At present: atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" th

Re: PaceOptionalSummary

On Wednesday, April 27, 2005, at 04:21 AM, Brett Lindsley wrote: One reason for title only feeds is to address bandwidth limited devices. The server I set up provides the same feed in two different formats - one title only and the other with title/summary/etc. The end client can decide which fe

Re: PaceOptionalSummary

On Tuesday, April 26, 2005, at 05:48 PM, Roger B. wrote: That's not good enough. You have to demonstrate an interop problem to say SHOULD or MUST. Interop with *what*, Robert? What's the baseline? Interop with other Atom processing software. The spec is the baseline. The requirements of the spe

Re: PaceOptionalSummary

On Tuesday, April 26, 2005, at 02:49 PM, Graham wrote: So your app sends me an Atom document that looks like this: whetever So Caleb is Lindsey's father What does this mean? a) A title only feed b) A full entry with the summary missing. Without knowing this (which it wouldn't under Tim's proposa

Re: PaceOptionalSummary

On Monday, April 25, 2005, at 12:25 PM, Tim Bray wrote: I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary +1

Re: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray))

Dan Sandler wrote: This essentially means that intermediate entities which parse and re-emit Atom feed data (such as aggregators or caches) must remember "semantically meaningless" details, such as the order of elements, in order to re-construct the Atom feed XML in a way that preserves signatu

Re: PaceXmlContentWrapper

On Wednesday, April 20, 2005, at 04:24 AM, Henri Sivonen wrote: On Apr 20, 2005, at 11:53, Bill de hÓra wrote: Henri Sivonen wrote: On Apr 20, 2005, at 05:21, Graham wrote: iii) Require that xhtml and *xml content elements have only a single child node. That is, all xml must be wrapped in an encl

Re: NoIndex, again

I believe we decided not to address licensing in the Atom core because the probability of not getting it quite right is too high, especially given the differences between laws in various jurisdictions around the world. Having something in the core might require consuming applications to enforc

PaceXmlContentWrapper

It may be too late, but either way, I'd like to get this into concrete form. Does anyone think this is worse than requiring the xhtml:div? Better? http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper == Abstract == Replace the requirement for an xhtml:div wrapper for content[type="xhmtl

Re: One reason we have duplicates entries is that we have duplicate feeds...

On Tuesday, April 19, 2005, at 12:59 PM, Bob Wyman wrote: Bill de hÓra wrote: I'm going to think about it some more but atm I'm not sure what you're proposing helps against DOS. My proposal says that things are considered the same only if found in the same feed. This is, I believe, the only way t

Re: Trade mandatory xhtml:div for atom:content/@container?

On Friday, April 15, 2005, at 04:15 PM, Thomas Broyer wrote: Antone Roundy wrote: Could we drop the xhtml:div requirement in [EMAIL PROTECTED]"xhtml"], +1 and instead clarify the status of the div that is commonly being put there (is it part of the content or not?) +1 by adding an at

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

On Friday, April 15, 2005, at 03:51 PM, A. Pagaltzis wrote: * Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 23:05]: 2) It makes it more difficult to determine the type of data. We know it's XML, but to find out whether it's a flavor of XML that we know how to deal with, we have

Trade mandatory xhtml:div for atom:content/@container?

In case the idea was buried too deeply in my prior email[1], here it is in it's own message: Could we drop the xhtml:div requirement in [EMAIL PROTECTED]"xhtml"], and instead clarify the status of the div that is commonly being put there (is it part of the content or not?) by adding an attribut

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

On Friday, April 15, 2005, at 02:30 PM, A. Pagaltzis wrote: * A. Pagaltzis <[EMAIL PROTECTED]> [2005-04-15 20:20]: * Antone Roundy <[EMAIL PROTECTED]> [2005-04-15 00:10]: ... This is XHTML content, and the default namespace is XHTML's. I like this. A lot. One better, w

<    1   2   3   4   >