Subject: Re: Last Call: Applicability Statement for HTTP State Managementto BCP

From: John Stracke <[email-masked]>
Date: Wed, 23 Jun 1999 21:30:13 +0000

The IESG wrote:

> The IESG has received a request from the IETF Steering Group Working
> Group to consider Applicability Statement for HTTP State Management
> <draft-iesg-http-cookies-00.txt> as a BCP.

I've got a procedural question.  This Draft says:

     This  memo  therefore  identifies uses of the HTTP State
     Management protocol which are either outside of the scope of the
     standard and  thus not  recommended  by  IETF,  or which are
     believed to be harmful and are therefore discouraged.  Uses in
     the latter category should be considered violations   of   the
     standard,   even   though  the  actual  protocol implementations
     may conform to the standard.  This memo, along with RFC-XXXX,
     is  considered  part  of  the  HTTP  State  Management  protocol
     specification.

Is such a statement appropriate for a BCP? My impression from RFC-2026 is
that BCPs are completely distinct from the standards track--and my
folklorish impression is that this is as it should be, since protocol
standards should only specify matters relevant to the operation of the
protocol.

If such a statement is inappropriate, then what do we do instead? (I do
sympathize with the goal here.)

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 23 Jun 1999 21:30:13 +0000

---

From: Fred Baker <[email-masked]>
Date: Thu, 24 Jun 1999 07:36:23 -0700

>standards should only specify matters relevant to the operation of the

BCPs are not distinct from the standards track, they are a parallel
standards track. They are best thought of as a "one shot standard" which
represents our best understanding of "how it ought to work." Examples of
such are the use of Classless Interdomain Routing (CIDR), the standards
process itself, etc.

---

From: Fred Baker <[email-masked]>
Date: Thu, 24 Jun 1999 07:36:23 -0700

---

From: [email-masked]
Date: Fri, 25 Jun 1999 02:04:00 -0400

> such are the use of Classless Interdomain Routing (CIDR), the standards

Fred, I suspect that you and John Stracke are either violently in
agreement, or managed to go right past each other.  I'm just not
sure which it is...

I think John's concern was that it appeared that HTTP State Management
was being aimed at *both* Proposed Standard *and* BCP - when BCP's are,
as you point out, our "current best understanding".  Thus, there is a
distinction between 'Standard' (we *know* this is The Way To Do It) and
BCP (we're doing it this way because it's the best we've come up with
so far).

Can somebody come up with a better replacement for the sentence:

Although the rest of Keith Moore's draft looks (at first reading)
to be an excellent candidate for BCP status, I have some issues
with a 'BCP' being part of a protocol spec.  Also, some quick
checking shows that no other "Applicability Statements" are also BCPs.

In addition, I'd modify the preceeding sentence:
                                                            Uses in
     the latter category should be considered violations   of   the
     standard,   even   though  the  actual  protocol implementations
     may conform to the standard.

I think "violationss of the protocol" should be replaced by
"bad/discouraged/obsolete practice" or similar.  Otherwise,
we're looking at setting a precedent of requiring Implementor's 
Workshops - the major reason the Internet works is because you
can yell "Foul! That violates RFC2845, section 4.5.3.5".  Saying
"If its 'believed to be harmful' implies "violation of the standard" 
is a *real* slippery slope.  

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Fri, 25 Jun 1999 02:04:00 -0400

Valdis Kletnieks