Subject: CAP: autologout

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 14:32:55 -0400

A couple of questions about autologout on idle:

    * 4.4: "When a timeout occurs, the server drops the connection to
      the CUA". Should there be some sort of notification first? We've
      got a notification for server shutdown (difficult as that may be
      to implement); one for idle timeout seems reasonable.
    * 7.1.12: the NOOP command seems like a way of evading the server's
      idle timeout policy. Many servers I've known with such timeouts
      don't want them evaded (for example, I had an ISP which had an
      idle timeout on their PPP connections, and warned that ping
      packets didn't count, because people were using ping to keep the
      connection alive). Maybe there should be an error code reporting
      that the NOOP has been ignored?

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Please do not adjust your mind--reality is   |
[email-masked] <mailto:[email-masked]>|malfunctioning.                              |
\==============================================================/

---

From: George Babics <[email-masked]>
Date: Sun, 19 Aug 2001 13:36:00 -0400

The issue of having a NOOP command, and allowing the server to ignore
it did come up in January 2000 (see the archive).

  Looking at the archive, it was agreed to allow the server to ignore
NOOP and still drop the connection.

  What you are suggesting is to return an error rather than simply
ignore
NOOP. Should we return an error, or simply allow the server to drop the
connection despite the NOOPs?

  The reasons NOOP was kept was:
  - allow the client to attempt to keep the connection up
  - a simple way to check if the server is still alive,  Like PING.
    (In fact, another issue that came up in the NOOP thread was if
     NOOP should be renamed to "PING.")

  However, we should have a way of discouraging avoid the situation
where
a CUA calls NOOP often.

  In section 4.4 we have:

  "A CUA may be discouraged from attempts to do useless things only to
keep the
   connection alive."

  Yet, we also give them NOOP that may encourage CUAs to do such useless
things.

  That part of section 4.4 can be interpreted that the CS can terminate
the connection or return some error code if the CUA calls NOOP too many
times?

George

---

From: John Stracke <[email-masked]>
Date: Mon, 20 Aug 2001 10:35:38 -0400

>NOOP and still drop the connection.
And I have no problem with that.

>NOOP.
Sure.  I mean, if the server isn't honoring the request, it should say 
so; it shouldn't just send a success code--that would be lying.

On the other hand, a CUA that gets an error code in response to NOOP 
might then start doing useless things to keep the connection alive, and 
those will cost more server resources.  So maybe it's best if the server 
can keep the CUA in the dark.

-- 
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |For the life of me, I've never understood why   |
[email-masked]|people dismiss the importance of "semantics" in |
|                |communication. After all, if semantics had no   |
|                |purpleness, you'd slitheringly go bold at by-sit|
|                |it I'm climbing. -- Tangwystyl                  |
\=================================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Tue, 21 Aug 2001 20:08:06 -0500

>   Yet, we also give them NOOP that may encourage CUAs to do such useless

So the standard supports a CS that drops you after 20m even if you have
been issuing pings, and a CS that lets you stay on all the time so you can
have a responsive calendar.

Is there an event-notification channel written into the standard, so that
when something happens, the event description is sent to the client?  

I think we just have polling for that.

---

From: John Stracke <[email-masked]>
Date: Wed, 22 Aug 2001 10:08:46 -0400

>when something happens, the event description is sent to the client?  
No.  Event notification protocols have turned out to be surprisingly 
tricky in the past.  It'd be useful, but we're probably better off 
waiting for a future rev of CAP.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |If you're going to walk on thin ice, you might|
[email-masked]|as well *dance*!                              |
\===============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Thu, 23 Aug 2001 13:49:28 -0500

> waiting for a future rev of CAP.

Here's a protocol definition.  What surprising trickinesses do you see in
it?

