Re: Fetch Me A Rock
* David Nesting <[EMAIL PROTECTED]> [2005-05-13 15:25]: > It is therefore up to us to clarify: > >A summary SHOULD* be present in an entry. Implementations >MUST be capable of processing entries with and without >summaries (title-only feeds). This is not intended to >suggest that implementations must do something useful with >title-only entries. +1 Regards, -- Aristotle
Re: Fetch Me A Rock
David Nesting wrote: On Thu, May 12, 2005 at 03:46:21PM -0600, Antone Roundy wrote: The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. So because both RFC 2119 and the current Atom draft are not explicit on this point, it is open either to varied interpretations, or at least to misinterpretations. It is therefore up to us to clarify: A summary SHOULD* be present in an entry. Implementations MUST be capable of processing entries with and without summaries (title-only feeds). This is not intended to suggest that implementations must do something useful with title-only entries. * - The "implications" are that many processors will ignore or reject entries that do not have summaries, because the processor may place the emphasis of its processing on the summary. The feed as a whole is still valid, however, and it's expected that processors will handle entries that DO have summaries in the same feed as entries that do NOT. Very nice. - Sam Ruby
Re: Fetch Me A Rock
On Thu, May 12, 2005 at 03:46:21PM -0600, Antone Roundy wrote: > > >The problem we have, as I pointed out earlier on the thread, is that > >we do not specify whether senders and receivers have the same SHOULD. > >I made one assumption, and Rob pointed out that I had made one > >different than he did. > > So because both RFC 2119 and the current Atom draft are not explicit on > this point, it is open either to varied interpretations, or at least to > misinterpretations. It is therefore up to us to clarify: A summary SHOULD* be present in an entry. Implementations MUST be capable of processing entries with and without summaries (title-only feeds). This is not intended to suggest that implementations must do something useful with title-only entries. * - The "implications" are that many processors will ignore or reject entries that do not have summaries, because the processor may place the emphasis of its processing on the summary. The feed as a whole is still valid, however, and it's expected that processors will handle entries that DO have summaries in the same feed as entries that do NOT. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
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 NOT REQUIRE implementations to interoperate with implementations that don't follow the recommendation. Otherwise, would that not have been spelled out? What are "the full implications", if not the possibility of failed interoperability? Reduced functionality? I don't think so, because that is what MAY is about. You are reading *way* too much into 2119; this is a normal thing to do. I realize I was going beyond what it actually says, thus: RFC 2119 isn't explicit on this point. and: Perhaps the best we can do from that document is to attempt to divine from what it says about MAY, what it means about SHOULD, but I don't know whether this is valid or not. The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. So because both RFC 2119 and the current Atom draft are not explicit on this point, it is open either to varied interpretations, or at least to misinterpretations. The way I read 2119 is that if a sender MAY or SHOULD include something, the receiver MUST NOT fall over if it is in what they receive, and MUST NOT fall over if it is not in what they receive. Does that clarify where I got to on this thread? Fortunately, as you suggest above, we can resolve the issue at hand by clarifying our spec (by explicitly stating the SHOULDs, MUSTs and MAYs for both the producer and consumer)...if we can come to consensus on what we want, that is! That would probably be a lot easier than coming to consensus on the one true reading of RFC 2119 and figuring out how to apply it to the Atom spec.
Re: Fetch Me A Rock
At 1:07 PM -0600 5/12/05, Antone Roundy wrote: 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 you mean by "interoperate". Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element". Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 a) ...and MUST NOT have more than one # Atom 1.0 RFC says entries MAY have one atom:foo3 b) ...and MUST NOT have more than one Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. c) ...if it exists If you find more than one atom:foo3, fail. Process the atom:foo3. d) ...if it exists Paul, I presume a, b, c and d are what you intended? Yes, thank you. See why I'm not a developer? :-) So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? So what we're discussing here is whether: "If you find more than one atom:foo2, fail. Process the atom:foo2 if it exists." ...should be this instead: "If you find more than one atom:foo2, fail. If you don't find an atom:foo2, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists." RFC 2119 isn't explicit on this point. Here's all it says about SHOULD: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Perhaps the best we can do from that document is to attempt to divine from what it says about MAY, what it means about SHOULD, but I don't know whether this is valid or not. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 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 NOT REQUIRE implementations to interoperate with implementations that don't follow the recommendation. Otherwise, would that not have been spelled out? What are "the full implications", if not the possibility of failed interoperability? Reduced functionality? I don't think so, because that is what MAY is about. You are reading *way* too much into 2119; this is a normal thing to do. The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. The way I read 2119 is that if a sender MAY or SHOULD include something, the receiver MUST NOT fall over if it is in what they receive, and MUST NOT fall over if it is not in what they receive. Does that clarify where I got to on this thread? --Paul Hoffman, Director --Internet Mail Consortium
Re: Fetch Me A Rock
On 13/5/05 5:14 AM, "Julian Reschke" <[EMAIL PROTECTED]> wrote: >> Why not? If the text says something to the effect of, for example, >> "SHOULD include an atom:summary element unless there really is no >> summary", then title-only feeds are fine. > > :-) > > Adding "unless there really is no summary" of course changes the meaning > in a way that *is* compatible with title-only feeds. So can we change > the spec to say that? +1 except that excludes other scenarios... For example: ... ... ... ... where the resource/representation retrievable from @href would include all the other elements (content, summary, author, category, copyright, etc etc). Thus, the 'entry' really does have a summary, but it's just not in the feed. If someone wants to write an aggregator/reader which expects everything to be right there in the feed, then sure, they can happily fail. Or more properly, they can say "we don't support that functionality". Just like how some web browsers don't support displaying images inline with the page ... they don't say "ick, spit, nasty pages, broken pages, has evil tags, it's broken broken broken". No, they simply don't support that functionality. e.
Re: Fetch Me A Rock
Julian Reschke wrote:
Paul Hoffman wrote:
Why not? If the text says something to the effect of, for example,
"SHOULD include an atom:summary element unless there really is no
summary", then title-only feeds are fine.
:-)
Adding "unless there really is no summary" of course changes the meaning
in a way that *is* compatible with title-only feeds. So can we change
the spec to say that?
No, because you usually provide title-only feeds not because you don't
have any content available but because title-only feeds:
1. are smaller and then meet wireless devices constraints (especially
reduced bandwidth)
2. meet some users/software needs (a "news ticker" displaying only
titles, or people who just want to be advised when something new is
available no matter really about its content)
IMO, the PaceTextShouldBeProvided thingy should go in an *informative*
appendix ("Interoperability considerations"): the spec _allows_
title-only feeds (normative) but authors _recommend_ providing textual
content or an alternative feed including such textual content. This is
an advice, nothing more (or less).
--
Thomas Broyer
Re: Fetch Me A Rock
On 13/5/05 5:07 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > "If you find more than one atom:foo2, fail. Process the atom:foo2 if it > exists." > > ...should be this instead: > > "If you find more than one atom:foo2, fail. If you don't find an > atom:foo2, you are allowed to fail and still call yourself Atom > compliant. Process the atom:foo2 if it exists." I'd say it should be this instead: "If you find more than one atom:foo2, fail. If you don't find an atom:foo2, * and you really, really need it, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists." Examples of "need it": a search robot that is looking for either summary or content a spammer tool that searches for email addresses in author elements (yes, I know that's a MAY) e.
Re: Fetch Me A Rock
Paul Hoffman wrote: At 8:32 PM +0200 5/12/05, Julian Reschke wrote: Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3 Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. If you find more than one atom:foo3, fail. Process the atom:foo3. I agree with the analysis. So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? Why not? If the text says something to the effect of, for example, "SHOULD include an atom:summary element unless there really is no summary", then title-only feeds are fine. :-) Adding "unless there really is no summary" of course changes the meaning in a way that *is* compatible with title-only feeds. So can we change the spec to say that? Best regards, Julian
Re: Fetch Me A Rock
At 8:32 PM +0200 5/12/05, Julian Reschke wrote: Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3 Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. If you find more than one atom:foo3, fail. Process the atom:foo3. I agree with the analysis. So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? Why not? If the text says something to the effect of, for example, "SHOULD include an atom:summary element unless there really is no summary", then title-only feeds are fine. --Paul Hoffman, Director --Internet Mail Consortium
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 you mean by "interoperate". Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element". Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 a) ...and MUST NOT have more than one # Atom 1.0 RFC says entries MAY have one atom:foo3 b) ...and MUST NOT have more than one Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. c) ...if it exists If you find more than one atom:foo3, fail. Process the atom:foo3. d) ...if it exists Paul, I presume a, b, c and d are what you intended? So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? So what we're discussing here is whether: "If you find more than one atom:foo2, fail. Process the atom:foo2 if it exists." ...should be this instead: "If you find more than one atom:foo2, fail. If you don't find an atom:foo2, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists." RFC 2119 isn't explicit on this point. Here's all it says about SHOULD: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Perhaps the best we can do from that document is to attempt to divine from what it says about MAY, what it means about SHOULD, but I don't know whether this is valid or not. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 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 NOT REQUIRE implementations to interoperate with implementations that don't follow the recommendation. Otherwise, would that not have been spelled out? What are "the full implications", if not the possibility of failed interoperability? Reduced functionality? I don't think so, because that is what MAY is about.
Re: Fetch Me A Rock
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 you mean by "interoperate". Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element". Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3 Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. If you find more than one atom:foo3, fail. Process the atom:foo3. I agree with the analysis. So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? ... Best regards, Julian
Re: Fetch Me A Rock
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 you mean by "interoperate". Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element". Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3 Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. If you find more than one atom:foo3, fail. Process the atom:foo3. At 1:18 PM -0400 5/12/05, Robert Sayre wrote: On 5/12/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > > At 11:38 AM -0400 5/11/05, Robert Sayre wrote: >Remember, if we say SHOULD, that means >implementations don't have to interoperate ... ...snip... > elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what you mean by "interoperate". That sentence seems to apply to the conformance level known as MAY. Similar to MAY, yes. Senders may or may not send depending on the reason given; receivers must be ready to accept with it present or not. At 1:20 PM -0400 5/12/05, Robert Sayre wrote: On 5/12/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > Thus spake RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there ...snip... > you are applying your interpretation to. Please be specific: is it the current draft, a particular Pace, or a particular group of Paces? PaceTextShouldBeProvided. Thank you. That Pace, in essence, adds a bunch of "SHOULD NOT be empty" statements without saying when it is or is not acceptable to be empty. I understood those additional SHOULD NOTs to be for sending implementations, not for receiving implementations. However, that understanding came from the mailing list, not the spec itself. If your issue was that you saw them as relevant for both senders and receivers, that's a valid concern. The Pace should be written to be clearer who the SHOULD applies to. Separately, I would like to see the Pace specify in case what scenarios empty values would be allowed. I trust you'll apply a similar standard of specifity to other members of this working group. Don't put your trust in fools. --Paul Hoffman, Director --Internet Mail Consortium
Re: Fetch Me A Rock
On 5/12/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > Thus spake RFC 2119: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > At 11:18 PM -0400 5/11/05, Robert Sayre wrote: > >My interpretation is correct. > > That's impossible to assess because you haven't said which wording > you are applying your interpretation to. Please be specific: is it > the current draft, a particular Pace, or a particular group of Paces? PaceTextShouldBeProvided. I trust you'll apply a similar standard of specifity to other members of this working group. > >SHOULD does not mean "encourage". Remember that. > > Fully agree. > > >I'm not going argue any more. > > Fully disagree. bye, Robert Sayre
Re: Fetch Me A Rock
Paul Hoffman wrote: Thus spake RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ...and I think that what we need to do is to define what these "full implications" are. ... Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. 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 you mean by "interoperate". Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element". ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Fetch Me A Rock
On 5/12/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > > At 11:38 AM -0400 5/11/05, Robert Sayre wrote: > >Remember, if we say SHOULD, that means > >implementations don't have to interoperate with people who don't > >provide a summary. > > 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 you mean by "interoperate". That sentence seems to apply to the conformance level known as MAY. "In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)" Otherwise, I'm not sure what you mean. Robert Sayre
Re: Fetch Me A Rock
Thus spake RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. At 11:18 PM -0400 5/11/05, Robert Sayre wrote: My interpretation is correct. That's impossible to assess because you haven't said which wording you are applying your interpretation to. Please be specific: is it the current draft, a particular Pace, or a particular group of Paces? At 11:38 AM -0400 5/11/05, Robert Sayre wrote: Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. 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 you mean by "interoperate". That does not mean 'doesn't display' or 'doesn't index', despite what some would have you believe. It means the Atom Processor is allowed to fail. Fully disagree. SHOULD does not mean "encourage". Remember that. Fully agree. I'm not going argue any more. Fully disagree. --Paul Hoffman, Director --Internet Mail Consortium
Re: Fetch Me A Rock
On 5/11/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > Robert Sayre wrote: > > > > They'll give you ten different definitions of SHOULD, but there's only > > one that matters. Remember, if we say SHOULD, that means > > implementations don't have to interoperate with people who don't > > provide a summary. That does not mean 'doesn't display' or 'doesn't > > index', despite what some would have you believe. It means the Atom > > Processor is allowed to fail. It doesn't matter if that's not what we > > meant. The document's meaning would be unambiguous. > > Are we looking at the same document? My interpretation is correct. Robert Sayre
Re: Fetch Me A Rock
Robert Sayre wrote: They'll give you ten different definitions of SHOULD, but there's only one that matters. Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. That does not mean 'doesn't display' or 'doesn't index', despite what some would have you believe. It means the Atom Processor is allowed to fail. It doesn't matter if that's not what we meant. The document's meaning would be unambiguous. Are we looking at the same document? curl -s http://www.ietf.org/rfc/rfc2119.txt | grep -i fail | wc http://www.imc.org/atom-syntax/mail-archive/msg14533.html - Sam Ruby
Re: Fetch Me A Rock
On 5/11/05, Martin Duerst <[EMAIL PROTECTED]> wrote: > Hello Robert, > > I agree that summaries should be optional. > > I think one possible kind of solution that could help > both you and Sam/Graham Martin, compromise is called for when there are competing technical concerns. Sam/Graham refuse to state their technical concerns. What does a MAY prevent them from doing? If there is nothing, it is an abuse of the process. Robert Sayre
Re: Fetch Me A Rock
Hello Robert, I agree that summaries should be optional. I think one possible kind of solution that could help both you and Sam/Graham would be to say the following: - Atom processors MUST accept entries without summary/... - Atom documents SHOULD contain actual text. This hopefully would make it obvious that a SHOULD on the document doesn't give processors any licence to fail. The spec could even go further and say something about where the SHOULD would be expected to not be satisfied. Regards,Martin. At 00:38 05/05/12, Robert Sayre wrote: > >"Fetch me a rock. No, not that one. Fetch me another. Now jump >through this hoop." > >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. > >I am disappointed we are putting up with it, but I am not surprised. >They'll give you ten different definitions of SHOULD, but there's only >one that matters. Remember, if we say SHOULD, that means >implementations don't have to interoperate with people who don't >provide a summary. That does not mean 'doesn't display' or 'doesn't >index', despite what some would have you believe. It means the Atom >Processor is allowed to fail. It doesn't matter if that's not what we >meant. The document's meaning would be unambiguous. > >SHOULD does not mean "encourage". Remember that. > >I'm not going argue any more. My opinion is clear, strong, and >supported by many others. > >Robert Sayre
Re: Fetch Me A Rock
Replying to the note mentioned in Antone Roundy's blog entry [1] I would say that there are only 2 things that need to be a MUST in entries appearing in a feed are: - atom:id - atom:updated The above assumes the atom:id can be used to dereference the entry. If it can't another url needs to be provided that can be used to dereference the entry. But that is all that is needed in a feed. A feed is just a list of state changes to resources that readers of the feed may be interested in knowing about. Henry [1] http://www.geckotribe.com/ibl/b/2005/05/too-many-cooks-spoil-feed- format.php On 11 May 2005, at 17:38, Robert Sayre wrote: "Fetch me a rock. No, not that one. Fetch me another. Now jump through this hoop." 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. I am disappointed we are putting up with it, but I am not surprised. They'll give you ten different definitions of SHOULD, but there's only one that matters. Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. That does not mean 'doesn't display' or 'doesn't index', despite what some would have you believe. It means the Atom Processor is allowed to fail. It doesn't matter if that's not what we meant. The document's meaning would be unambiguous. SHOULD does not mean "encourage". Remember that. I'm not going argue any more. My opinion is clear, strong, and supported by many others. Robert Sayre
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? I haven't yet seen an explanation of how this solves any problem. Can you step us through the process that one would use under this proposal to: detect duplicates, detect DOS attempts, or any other goals relevant to the Pace? Can you explain how this Pace changes and/or improves the process or its results over the current draft? +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 Especially this late in the game, doesn't a proposal have to clear a higher bar than this to be accepted? > It doesn't address the DOS problem--neither > accidental nor intentional. Oh yes it does. Each entry's provenance is documented. The data format accurately states that the intermediary has munged the original entry. If it does solve the DOS problem (if), then as far as I can tell, it does it by reintroducing the duplicates problem. Does an aggregator show both the original and the copy, or just one of the two? What happens when someone spoofs both the feed ID and the entry ID? Also, a more general question directed to everyone (not people other than Robert couldn't respond to the above, of course)--if someone republishes an entry from another feed, how much/in what ways may they annotate or otherwise alter it while preserving the original ID? Adding elements to annotate it might be fair game. Modifying the contents of existing elements feels out of bounds--that makes it a different entry. It can LINK to the original (...if there is a way to link to the original) in that case, but it isn't the original anymore. What about dropping elements from the original (eg. dropping atom:content, and keeping only atom:summary)?
Fetch Me A Rock
"Fetch me a rock. No, not that one. Fetch me another. Now jump through this hoop." 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. I am disappointed we are putting up with it, but I am not surprised. They'll give you ten different definitions of SHOULD, but there's only one that matters. Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. That does not mean 'doesn't display' or 'doesn't index', despite what some would have you believe. It means the Atom Processor is allowed to fail. It doesn't matter if that's not what we meant. The document's meaning would be unambiguous. SHOULD does not mean "encourage". Remember that. I'm not going argue any more. My opinion is clear, strong, and supported by many others. Robert Sayre
