Subject: Fetch Me A Rock

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 11:38:38 -0400

"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

---

From: Antone Roundy <[email-masked]>
Date: Wed, 11 May 2005 10:25:13 -0600

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

---

From: Henry Story <[email-masked]>
Date: Wed, 11 May 2005 23:41:41 +0200

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

---

From: Martin Duerst <[email-masked]>
Date: Thu, 12 May 2005 09:23:07 +0900

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.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 21:43:12 -0400

On 5/11/05, Martin Duerst <[email-masked]> wrote:
> 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

---

From: Sam Ruby <[email-masked]>
Date: Wed, 11 May 2005 23:16:02 -0400

> 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

---

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 23:18:38 -0400

> Are we looking at the same document?

My interpretation is correct.

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2005 10:05:17 -0700

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.

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

---

From: Robert Sayre <[email-masked]>
Date: Thu, 12 May 2005 13:18:01 -0400

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 May 2005 19:16:08 +0200

>    carefully weighed before choosing a different course.

...and I think that what we need to do is to define what these "full 
implications" are.

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

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Robert Sayre <[email-masked]>
Date: Thu, 12 May 2005 13:20:58 -0400

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

> >I'm not going argue any more.

bye,

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2005 10:41:47 -0700

At 7:16 PM +0200 5/12/05, Julian Reschke wrote:
>>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:
>>  >implementations don't have to interoperate ...
>...snip...

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

Don't put your trust in fools.

--Paul Hoffman, Director

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 May 2005 20:32:16 +0200

Paul Hoffman 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):
> 

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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 12 May 2005 13:07:50 -0600

>> # 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
>> If you find more than one atom:foo2, fail.
c) ...if it exists
>> If you find more than one atom:foo3, fail.
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:

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.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2005 12:07:10 -0700

>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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 May 2005 21:14:24 +0200

> 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

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 05:51:10 +1000

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

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 12 May 2005 21:56:18 +0200

>  in a way that *is* compatible with title-only feeds. So can we change 

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

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 06:01:48 +1000

+1

except that excludes other scenarios...

For example:

    <entry>
        <id>...</id>
        <updated>...</updated>
        <title>...</title>
        <link rel="self" type="application/atom+xml" href="..."/>
    </entry>

... 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 <img> tags,
it's broken broken broken". No, they simply don't support that
functionality.

e.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2005 13:11:52 -0700

At 1:07 PM -0600 5/12/05, Antone Roundy wrote:
>>>>>elements, regardless if they are defined as MAY sent, SHOULD 
>>>>>send, or MUST send, so I'm not sure what you mean by 
>>>>>"interoperate".
>>>>

Yes, thank you. See why I'm not a developer? :-)

>"If you find more than one atom:foo2, fail. Process the atom:foo2 if 
>it exists."
>
>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.
>
>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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 12 May 2005 15:46:21 -0600

On Thursday, May 12, 2005, at 02:11  PM, Paul Hoffman wrote:
>> call out any such requirements.  This omission suggests to me that 
>> the intent of SHOULD is to NOT REQUIRE implementations to 

I realize I was going beyond what it actually says, thus:

>> RFC 2119 isn't explicit on this point.

> I made one assumption, and Rob pointed out that I had made one 

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.

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

---

From: David Nesting <[email-masked]>
Date: Fri, 13 May 2005 08:16:26 -0500

> this point, it is open either to varied interpretations, or at least to 

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-masked] http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01

---

From: Sam Ruby <[email-masked]>
Date: Fri, 13 May 2005 10:20:02 -0400

> that DO have summaries in the same feed as entries that do NOT.

Very nice.

- Sam Ruby

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 13 May 2005 19:08:58 +0200

* David Nesting <[email-masked]> [2005-05-13 15:25]:
>    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