Subject: W-7 CAP Auto-logout Timer

From: Doug Royer <[email-masked]>
Date: Tue, 17 Aug 1999 15:19:58 -0700 (PDT)

W-7 CAP Auto-logout Timer issues               U

Do we need one?

If so, how long?

Can the server decide not to do this? As in mandatory in protocol,
optional to implement?

I propose that we DROP this as a requirement.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Thu, 19 Aug 1999 13:30:21 -0400

Doug called for an eHum on W-7 so here are my hums w/comments following:

W-7.1            YES
W-7.2            NO
W-7.3            NO
W-7.4            YES
W-7.5            OPTIONAL
W-7.6            YES

A timer is an architectural issue that I think is really OOB for CAP or 
iCalendar explicitly.  Some CS implementors may have this concept and 
implement it different ways.  Others have no concept of it at all (ie: 
they act just like SMTP and listen forever).  I dont think we should 
mandate the creation of this but rather provide a means to communicate the 
info to the CUA/CU IFF a CS does implement such a beast.

WRT 7.2 & 7.3: These values are policy based and should be adjustable 
acording to the implementations.   W/O mandating this in the architecture, 
these are not needed.

WRT 7.4 & 7.5: The info may be useful to a CUA in deciding how frequently 
it may want to poll, etc so it could be of use in the CAPABILITY info. 
However, if a CS does not implement it or choses not to expose it then 
thats fine too.  The policy could be automatically adjusted by the CS 
based on load, etc or it may be static.   7.4 could be a hint ala SMTPs 
hints or it could be fixed all the time for simpler implementations.

WRT 7.6: The CS should be as polite as possible in the right 
circumstances.  Situations like "immediate shutdowns" (attackers, loss of 
power, etc) or system panics and crashes obviously qualify as exceptions 
to this rule.

===========================================================================
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: [email-masked]
Date: Thu, 19 Aug 1999 18:11:36 GMT

As a customer who runs servers now and in the past,and who has received
hundreds of angry calls, I agree.

                    David Madeo                                                                                        
                    <[email-masked]>          To:     [email-masked]                                               
                    Sent by:                 cc:     John Stracke <[email-masked]>, [email-masked]            
                    owner-ietf-calend        Subject:     Re: W-7 CAP Auto-logout Timer                                
                    [email-masked]                                                                                         

                    08/19/99 12:11 PM                                                                                  
                    Please respond to                                                                                  
                    dmadeo                                                                                             

>but the CUA will always need to be able to
>deal with unclean closes.

     Never said it wouldn't.  Im suggesting this from the POV of making it
     easier/nicer for CU/CUAs.  If the Admin does a "nice shutdown" (or the
     CS policy times out the idle CUA) then why not make it easy for the
     CUAs to deal w/it??  This isn't rocket science Im proposing; just a
     simple solution to item W-7.

I'd agree that the CS should attempt to notify the client as to why it's
dropping the connection.  Don't handshake on it or anything, just send the
message, wait a few seconds, ignoring any incoming data and drop the
connection.

As an end-user, I'd rather see a message saying "Server says: going down
due to water leak" rather than just a dropped connection.

The reason it should be in the spec is so that clients can be coded to
understand the message and possibly pass it on to the customer.  Whether a
given installation, or even a given implementation server chooses to send a
message should be optional.

dmadeo(See attached file: dmadeo.vcf)

---

From: [email-masked]
Date: Thu, 19 Aug 1999 18:21:37 GMT

John, Doug is following procedure. He was correct to check with me.

                    John Stracke                                                                                       
                    <[email-masked]        To:     [email-masked]                                             
                    >                        cc:                                                                       
                    Sent by:                 Subject:     Re: W-7 CAP Auto-logout Timer                                
                    owner-ietf-calend                                                                                  
                    [email-masked]                                                                                         

                    08/19/99 01:24 PM                                                                                  

Doug Royer wrote:

> Pat - can we call for an e-humm?

I think you just did.  :-)

>         W-7.5   NO

I agree on all of these except 7.5: I think it could be useful for the CUA
to be able to tell the user how much idle time the CS permits.  For
example, if I find that I'm getting dropped frequently, I might like to be
able to see what the timeout was set to, so I can ask the admin about
increasing it.

--
/=============================================================\
|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: [email-masked]
Date: Thu, 19 Aug 1999 18:19:44 GMT

List, electronic hum?

By the way, I'm not seeing many electronic hums? Does this mean people
don't approve; aren't there; don't care.  I guess since this is electronic,
if we don't hear a hmmm, and you don't care, it's a N/A.  If you are
opposed, and speak up, that will be an "opposed" hm.   Agree?

                    Doug Royer                                                                                         
                    <[email-masked]        To:     [email-masked]                                             
                    OM>                      cc:                                                                       
                    Sent by:                 Subject:     Re: W-7 CAP Auto-logout Timer                                
                    owner-ietf-calend                                                                                  
                    [email-masked]                                                                                         

                    08/19/99 12:51 PM                                                                                  
                    Please respond to                                                                                  
                    ietf-calendar                                                                                      

I suggest (based on my memory of the issues as discussed in Oslo
or the mailing list):

  Give everyone until the end of August to e-humm on:

           W-7.1          Do we have an auto logout timer?

           If they humm YES, then:

                     W-7.2          Do we mandate a minimum value? As in
                               it can not be less than XX minutes. A
                               'no' humm means that you ~could~ be dropped
                               right after a command - zero idle time
allowed.

                     W-7.3          Do we mandate a maximum value? As in
                               it can not be more than YY minutes. A 'no'
                               humm means that the CS might never hang up.

                     W-7.4          Can the value be variable so the CS
                               can decide based on load?

                     W-7.5          Is the CS's default timeout value
returned
                               with the CAPABILITY command? Which would
                               make W-7.4 just a hint.

                     W-7.6          MUST the CS send something to the CUA
                               when the connection is dropped? (Except
                               a CS could just hang up on a spammer/hacker
                               without any message.)

I e-humm:

           W-7.1          YES
           W-7.2          NO
           W-7.3          NO
           W-7.4          YES
           W-7.5          NO
           W-7.6          YES

-Doug
Mountain View, CA 94040                   Ham Radio: N6AAW, Aviation:
PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 10:38:26 -0700 (PDT)

> Date: Tue, 24 Aug 1999 11:33:02 -0400
> From: Alexander Taler <[email-masked]>
> 
> I'm with Doug on all of these.
> 
> I seem to recall that IMAP (?) clients would issue NOOP commands in 
> order to prevent the server from closing a connection.    We don't 
> have NOOP, but CAPABILITIES could serve the purpose.  Providing 
> default timeout information (W-7.5) just makes this sort of 
> behaviour easier, and I'm sure that we don't want to encourage it.
>
> I can find that I'm getting dropped frequently when the server sends
> timeout notices, and my client displays a 'The server timed-out your 
> connection' message.

Sounds good to me.

I think that it should be worded so that a CS implementation might
wish to timeout a CUA if the CS feels that the only reason the CUA
is still connected is so that the connection stays alive. If you
think of a public calendar - to prevent a large number of CUA's from
hanging on forever .

In the enterprise or ISP world a CS implementation may be happy
with a CUA hanging on forever. In the e-business, merchants
my not wish a CUA to hang on when nothing is happening (as seen
by the merchants CS).

-Doug