Subject: On SHOULD, MUST, and semantics

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Apr 2005 09:28:18 -0700

A few brief notes for the WG to chew on.

- Literal interpretation of 2119 for a document format such as Atom 
would make nearly every element of an entry a MAY. It is a tad 
dishonest to say "why is element Xyz even a SHOULD?" when we have a 
*long* list of MUSTs already. It is no wonder that people are 
changing their opinion of any particular element from MUST to MAY to 
SHOULD and around again.

- The format document, like many IETF Applications Area specs, is 
steeped in hidden semantics. If I suggested that atom:title go from 
MUST to MAY, there would be outrage. The reason is that most of us 
think of entries as having some semantics that include a title. We 
don't say in the format document why we made atom:title a MUST: it's 
just "obvious".

- Differentiating the importance of the semantics of various elements 
is really, really hard, and people's opinions change over time. I 
strongly suspect that many of the less-vocal-but-still-active members 
of this list have changed their view of the importance of 
atom:category at least once. This is the hardest one to align with 
making a simple-to implement spec. The fewer cross-element links we 
have, the easier it will be for an implementer.

- We have, unfortunately, linked the semantics of two or more 
elements together. atom:content and atom:summary are linked because 
of their semantics (if you don't have a readable content, you 
MUST/SHOULD/MAY have a summary).

- We have, fortunately, not required linked semantics for extensions. 
If I came out with hoffman:content-plus-plus, I can't assume that 
whatever linkage there is between atom:summary and atom:content will 
apply to my extension. But, of course, if someone considers 
hoffman:content-plus-plus to be like atom:content, they may *want* 
the same linkages.

- Every SHOULD, by definition, adds logic into the software that 
creates a message in the spec'd format. In the long history of the 
IETF, this also tends to prevent interop, because it gives two 
differing parties a soapbox to argue from.

- Person A may think that an optional element that is missing means 
W. Person B may think that an optional element that is present but 
null means X. Person C may think that W == X, Person D may think that 
W != X. Person C and Person D will probably code very differently.

Proposal for thinking about: to simplify the spec, "atom:summary" 
should either be a MUST in all cases or a MAY in all cases. If it is 
just semantic like "atom:category", it should be a MAY. If it is 
inherently valuable like "atom:title", it should be a MUST.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Sam Ruby <[email-masked]>
Date: Wed, 27 Apr 2005 12:49:39 -0400

Paul Hoffman wrote:
> 
> - We have, unfortunately, linked the semantics of two or more elements 
> together. atom:content and atom:summary are linked because of their 
> semantics (if you don't have a readable content, you MUST/SHOULD/MAY 
> have a summary).
> 
> - We have, fortunately, not required linked semantics for extensions. If 
> I came out with hoffman:content-plus-plus, I can't assume that whatever 
> linkage there is between atom:summary and atom:content will apply to my 
> extension. But, of course, if someone considers 
> hoffman:content-plus-plus to be like atom:content, they may *want* the 
> same linkages.

Actually, that's one of the key reasons why I like the MUST for summary. 
  If somebody invents a popular hoffman:content-plus-plus, then feeds 
that include it lieu of atom:content will need to include a human 
readable summary that can be used by existing clients.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Wed, 27 Apr 2005 13:03:07 -0400

> readable summary that can be used by existing clients.

If they nest a content-plus-plus inside atom:content, they wouldn't
have to include that summary, right?

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 27 Apr 2005 18:47:37 +0100

> inherently valuable like "atom:title", it should be a MUST.

What isn't "inherently valuable" about a "semantic". False dichotomy. 
What a load of unconstructive bollocks.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Apr 2005 11:37:54 -0700

Well said, Paul; this articulates the reasons for a profiling mechanism 
much more effectively than I ever did.

Cheers,

On Apr 27, 2005, at 9:28 AM, Paul Hoffman wrote:

> *long* list of MUSTs already. It is no wonder that people are changing 
> their opinion of any particular element from MUST to MAY to SHOULD and 
> around again.
>
> - Person A may think that an optional element that is missing means W. 
> Person B may think that an optional element that is present but null 
> means X. Person C may think that W == X, Person D may think that W != 
> X. Person C and Person D will probably code very differently.
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

---

From: Sam Ruby <[email-masked]>
Date: Wed, 27 Apr 2005 16:13:29 -0400

> have to include that summary, right?

My recollection of the consensus of the decision to nuke 
PaceNukeMultipart apparently is flawed, as I can't find any email 
discussion that backs up what I seem to remember.  Judging by the text 
in rationale listed in PaceOptionalSummary, I gather that the author of 
that Pace came to a similar conclusion.

Simply put: my recollection was that we were successful in killing 
PaceNukeMultipart with the argument that every entry would have some 
displayable text (either plain, html, or xhtml).

That's pretty much orthogonal to the discussion we are having here 
(i.e., if an entry does not have any summary or content, then it doesn't 
discriminate - it is equally as inaccessible to everybody); but if that 
was the actual intent of the consensus, then the document should be 
updated to reflect that.  Furthermore, it would rule out the tunneling 
of hoffman:content-plus-plus as a dodge to avoid providing a summary 
that could be understood by existing clients.

