Subject: [Fwd: Re: CAP ABNF and external references]

From: Doug Royer <[email-masked]>
Date: Wed, 04 Dec 2002 16:14:26 -0700

>
 > ...However your
 > new p-integer does allow for 0 which is still a non-useful value for
 > LATENCY.

I agree the zero has no meaning - I'lll fix that.

However if a initiator wishes to wait a very long time for
the responder to complete, that is up to them. It
does not stop the responder from responding earlier
and it does not stop the responder from sending some kind
of error before the timeout, both of which terminate
the command.

Your example of 24 hours seems excessive to me, but
I would rather not limit it in the protocol as I feel
the CUA and the CS implementations can decide.

-- 

   Doug Royer                     |   http://INET-Consulting.com
   -------------------------------|-----------------------------
   [email-masked]                 | Office: (208)612-INET
   http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                  |   Cell: (208)520-4044

                  We Do Standards - You Need Standards

---

From: Andrea Campi <[email-masked]>
Date: Thu, 5 Dec 2002 12:24:36 +0100

> of error before the timeout, both of which terminate

I think we should state this explicitely. That is, the responder
may respond with a timeout error of sort even before the initiator
specified expires.

Bye,
	andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - 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: Thu, 05 Dec 2002 11:21:01 -0700

> may respond with a timeout error of sort even before the initiator

Sorry - I did not mean to say that. I meant that the responder
may reply with an error. However I guess any valid error would do,
including 'server temporally unavailable' or something.

--

---

From: Andrea Campi <[email-masked]>
Date: Fri, 6 Dec 2002 09:58:44 +0100

> including 'server temporally unavailable' or something.

Regardless, we seem to be in agreement, right?
Note that I was referring more to something like "server has run
out of resources", or even "processing time quota exceeded". It's
a policy decision on the server side, and the CUA won't care, as
long as the error code is right. Ideally we should have error code(s)
that indicate this is not a permanent error, but you might need to
simplify your request.

Bye,
	Andrea

---

From: [email-masked]
Date: Fri, 6 Dec 2002 12:29:32 -0500

> I agree the zero has no meaning - I'lll fix that.

So are you taking the position that NO latency-param means "Never times 
out"??

Im on the fence but the more I think about it the more Im inclined to 
mandate that latency-param MUST be specified and that "0" mean "Never 
times out".  See previous post in this thread for more info on this...

In any case CAP 1.0 09-submitted is unclear as to what it means when no 
latency-param is specified and that needs to be rectified before it can 
pass WG last call.

> the responder to complete, that is up to them. 

Agreed.  However I do think that ~68 years is a bit excessive no matter 
what your definition of "very long time" is...

>                                                 It

This case is not described in 09-submitted and I think it needs to be 
before this confusion can be considered resolved.  Section 10.1.1 Bounded 
Latency covers many permuations but there is no talk of returning partial 
results.  This needs to be covered in text in 10.1.1 where latency is 
covered.

> the CUA and the CS implementations can decide.

There already is a limit if you use integer (or a modified integer) from 
2445 which already defines "The valid range for "integer" is -2147483648 
to 2147483647.".  Even if we simplify this to 1..2147483647 thats a damn 
long time for any single command to complete.  In the interest of KISS I 
think we should shorten it to something more reasonable for a single CAP 
command since we are already making changes and not adopting 2445's 
integer as is.  But thats just my preference, your mileage may vary.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...