Atom Notification Protocol Update

I have just submitted an update to the Atom Notification Protocol draft that will hopefully be published in a day or so. I have attached the draft for review. Summary of changes: * Rather than POSTing atom:feed elements to indicate an updated feed, atom:head elements are POSTed. * Eliminated

Re: URI canonicalization

* Roy T. Fielding wrote: >It is not necessary for the format to require world peace, or >anything generally equivalent to it. Give implementations the >freedom to do whatever they like with the format -- just tell >them what the syntax means and the implementations will sort >themselves out. YMM

Re: URI canonicalization

On Jan 31, 2005, at 8:40 PM, Tim Bray wrote: Graham's right, the word "identical" is wrong, because in fact you will commonly encounter two instances of the same entry which aren't identical (e.g. the one in your cache and the one you just fetched). I suggest "Software MUST treat any two entrie

Re: URI canonicalization

There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but nobody cares because AT WORST the result is a bit of inefficient use

Re: URI canonicalization

On Jan 31, 2005, at 7:10 PM, Martin Duerst wrote: 5) Add a note saying something like "Comparison functions provided by many URI classes/implementations make additional assumptions about equality that are not true for Identity Constructs. Atom processors therefore should use simple stri

Re: URI canonicalization

At 13:20 05/02/01, Graham wrote: >On 1 Feb 2005, at 3:10 am, Martin Duerst wrote: >> 4) Add a sentence saying something like "Feeds or Entries >>are identical if their IDs compare identical.". >>Seems obvious, but isn't stated anywhere. > >No. Feeds/entries with the same id are different ve

Re: Feed State [was: Work Queue Rotation #16]

What registry? I don't think the examples you cite are the common case. The common case is "This Feed Document represents the last n entries in an ongoing information channel," or "This Feed Document represents entries within the last m units of time in an ongoing information channel." These ca

Re: Feed State [was: Work Queue Rotation #16]

On Jan 31, 2005, at 6:27 PM, Paul Hoffman wrote: At 3:46 PM -0800 1/31/05, Mark Nottingham wrote: If this is the direction we go in on this, that's fine with me, but I think that the spec needs to say *something* about managing feed state, Why? Because it's a *very* common use case, but we don't

Re: URI canonicalization

Robert Sayre wrote: 4) Add a sentence saying something like "Feeds or Entries are identical if their IDs compare identical.". Seems obvious, but isn't stated anywhere. No. Feeds/entries with the same id are different versions or instances of a common ancestor. They are not "the same". Mar

Re: URI canonicalization

Over here in the thread with technical commentary, Graham wrote: On 1 Feb 2005, at 3:10 am, Martin Duerst wrote: 1) switch sections 3.5.1 and 3.5.2 to make clear that comparison of IDs is the most important operation. Yes. I eliminated 3.5.1 as a distinct entity in this proposed edit: http://w

Re: URI canonicalization

On Jan 31, 2005, at 8:20 PM, Graham wrote: This makes it clear that we are talking about "here is how you do it", rather than "here's one way to do it". We might be treading on toes making that assertion. Yes, but it's not only correct, it's good advice, so we should put it in. 4) Add a sen

Re: PaceAggregationDocument posted

Antone Roundy wrote: My preferences: +1: Current draft or PaceAggregationDocument (with or without atom:feed/atom:head and with or without metadata for atom:aggregation (atom:aggregation/atom:head?)) +0.5: PaceFeedRecursive without any more indirection than we already have, and only one level of

Re: URI canonicalization

On 1 Feb 2005, at 3:10 am, Martin Duerst wrote: 1) switch sections 3.5.1 and 3.5.2 to make clear that comparison of IDs is the most important operation. Yes. This makes it clear that we are talking about "here is how you do it", rather than "here's one way to do it". We might be treading o

Re: PaceAggregationDocument posted

