Subject: Re:

From: Andrea Campi <[email-masked]>
Date: Tue, 27 Aug 2002 17:45:26 +0200

Hi all,

I just noticed one area of ambiguity wrt the LATENCY param. What
is not clear if this applies to the whole transaction or if it's
a proper latency, i.e. it applies only to the time before the first
reply is sent.
For example, imagine a search that returns multiple objects with
different METHODs. The draft allows the server to send them using
separate ANS BEEP frames. Should the server stop checking for the
latency after the first ANS is sent, or should it keep checking and
maybe abort halfway? The latter doesn't seem very useful IMHO.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 Aug 2002 13:21:47 -0600

> maybe abort halfway? The latter doesn't seem very useful IMHO.

9.1.1 Bounded Latency

  ...  If the command is unable to be  completed in the specified
  amount of time ...

Great question, it does look confusing. I would say that as the
CS determines the timeout. It would know if it has completed the
command and if it can complete the command.

To muddy it more, if I were to write a multi-treaded CS and
I handed each TARGET off to a separate thread, thread ONE
could be done and sending, and thread TWO might not be able
to complete - what do I do?

(A) The CS must decide and the CUA must be able to handle ether:
    (1) no-answer and (2) partial-answers

OR

(B) Should a CS wait until it has all of the answers before sending
    any replies? And then if it does not have all of the answers
    by LATENCY - only then time out?

I would lean towards (B), as it may make the CUA easier to
implement??

---

From: John Stracke <[email-masked]>
Date: Tue, 27 Aug 2002 16:02:03 -0400

>I would lean towards (B), as it may make the CUA easier to
It depends on the answer to another question: when is the command 
completed? Is it when the CS has all the data, and can start sending, or 
when the CUA receives the last byte? Over a slow link, these could be 
very different--and, in the nature of TCP (and socket APIs), the CS will 
probably be completely unable to know how different.

(I, of course, consider this yet another argument against including 
bounded latency in the protocol at all: it necessarily results in 
ill-defined behavior.)

My first impulse was to say that (B) is the Right Thing, since the 
protocol can't expose whether the CS is multithreaded or not.  However, 
waiting until you have all the data before sending any of it 
gratuitously increases latency, which is a Bad Thing.  (It also 
increases the CS's memory requirements.)

-- 
/============================================================\
|John Stracke      [email-masked]                   |
|Principal Engineer|http://www.centivinc.com                 |
|Centiv            |My opinions are my own.                  |
|============================================================|
|In the country of the blind, the one-eyed man is in therapy.|
\============================================================/

---

From: Andrea Campi <[email-masked]>
Date: Wed, 28 Aug 2002 10:18:41 +0200

> to complete - what do I do?

Exactly.

>     by LATENCY - only then time out?

What about:

 (C) The CS does preliminary processing bounded by the provided latency;
if it's unable to complete by that, it aborts. The latency is only
meaningful until the server sends the first part of the answer -
either RPY or the first ANS - and then can take however long.

Note that the "preliminary processing" might even include executing
any needed SQL queries to the backend, so by the time it starts
sending it can reasonably expect to be able to complete in at least a
finite time.

Note that the client can always decide to abort a transaction (by
closing the channel) and can always detect whether an answer was
complete and valid (by validating the iCalendar content; or we could
even add a Content-Length header). These are desirable features, as
in a GUI MUA the user may hit a stop button before the timeout has
expired.

Bye,
	Andrea