- Sam Ruby

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Apr 2005 13:54:54 -0700

At 6:47 PM +0100 4/27/05, Graham wrote:
>>should either be a MUST in all cases or a MAY in all cases. If it 
>>is just semantic like "atom:category", it should be a MAY. If it is 
>What isn't "inherently valuable" about a "semantic". False 
>dichotomy. What a load of unconstructive bollocks.

False reading. I was comparing "just semantic" to "inherently 
valuable". Both atom:category and atom:title are obviously both 
semantic, yes?

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Wed, 27 Apr 2005 17:31:55 -0400

> displayable text (either plain, html, or xhtml).

My recollection is that we were successful in removing multipart
content because references to linked alternates would have sufficient
granularity to provide accessible alternatives. If there were multiple
content elements, an entry would need to provide references for each
of those elements, and start to look like a feed itself. I don't lend
much weight to either of our recollections, though. Those discussions
were disorganized, rude, and full of intimidation.

> discriminate - it is equally as inaccessible to everybody);  

My opinion is that ~10 WG members are currently clearly stating their
belief that  summary/content are optional.

> but if that
> updated to reflect that. 

If you are suggesting that the format should require a summary for
more non-empty types of content than it currently does, I don't have
an objection to that, but we'll have to see a Pace.

> Furthermore, it would rule out the tunneling

I don't think we can defend ourselves from bad-faith publishers.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 28 Apr 2005 00:11:39 +0100

> belief that  summary/content are optional.

You should make clear that most of those people supported a misleading 
Pace that didn't clearly state its side-effects beyond making 
feeds-where-no-title-is-available legal. Whether or not they support 
the general position that "summary/content are optional" is not for you 
to make.

Graham

---

From: Graham <[email-masked]>
Date: Thu, 28 Apr 2005 01:50:48 +0100

On 28 Apr 2005, at 1:41 am, Robert Sayre wrote:

> Sorry Graham, my conclusion is perfectly reasonable.

It fucking is not. The people +1ed a specific Pace with a particular 
purpose. Arguing that you therefore have support for a general position 
is totally disingenuous.

Also, you may not be the most impartial judge of the reasonableness of 
your position, unless there's two of you.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Wed, 27 Apr 2005 20:58:12 -0400

> purpose. Arguing that you therefore have support for a general position

Well, Graham, all we can really talk about is what the Pace says. It's
fairly clear. The fact that those opposing it didn't take the time to
read it or the spec is not my problem, nor does it indicate
disingenuousness of any sort on my part. If someone were looking for
that, they could go back through the archives and look at the
arguments of the 2 or 3 people that seem to want this argument to
continue. They keep changing, don't they? Those 2 or 3 people are
lucky that I pointed out they might want to close the front door
before they put their tinfoil hats on.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Wed, 27 Apr 2005 20:32:45 -0600

On Wednesday, April 27, 2005, at 05:11  PM, Graham wrote:
> the general position that "summary/content are optional" is not for 
> you to make.
>
I didn't find the Pace misleading, and support the position that 
summary/content are optional.

On Wednesday, April 27, 2005, at 10:49  AM, Sam Ruby wrote:
> Actually, that's one of the key reasons why I like the MUST for 
> summary.  If somebody invents a popular hoffman:content-plus-plus, 
> then feeds that include it lieu of atom:content will need to include a 
> human readable summary that can be used by existing clients.
>
This is definitely the most convincing argument I've heard for 
requiring the summary.  But it doesn't make it a MUST for me.  If 
hoffman:content-plus-plus gets popular enough for this to matter, and 
publishers publish a feed with that element, no atom:content, and no 
atom:summary, and don't publish a variant with one or both of those, 
then either we've really missed the boat with this spec or Paul has 
invented something so revolutionary and great that old apps deserve to 
be obsolete and unsupported.  I think this goes just a little beyond 
the limits of what we need to foresee and ensure we're ready for.

I know it wouldn't be enforcable, but in some imaginary world, the 
bullet point that PaceOptionalSummary proposes removing could be 
replace by "the atom:entry element contains no atom:content element, 
but does contain an extension element that carries the content of the 
entry".  I wouldn't be opposed to that.

But back to the real world...

On Wednesday, April 27, 2005, at 04:35  AM, Sam Ruby wrote:
> So.. can we agree on SHOULD?
>
I could live with it SHOULD or MAY.

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 28 Apr 2005 10:12:35 +0100

Graham wrote:
> feeds-where-no-title-is-available legal. Whether or not they support the 
> general position that "summary/content are optional" is not for you to 
> make.

But yet you can make the judgement that people supported a misleading 
pace. This does not seem to be a reasonable or useful argument to make.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Thu, 28 Apr 2005 00:11:39 +0100

Graham

---

From: Graham <[email-masked]>
Date: Thu, 28 Apr 2005 00:11:39 +0100

Graham

---

From: Graham <[email-masked]>
Date: Thu, 28 Apr 2005 00:11:39 +0100

Graham