On Monday, January 31, 2005, at 08:51 PM, Robert Sayre wrote: Graham wrote: Both proposals suck equally. HeadInEntry is surprisingly elegant when you get to thinking about it. My preferences are as follows: 1.) PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and atom:content 2.) RDF (

Re: URI canonicalization

I have just looked at the text in question in -05.txt, and read through the discussion. I'll give my comments here, but they are not specifically on this mail. First, for me, the goal of having reproducible id comparison is most important; this is the basic requirement. Second, given that there are

Re: PaceAggregationDocument posted

Graham wrote: Both proposals suck equally. HeadInEntry is surprisingly elegant when you get to thinking about it. My preferences are as follows: 1.) PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and atom:content 2.) RDF (instead of the fake RDF in #4) 3.) "add an attribute to atom:e

Re: Feed State [was: Work Queue Rotation #16]

At 08:46 05/02/01, Mark Nottingham wrote: >[[[ >x. Managing Feed State > >Atom Processors MAY keep state (e.g., metadata in atom:head, entries) sourced from Atom Feed Documents and combine them with other Atom Feed Documents, in order to facilitate a contiguous view of the contents of the feed.

Re: Feed State [was: Work Queue Rotation #16]

Paul Hoffman wrote: What does that add to the document? A MAY with a hint of an extension doesn't seem to add much. I agree with Paul. The proposal doesn't really make sense unless there's a way to distinguish "this feed represents the current weather in Oaxaca" from "the latest entry represent

Re: Feed State [was: Work Queue Rotation #16]

At 3:46 PM -0800 1/31/05, Mark Nottingham wrote: If this is the direction we go in on this, that's fine with me, but I think that the spec needs to say *something* about managing feed state, Why? even if it's just this: [[[ x. Managing Feed State Atom Processors MAY keep state (e.g., metadata in

Re: PaceAggregationDocument posted

Both proposals suck equally. HeadInEntry is surprisingly elegant when you get to thinking about it. Graham smime.p7s Description: S/MIME cryptographic signature

Re: IRIs (was: Re: Work Queue Rotation #16)

At 22:25 31/01/2005, Graham wrote: I don't know much about IRIs. Is it possible to express them as URIs? As far as I understand, and this is my problem : I cannot have a formal response on the following. - there are various way to support a non ASCII IRI (the majority of the world needs them - in

Re: PaceAggregationDocument posted

On Jan 31, 2005, at 2:23 PM, Antone Roundy wrote: 4) PaceFeedRecursive eliminates atom:head. PaceAggregationDocument does not, though it leaves the door open for discussing whether to do so. That is kind of pointless. The main purpose of PaceFeedRecursive is to use XML hierarchy to clearly defin

Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published

Hello Mark, I have just responded in quite some detail to Robert, which should cover quite some of your questions. At 09:25 05/01/30, Mark Nottingham wrote: > >As I understand it, if I implement an Atom processor that doesn't support IRIs, It's not conformant, and will have problems with some vali

Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published

This is a pretty persuasive argument, IMO. There is always a natural profile of what is supported by most implementations; that shouldn't necessarily constrain the specs. Thanks, On Jan 31, 2005, at 3:46 PM, Martin Duerst wrote: Yes and no. Does the Atom spec require that an Atom processor suppo

Feed State [was: Work Queue Rotation #16]

On Jan 31, 2005, at 11:45 AM, Tim Bray wrote: PaceFeedState: If no further discussion: Like PaceSupersede, this model of publishing does not (so far) enjoy consensus support. Partially pro: 2 Contra: 0 Conclusion: Not enough interest. Close it. If this is the direction we go in on this, that's

Re: PaceAggregationDocument posted

On Monday, January 31, 2005, at 03:23 PM, Antone Roundy wrote: 1) PaceFeedRecursive enables aggregation by allowing the document element feed to contain other feeds (but those feeds may not contain yet other feeds). Correction: PaceFeedRecursive doesn't contain any language limiting the depth o

PaceAggregationDocument posted

http://www.intertwingly.net/wiki/pie/PaceAggregationDocument PaceAggregationDocument is an alternative to PaceFeedRecursive (and was largely cloned from PaceFeedRecursive). Both replace head-in-entry as a way to carry an entry's original context with it when aggregating feeds. The primary diff

Re: IRIs

Graham wrote: I don't know much about IRIs. Is it possible to express them as URIs? My read-the-draft-once understanding is that it is always possible to convert an IRI to a URI, but it may not be possible to convert a URI back to the same IRI it was generated from. For example, it is always po

RE: atom:host [was: Comments on format-05]

I thought atom:host was made redundant by the combination of HeadInEntry and FeedLink... bob wyman

Re: IRIs (was: Re: Work Queue Rotation #16)

I don't know much about IRIs. Is it possible to express them as URIs? Graham smime.p7s Description: S/MIME cryptographic signature

Re: Work Queue Rotation #16

On Monday, January 31, 2005, at 12:45 PM, Tim Bray wrote: === PaceEntriesAllTheWayDown: If no further discussion: This is a radical change to the document and, so far, hasn't gathered widespread enough support to make it over the li

IRIs (was: Re: Work Queue Rotation #16)

Tim Bray wrote: == PaceIRI If no further discussion: It's hard to see how to avoid adopting this now that IRIs are standards-track RFC. Pro: 2 Expressed neutral: 1 Contra: 0 Concerns about cost: 3 Conclusion: This is tough. There

PaceLinkRelVia

As requested: Feel free to make changes that do not have much impact and improve the quality of the message. By the way, should it be listed elsewhere? -- Anne van Kesteren

Work Queue Rotation #16

Atom Public Issues List: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList First off, a huge THANK-YOU to the group for taking this list of hard issues on and engaging in some really high-quality discussion and (mostly) being polite about it. Second, our "last call" attempt, as last ca

Re: Comments on format-05

On Jan 31, 2005, at 10:31 AM, Antone Roundy wrote: Another option would be to allow one with inline content, and alternative content by reference, eg. (not being careful about getting language tags correct): This is a pen http://foo.com/abc"; /> http://foo.com/aiu"; /> I think that's the same

Re: URI canonicalization

Bjoern Hoehrmann wrote: * Robert Sayre wrote: Suppose your user is subscribed to a feed containing 1000 entries. One day, the host name is no longer capitalized. Are you going to put 1000 new, duplicate entries in front of the user? It seems the Working Group is split on the requirements for dupl

Re: Comments on format-05

On Sunday, January 30, 2005, at 10:49 AM, Eric Scheid wrote: On 31/1/05 3:47 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: +1, but not just type attributes, also xml:lang variations please. -1. An Atom entry is *one* representation and you can link to alternates. I'm deeply unhappy that this was

Re: Obs on format-05

On Sunday, January 30, 2005, at 10:25 AM, Tim Bray wrote: ** @type ** The passages in 3.1.1 and 4.15.1 and 4.6.3 around @type are not consistent. In 3.1.1 media types are not an option: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] in 4.15.1

Re: Dereferencing Identity Constructs

On Jan 31, 2005, at 8:47 AM, Robert Sayre wrote: Paul Hoffman wrote: At 10:30 PM -0500 1/30/05, Robert Sayre wrote: Well, it seems silly to use a dereferencable scheme if you don't want the URI dereferenced. I agree, but there was broad WG consensus on this months ago. It is too late to revisit

Re: IRI - URI canonicalization

I am not sure this is relevant but all this is supporting IRI? jfc At 13:24 31/01/2005, Bjoern Hoehrmann wrote: * Robert Sayre wrote: >Suppose your user is subscribed to a feed containing 1000 entries. One >day, the host name is no longer capitalized. Are you going to put 1000 >new, duplicate entr

Re: URI canonicalization

On Sunday, January 30, 2005, at 05:43 PM, Robert Sayre wrote: How about "Make sure your id is unique from a character-by-character perspective, but also unique in the face of scheme-specific comparisons". That is, don't lean on scheme-specific comparisons to match URIs, but they don't have to b

Re: Dereferencing Identity Constructs

At 11:47 AM -0500 1/31/05, Robert Sayre wrote: How about this: [Last sentence of the first paragraph, combined 3.5.1 and 3.5, altered first paragraph in "Comparing"] 3.5 Identity Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier

Re: Dereferencing Identity Constructs

Paul Hoffman wrote: At 10:30 PM -0500 1/30/05, Robert Sayre wrote: Well, it seems silly to use a dereferencable scheme if you don't want the URI dereferenced. I agree, but there was broad WG consensus on this months ago. It is too late to revisit that now. Not what I meant. Secondly, I fail to

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt

On Jan 31, 2005, at 16:05, Julian Reschke wrote: Can't we just get rid of the defaulting? That would make the spec simpler with little additional verbosity in the instance documents. If there is no default, someone will still omit the attribute and consumers will try to cope. I think it is better

Re: Dereferencing Identity Constructs

H. The dead horse comes to life with more beating. At the risk of causing further consternation and time-wasting... At 7:28 PM -0800 1/30/05, Mark Nottingham wrote: How about "Dereferencability of Identity Constructs"? Works for me. At 10:30 PM -0500 1/30/05, Robert Sayre wrote: Well, it seem

Re: Dereferencing Identity Constructs

On 31 Jan 2005, at 3:40 pm, Tim Bray wrote: Uh, it seems that you're assuming that "can be dereferenced" is equivalent to "will be unstable". I disagree. -Tim I agree it's possible for links to be stable. But giving the id a functional purpose as an address introduces all sorts of reasons to ch

Re: Dereferencing Identity Constructs

On Sun, 30 Jan 2005 19:28:05 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > How about "Dereferencability of Identity Constructs"? That should discourage most everyone from reading that section. Lance

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Tim Bray wrote: On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote: 05-C05, 4.15.3 processing model "If the value of "type" begins with "text/" the content of atom:content MUST NOT contain child elements." See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's

Re: Dereferencing Identity Constructs

* Henry Story <[EMAIL PROTECTED]> [2005-01-31 16:25+0100] > > On 31 Jan 2005, at 05:22, Tim Bray wrote: > >On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote: > > > >>> The content of an Identity construct SHOULD NOT be dereferenced, > >>>even when it comes from a > >>> normally dereferencabl

Re: Dereferencing Identity Constructs

On Jan 31, 2005, at 6:53 AM, Graham wrote: Absolutely not Joe times one billion. Any such convention forming jeopardises the persistence of the identifier, since it will get changed when people re-organize their site or fiddle with their features. The id is an identifier and nothing else. Lettin

Re: Posted PaceTextRules

On Jan 31, 2005, at 5:37 AM, Bjoern Hoehrmann wrote: * Tim Bray wrote: Currently, the draft says *nothing* about xml:space (unless I'm mis-using the search function). If you read the specification for xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says is that this is a message

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote: 05-C05, 4.15.3 processing model "If the value of "type" begins with "text/" the content of atom:content MUST NOT contain child elements." See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's a MUST then <

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt

On Jan 30, 2005, at 11:58 PM, Henri Sivonen wrote: I don't want to refer to OASIS's URLs. Why not? Will ISO-Relax NG be available on the Web free of charge? Specs that are available free of charge on the Web win. Indeed. And what's wrong with OASIS URL's? -Tim

Re: Dereferencing Identity Constructs

On 31 Jan 2005, at 05:22, Tim Bray wrote: On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote: The content of an Identity construct SHOULD NOT be dereferenced, even when it comes from a normally dereferencable scheme. There is no requirement for the content to represent a URI where a versi

Re: atom:info [was Re: Comments on format-05]

Sam Ruby wrote: Interoperability will be improved if we can nail down what are valid media types that atom feeds can be served with, and what are invalid media types that should always be rejected. We can build voluntary conformance test suites for aggregator developers to test against. The fe

Re: Dereferencing Identity Constructs

On 31 Jan 2005, at 4:08 am, Joe Gregorio wrote: I disagree with Graham in that someone may come up with a good thing to stick at the resource that an Identity construct points at (the lessons of XML namespaces not withstanding). Absolutely not Joe times one billion. Any such convention forming je

Re: atom:info [was Re: Comments on format-05]

Robert Sayre wrote: In the subscribe dialog, I always know what the appropriate agent is. What makes you think "standards" dictate some other behavior? Counter example: one that is all too common. If you get back something with a content type of text/html, what you are probably getting back is

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Julian Reschke wrote: Robert Sayre wrote: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of "alternate".' Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of "alternate".' Can't we just get rid of

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Robert Sayre wrote: Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of "alternate".' Can't we just get rid of the defaulting? That would make the spec simpler with little additional verbosity in the instance documents. In this case, my pref

Re: atom:info [was Re: Comments on format-05]

Bjoern Hoehrmann wrote: * Robert Sayre wrote: If I tell NetNewsWire to GET something in the subscribe dialog, my dispatching instructions are clear. Everything is a feed. Making up rules for application/xml, text/xml, and application/octet-stream will require superceding some RFCs that I'd ra

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Robert Sayre wrote: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of "alternate".' Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of "alternate".' Can't we just get rid of the defaulting? That wo

Re: atom:info [was Re: Comments on format-05]

* Robert Sayre wrote: >If I tell NetNewsWire to GET something in the subscribe dialog, my >dispatching instructions are clear. Everything is a feed. Making up >rules for application/xml, text/xml, and application/octet-stream will >require superceding some RFCs that I'd rather not mess with. W

Re: Posted PaceTextRules

* Tim Bray wrote: >Currently, the draft says *nothing* about xml:space (unless I'm >mis-using the search function). If you read the specification for >xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says >is that this is a message from the author to downstream software. So

Re: URI canonicalization

* Robert Sayre wrote: >Suppose your user is subscribed to a feed containing 1000 entries. One >day, the host name is no longer capitalized. Are you going to put 1000 >new, duplicate entries in front of the user? It seems the Working Group is split on the requirements for duplicate detection, we

Re: Dereferencing Identity Constructs

Graham wrote: The content of an Identity construct SHOULD NOT be dereferenced, Graham, Would you go with "..MUST NOT rely on dereferencing.." instead? cheers Bill

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Julian Reschke wrote: Thanks for the feedback, Robert... Robert Sayre wrote: - "rel" attribute is missing The rel attribute is optional and the relation is considered to be "alternate" in that case. http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt

Henri Sivonen wrote: On Jan 31, 2005, at 00:53, Robert Sayre wrote: I think this should come with the following URL: I don't want to refer to OASIS's URLs. Why not? Will ISO-Relax NG be available on the Web free of charge? Specs

Re: atom:info [was Re: Comments on format-05]

Mark Nottingham wrote: And, if you use XSLT, it's also possible to do it all in-stylesheet, with or without links. Safari (and probably other things) don't do XSLT. Fair enough. Safari is said to get a (libxml-based) XSLT engine in the next major upgrade. Best regards, Julian -- bytes GmbH --

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Sam Ruby wrote: Julian Reschke wrote: http://www.w3.org/1999/xhtml";> Less: < (hope I got these right). This is not only right, but also a good example of why many people would prefer to have another element so that they don't have to deal with prefixes: http://www.w3.org/1999/xhtml

Re: Dereferencing Identity Constructs

On 31 Jan 2005, at 4:22 am, Tim Bray wrote: OFor "ongoing", I plan to use the same http: URIs for both the and ; I will manage (and have managed) my URI space so that they will meet the requirements of permanence, uniqueness, and so on. In this case the URI will absolutely be dereferenced, b

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt

On Jan 31, 2005, at 00:53, Robert Sayre wrote: I think this should come with the following URL: I don't want to refer to OASIS's URLs. Why not? Will ISO-Relax NG be available on the Web free of charge? Specs that are available fr

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Thanks for the feedback, Robert... Robert Sayre wrote: - "rel" attribute is missing The rel attribute is optional and the relation is considered to be "alternate" in that case. http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute

Re: Obs on format-05

Robert Sayre wrote: Agree. -1. Bill needs a private content model. Removing the content model from Atom will not fix that. I suggest something like "text/bill+xml". Making general-purpose feeds available where one consumer will only ever use half of the content is bad practice. Use two resource

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-form at-05.txt

On Jan 31, 2005, at 01:32, Sam Ruby wrote: Julian Reschke wrote: http://www.w3.org/1999/xhtml";> Less: < (hope I got these right). This is not only right, but also a good example of why many people would prefer to have another element so that they don't have to deal with prefixes: Their seri

Re: Posted PaceTextRules

On Jan 31, 2005, at 03:00, Graham wrote: "Software displaying this text SHOULD remove white-space at the beginning and end; collapse white-space between words; and disregard line break, tab and other formatting characters." in 3.1.1 (TEXT). +1 with the minor nit that lone line breaks should be co

Re: Issues with draft-ietf-atompub-format-04

On Jan 31, 2005, at 03:11, Asbjørn Ulsberg wrote: On Sun, 30 Jan 2005 22:06:23 +0200, Henri Sivonen <[EMAIL PROTECTED]> wrote: So how many European sites besides the EU have the resources to provide translations of the *same* content in multiple languages at the same time? The company I work in