Subject: On SHOULD

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 13:31:48 -0400

Off-list, I've been told some it would help to explain my view that
PaceTextShouldBeProvided and PaceOptionalSummary are incompatible.

---------------------------------------

First, remember that PaceOptionalSummary does one thing--make
content/summary optional. This means that Atom Processors MUST be
prepared to interoperate with title-only feeds. It doesn't mean an
_application_ has to accept them. It does mean that application
authors can't claim it breaks their Atom machinery. We don't care what
applications do after something is parsed. They can turn everything
purple and display it with polar coordinates.

Let's start with the current draft's requirements:

1 of atom:content or atom:summary MUST be present.

That's clear. It means that say, Jakarta FeedParser, could halt and
catch fire if it encountered an atom:entry missing both elements.

PaceOptionalSummary dismissed the requirement entirely, as its only
action. Jakarta FeedParser would have to be prepared to deal with
title-only feeds.

---------------------------------------

Here's where SHOULD comes in. We're lucky that we have an example of
what happens when a SHOULD is violated. I'm sure most of you saw the
nasty arguments, accusations, and all-around busted software that
happen this week with Google Web Accelerator and Ruby On Rails.[0]
Ugly, right? This WG should be proud that we've kept the SHOULDs to a
minimum.

PaceTextShouldBeProvided proposes a number of (IMO) misguided a
requirements in effort to reverse the effect of PaceOptionalSummary.
It proposes that "<summary></summary>" is threat to interop while
"<summary> </summary>" is not. It makes similar claims for a number of
other situations. It does reasonably propose that application-specific
atom:content SHOULD have an accompanying summary.

Lastly, it makes this requirement:
1 of atom:content or atom:summary SHOULD be present.

It means that say, Jakarta FeedParser, could halt and catch fire if it
encountered an atom:entry missing both elements and remain conformant.
It does allow for the possibility of a parser that can handle it.

That's not what PaceOptionalSummary proposed. The discussion has heard
from application authors and publishers who value the ability to
choose title-only feeds. That choice *does not* cause breakage, as
every existing format and processor demonstrate.
PaceTextShouldBeProvided loses the running code argument by an even
wider margin than it loses elsewhere.

Robert Sayre

[0] http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html

---

From: Sam Ruby <[email-masked]>
Date: Thu, 12 May 2005 16:43:38 -0400

People seem confused about RFC 2119.

If it helps, here is an example.  But, be aware, it is JUST an example 
at this point.  I'd like to be able to discuss it without people 
questioning each other's commercial viability, personal relevance to 
this process, or talking about things "caching fire" or the like, OK?

I'm also staying away from "atom:summary" for the the moment as there 
continues to be more heat than light in that particular conversation.

With that in mind, I suggest that the following are roughly equivalent:

     atom:title MAY be empty, but be aware that if it is empty, the
     recipient MAY chose to ignore the entire entry.

     atom:title SHOULD NOT be empty, lest the recipient choses to ignore
     the entire entry.

While the latter is slightly stronger, what is being conveyed in each 
case is "you are free to do this, but be aware that there are 
implications that you need to consider".  This is not meant as a value 
judgment.  And to illustrate this example, I offer the following for 
Firefox users:

   http://intertwingly.net/stories/2005/05/12/

Even with this example in mind, things are not cut and dry:

     We could decide as a group that titles MUST be present and not
     empty.  Even knowing that this means that somewhere that somebody
     will create a feed either ignoring this requirement.  And it might
     even work.  But when things break, it is clear who to blame.

     We could decide as a group that titles SHOULD be present and not
     empty.  This puts both parties on notice.  If you include it, more
     things work.  If you don't, many things will still work.
     Furthermore, people who parse feeds are put on notice that from
     time to time they will encounter entries with empty titles.

     We could decide as a group that titles are completely OPTIONAL.
     This is pretty much the reverse of the MUST case above.  If things
     break, it is the recipient who is to blame.

I claim that we are free to pick amongst all three of these 
alternatives.  We would also shunt this issue off to a Best Current 
Practices document.

What's worse, there is no magic numbers to guide us in this decision. 
Examples of things you WON'T find: "if not including a title affects 
more than 17% of the user base" or a if this affects a tool produced by 
a company with a market cap of greater than 6.3 billion dollars".

It comes down to judgment.  And on matters of judgment, reasonable 
people will disagree.

  - - -

So far, we seem to have consensus that atom:id MUST be present in 
atom:entries.  People who intend to consume atom feeds have expressed 
this requirement pretty clearly, and as a group we seem inclined to 
satisfy this requirement.

So far, I don't recall anybody stepping forward and saying that feeds 
without atom:category elements will be less effective.  Now that I have 
said that, I'm sure that somebody could come up with an example, but 
that would only prove my point that this is about judgment.

  - - -

We have RFC 2119.  We have Paul on record saying that if this actually 
is the will of the working group, scenarios such as these are 
appropriate uses of the word SHOULD.  Note: this is not Paul advocating 
any particular outcome, simply saying that that option is open to us.

With all this in mind, my suggestion is that we all calm down for a few 
days, and discussion things other than text elements.  And when we do 
revisit this discussion early next week, lets not start with 
atom:summary, OK?

- Sam Ruby

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2005 15:16:08 -0700

>     atom:title SHOULD NOT be empty, lest the recipient choses to ignore

They are roughly equivalent with normal usage of those words, but in 
my mind, not with respect to RFC 2119. The latter does not give an 
implementer enough information to determine when he or she might want 
to include and atom:title, and when he or she might not.

Put another way, if I were implementing, I would understand the first 
one much more than I would understand the second one, even though the 
person writing the two thought they were roughly equivalent.

Also, as was pointed out to me earlier on this thread, it is not 
clear to whom these are addressed: Atom producers or Atom consumers. 
If read as-is by an implementer of consumers, the second one sounds 
more like an invitation to ignore than the first.

>It comes down to judgment.  And on matters of judgment, reasonable 

+1

>We have RFC 2119.  We have Paul on record saying that if this 
>actually is the will of the working group, scenarios such as these 
>are appropriate uses of the word SHOULD.

Not quite. I think (I hope!) the essence of what I said was "you can 
use a SHOULD if you explain what the exceptions are". I don't think 
the example above meets that test.

>With all this in mind, my suggestion is that we all calm down for a 
>few days, and discussion things other than text elements.

+1

>And when we do revisit this discussion early next week, lets not 
>start with atom:summary, OK?

The co-chairs will attempt to find a different way to determine WG 
consensus on atom:summary than the current method, which is not 
working.

--Paul Hoffman, Director
--Internet Mail Consortium