Subject: Re: RECAP & Questions of CPL RECUR Issues.

From: [email-masked]
Date: Thu, 17 May 2001 18:03:28 -0400

John claimed:
>To reach Draft Standard, there need to be two implementations
>which implement the *entire* specification.  You can't
>cherry-pick; you can't say, "A and B support X, and C and D
>support Y, so we keep X and Y" (unless X and Y are optional).

Thats not how I read RFC 2026, section 4.1.2  Draft Standard, paragraph 2 where it says:

              In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

This tells me that both X and Y would stay in the spec as it progressed 
since at least 2 implementations implement those "options or features". 
That confirms what I was first told when I was new to IETF.  However, 
perhaps Patrick or some other AD can confirm / decline / clarify this.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Thu, 17 May 2001 18:16:38 -0400

[email-masked] wrote:

> This tells me that both X and Y would stay in the spec as it
> progressed since at least 2 implementations implement those
> "options or features".

I *think* "options or features" means things that are not
mandatory.  If X is mandatory, and C does not support it, then C
is not an implementation of the spec.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |You're just jealous because the voices only talk|
[email-masked]|to me.                                          |
\=================================================================/

---

From: Alan Davies <[email-masked]>
Date: Thu, 17 May 2001 18:34:38 -0400

Sometimes it's difficult to work out what is and isn't
mandatory- there are lots of places where 'MUST' seems
to be implied, without being stated- e.g. iTIP's restriction
tables.

Also the level of support that implies that a feature
has been 'demonstrated' is a grey area- for instance
we noticed several properties and values at CalConnect
that 1 or more vendor(s) supported on their inputs, but
which they couldn't generate themselves. If a CUA can
understand property X and allow users to view it, but
wouldn't let them create or modify it, have they
implemented X?

Another example is the VJOURNAL component- it seems that
to be compliant with all MUSTs a CUA doesn't have to
fully implement VJOURNALs, just return an appropriate status
to show that they're not supported.

How do other groups test for conformance to RFCs when
progressing to Standard Protocol status?

--Alan