Subject: Real problems in CAP document

From: John Stracke <[email-masked]>
Date: Sun, 11 Jul 1999 07:38:12 -0400

Some more serious problems with the CAP document (as opposed to the
other message I'm composing on editing nits):

I don't think the bounded latency features are implementable.  The CS
may be able to do rollback if all the operations occur within its
database; but what if it had to send an iMIP message?

4.4: "If a server has an inactivity auto-logout timer, that timer MUST
be of at least <pick a number: 30> minutes duration.": why? I could
see specifying a minimum *default*, but an admin should be able to
override that (for example, if they find that their users rarely stay
idle more than 10 minutes, but some of the users have a bug that
crashes the client if they're idle for 20 minutes, then the admin
should be able to set the idle timeout to 15 minutes).

7.1.5: "ed. Note: should the client now wait for a response from the
server before disconnecting?": I'm pretty sure the answer is no;
otherwise, if the server's hung, the client will hang.

14.2.4: "The Method Reviewer is appointed by the Application Area
Directors and can either accept or reject the entity registration."
There should not be a single person with such authority.

-- 
/=============================================================\
|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: Doug Royer <[email-masked]>
Date: Mon, 19 Jul 1999 14:15:36 -0700 (PDT)

> Date: Sun, 11 Jul 1999 07:38:12 -0400
> From: John Stracke <[email-masked]>
> 

The latency is for the CS reply - not the application data reply.
So the CS may say, accepted for delivery. That does not mean
that the end ~user~ has seen it.

> should be able to set the idle timeout to 15 minutes).

I agree here.

> otherwise, if the server's hung, the client will hang.

I agree here also.

> There should not be a single person with such authority.

If this is in compliance with the IETF rules - then this
needs to be taken to the IESG?

If not, then it should be fixed in the draft.

-Doug