Subject: Re: CAP ABNF and external references

From: [email-masked]
Date: Tue, 15 Apr 2003 11:22:17 -0400

Hmm, not sure why this was stuck in my laptops outgoing queue.  Sorry its 
a bit dated (I queued it in Nov 2002) but its still relevant I think...

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]

You misread my posting.  I was referring to the current integer ABNF.

Your new ABNF does not allow negative numbers but it still allows for a 
latency of 0 no matter how you tweak the "*DIGIT" parts.  I think that 
allowing a latency of ~68 years is a bit excessive.  I dont think it 
unreasonable that we further restrict latency-param to be something like 
"1..31536000" (~1 year) or even a smaller range.  I know none of our users 
are that patient.

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

One problem, we have no currently defined REQUEST-STATUS code that means 
"Command Terminated by the CS" and then we can subclass it into "because 
your command took too long", "because you requested too much data", 
"because I dont like your hair color"...

Please consider this when you consolidate the error codes in CAP...

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