Subject: Re: CAP ABNF and external references

From: [email-masked]
Date: Wed, 4 Dec 2002 15:15:58 -0500

Doug replied on 11/18/2002 11:58:01 AM:
> > Im sorry I wasnt a bit more clear in my original posting; this change 
is 
> > probably not sufficient.  The definition/ABNF for integer in RFC 2445 
is:
> > 
> >      integer    = (["+"] / "-") 1*DIGIT
> > 
> >     Description: If the property permits, multiple "integer" values 
are
> >     specified by a COMMA character (US-ASCII decimal 44) separated 
list
> >     of values. The valid range for "integer" is -2147483648 to
> >     2147483647. If the sign is not specified, then the value is 
assumed
> >     to be positive.
> > 
> > As such it is valid to have negative or "0" LATENCY.  I think CAP 
should 
> > adopt the BEEP approach of expressly defining a range of allowed 
values 
> > ala:
> 
> And how does a positive integer like the following that I
> sent go negative?
> 
>       p-integer   = 1*DIGIT  ; Where DIGIT is defined in [iCAL]

The p-integer definition does not go negative.  I _never_ said it did, go 
reread my post;  Im talking about integer from 2445!  However your new 
p-integer does allow for 0 which is still a non-useful value for LATENCY.

Whats wrong w/redefining as I suggested:

   latency-sec = 1..2147483647 

(I think I put in 0.. before but I didnt mean to.)  I dont see a pressing 
need to define p-integer since A) it leaves the maximum value undefined in 
the ABNF and B) very large values like those possible from integer in 2445 
(~68 YEARS) are not that useful for C/S (no matter how robust you think 
your implementation is, I strongly doubt anyone would wait that long for a 
single command to complete!!)

Im advocating the KISS approach and defining strict limits to the 
latency-sec that are sufficent for nearly any needs.  A maximum value of 
86400 is probably more than enough for any CAP command; its equivalent to 
24 hours given that latency-sec is in units of seconds.  Thus I ammend my 
proposal to be that we redefine latency-sec as:

   latency-sec = 1..86400

and this precludes overly long timeouts and the 'What is a 0 time out?' 
case.

> > I guess this raises some questions about LATENCY since its not clearly 

> > defined in the draft (there is only some ABNF but no prose about 
> > limitations, etc):
> > 
> > 1) If there is no LATENCY= (and ACTION=) params on a command, does it 
> > ever time out?
> >     A) If not then we need to clearly say this in the draft and 
provide 
> > the CS some clear way to 'error out' after processing the command 
("You 
> > have exceeded the maximum allowable time for a single command, try 
again 
> > later or simplify the command and arguments.")
> 
> We do - send a VREPLY with an error. The entire argument for LATENCY
> way back in the iRIP time frame was so that you could specify
> a timeout. The presumption being that you have no timeout if
> you do not sent one.
> 
> I see NO need to have LATENCY to specify timeout and ANOTHER-LATENCY
> to specify the timeout when LATENCY is not specified.

You didnt answer the question, you were strictly responding to the (A) 
possible answer case.

Nowhere in CAP 09-submitted can I find ANY text that clearly states if a 
command ever times out if _no_ LATENCY and ACTION parameters are present 
on the command.  Are you suggesting that the command never times out 
(perhaps unless the CS decides to error out for some reason like the 
command is taking too many system resource, etc)?  Or are you saying that 
all commands time out even if no LATENCY / ACTION parameters are 
provided??

Hmm, perhaps you did with that last line of the 1st paragraph but its 
_NOWHERE_ in CAP so its ambiguous as to how an implemenatation should 
address the case of no LATENCY and ACTION parameters... 

In the interest of clearning this up why not mandate the following:

1) LATENCY MUST always be provided, ACTION MUST be provided except for the 
case outlined in 2) below
2) If no timeout is desired/intended then a value of '0' MUST be used for 
LATENCY and ACTION MUST NOT appear (since no ACTION is required if no 
timeout is to occur).
3) If any timeout is desired/intended then a value between 1..86400 MUST 
be used for LATENCY and ACTION MUST appear.

Im just trying to find ambiguities or vagaries in the spec and get rid of 
them. 

> > 2) What good is LATENCY=0 on a command if the lack of the LATENCY 
> > parameter effectively means "Never times out"?
> 
> I could argue that it is a good way to perform a DOS on a CS :-)
> 
> I agree - lets disallow LATENCY of zero, as '1' would never
> be a issue :-)

Well there is little difference between using LATENCY=0 for a DOS and 
sending NO LATENCY at all; apart from 9 octets of extra data in the former 
case (excluding the required ACTION=... parameter too).

I didnt propose we disallow '0', I just asked what good it was given the 
current ABNF.  I could go either way with LATENCY=0 or no LATENCY 
parameter; I just want it to be clearly defined in the draft what it means 
to have no LATENCY (if we go the route of no LATENCY means "this command 
never times out" or not).  If LATENCY is optional then we need to be clear 
on what it means to not be there.  If LATENCY is not optional then using 
'0' for "never times out" is the route to go.

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...