Subject: Re: RFC3229+feed: Empirical Evidence of significant savings.

From: [email-masked]
Date: Mon, 4 Oct 2004 21:30:23 +0100

I don't see what this has to do with interop.

Graham

-- original message --
Subject:	Re: RFC3229+feed: Empirical Evidence of significant savings.
From:	Bjoern Hoehrmann <[email-masked]>
Date:		04th October 2004 4:40:52  AM

  The working group will also take steps to ensure interoperability,
  by [...] clearly nominating conformance levels for different types
  of software

---

From: Robert Sayre <[email-masked]>
Date: Mon, 04 Oct 2004 16:56:38 -0400

> I don't see what this has to do with interop.

The conformance section of the Atom spec is empty. This WG defines what 
a conformant Atom User Agent is.

We could split conformance into multiple levels or classes. Here's an 
example from the HTML 2.0 spec:

http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.2.3

I don't have an opinion on RFC3229 support, but this is discussion is 
totally in-bounds, IMO.

Robert Sayre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 4 Oct 2004 14:24:36 -0700

At 4:56 PM -0400 10/4/04, Robert Sayre wrote:
>The conformance section of the Atom spec is empty. This WG defines 
>what a conformant Atom User Agent is.

We already have a set of MUST and SHOULD statements; that specifies 
conformance.

>We could split conformance into multiple levels or classes.

We could, and that would be relatively novel for an IETF spec. Is 
there a good reason to do this? Maybe the spec plus a fleshed-out 
implementer's guide would be sufficient without us slicing-and-dicing 
different levels. The last thing we want is to confuse developers 
more than we already will be.

Personally, I'm happy with MUST and SHOULD, but I swim in them all 
the time in IETFworld. Others might prefer putting those in different 
categories.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Mon, 04 Oct 2004 18:19:52 -0400

Paul Hoffman / IMC wrote:

> We could, and that would be relatively novel for an IETF spec. Is there 
> a good reason to do this?

I don't know if there's a good reason, because many of the nouns in the 
spec aren't very well-defined. We don't define an "error", "processor", 
"user agent", "generator", "consumer", or anything like that.

Most of the MUST and SHOULD statements in the spec would be gone if we 
chose a formal language to describe syntax constraints[0]. I agreed with 
PaceReduceMustMay's [1] suggestion to use a formal language, but that 
Pace offered no proposal to act on. I could live with a DTD, with 
English for constraints that DTDs can't express.

Robert Sayre

[0] example: http://asg.web.cmu.edu/rfc/rfc2518.html#sec-23.1
[1] http://www.intertwingly.net/wiki/pie/PaceReduceMustMay