<mode disposition=fantasy  setting=text-of-CAP-standard>

	Spontaneous Transmissions (STs):

	At any time except during the transmission of another response,
	the server MAY initiate a communication which is not immediately
	prompted by client command.  Examples of such communications
	would be "chimes," event notifications, and timeout warnings.

	Every ST consists of a descriptive line which starts with
	the letters "ST" and a space, then a CRLF, then zero or more
	lines of data, and finally a line with a single dot.

	Clients MUST be prepared to accept a well-formed ST at any time
	except during the receiving of another transmission, for instance
	between issuing a command and receiving a response code.

	The exact contents of STs are beyond the scope of this document.

	A typical difficult example:

      C: SENDDATA
      C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII
      C: Content-Transfer-Encoding:7bit
      C:
      C: BEGIN:VCAP
      C: VERSION:2.1
      C: CMDID:abcde-2
      C: METHOD:CREATE
      C: TARGET:cap://cal.example.com/relcal1
      C: BEGIN:VQUERY
      C: BEGIN:VQUERY
      C: QUERYNAME:GetAlliTIPinQueue
      C: QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
      C: END:VQUERY
      C: END:VEVENT
      C: END:VCAP
      C: .
      S: ST quarter-hourly chime: The time is now 1:45 PM
      S: .
      S: ST urgent bell
      S: Get moving!  Class is at two.
      S: .
      S: 2.0
      S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde"
      S:
      S: BEGIN:VCAP
      S: CMDID:abcde-2
      S: METHOD:RESPONSE
      [...]

</mode>

-- 
                                           David Nicol 816.235.1187
"In the world of the future, the new illiterate will be the person
who has not learned how to ignore morons" -- Not Alvin Toffler

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 24 Aug 2001 13:31:30 -0400

Date: Thu, 23 Aug 2001 13:49:28 -0500
   From: "David L. Nicol" <[email-masked]>

   [...]

This doesn't seem very useful.  How does this lead to
interoperability?  What is a client suppose to do with the contents
except discard them?

Larry

---

From: "David L. Nicol" <[email-masked]>
Date: Fri, 24 Aug 2001 14:59:14 -0500

Lawrence Greenfield wrote:
> This doesn't seem very useful.

I don't know about you, but I am constantly typing things like

	echo echo Soccer Practice \| mail pagers-nicol | at 3:30 pm tomorrow

into unix command lines.

>  How does this lead to
> interoperability? 

With the protocol written into CAP, different CS implementations will
issue event notifications regarding events affecting connected users
in the same way.

> What is a client suppose to do with the contents
> except discard them?

Display them to the user, in a pop-up window.  Or send them to
the user's pocket pager.  That's between the user and their installation.

Stracke said "event-notification protocols have problems" and I
responded with one that as far as I can tell would be resilient against
the problem I am aware of, which is confusion due to in-band data getting
fouled by an out-of-band data that is produced in the middle of it.

Having a CS implementation just send e-mails may be a lot cleaner, for
certain installations, but not for all.  The paradigm of many short
sessions against a server that can only handle so many simultaneous
sessions is but one possible paradigm.

An even simpler way of addressing this kind of thing (and any other
kinds of things that may appear) is to allow for open-ended vendor
extensions somehow.  Then a compliant implementation could define
some extras that are not defined in the standard, without breaking their
compliance.  Well-formed vendor extensions would be guaranteed to
not cause protocol participants (wither the C or the S) problems and
implementors could compete with each other in a wide open space.

Something like:

	Extended commands and transmissions may be sent from
either side of the connection at any time except during the middle
of another transmission of any time.

	Extended commands and transmissions start with an X and end with a dot on
a line by itself. The first line of an Extended command SHOULD look like
the definition of X-params, that is, X-[Vendor]-[Command] [arguments]

	When the Client sends an X-command, the server MUST respond with
a numerical response from a response set defined to include at least one
reserved numerical response which indicates that the server has no idea
what
the client is going on about.

Such a defined syntax for Features That Have Been Left Out would take
care of not only event notifications, but those Permission Tickets or
whatever you want to call them that I've made so much stink about in the
last month.

-- 
                                           David Nicol 816.235.1187
                                                 www.funnytimes.com