Subject: CAP ABNF and external references

From: [email-masked]
Date: Wed, 13 Nov 2002 14:04:41 -0500

The ABNF in a draft should be fully self contained or at best note what 
other RFCs it is inheriting content from.  RFC 2234 is assumed because it 
defines the ABNF notation.  Other RFCs are not assumed normally and I can 
see no text that says "ABNF components from RFC 2445 and 3080 are used in 
some cases below".  Mainly because I dont see much inheritance to note.

I do see some that do require you to be very familiar w/the ABNF of 2445 
to fully parse:

   latency-sec      = integer
[Snip]
   option-value     = paramtext

Given the minor ABNF content that is in really an external reference I 
think we should either clearly note it in the prose OR include the 
relevant ABNF parts here for completeness.  I prefer the latter as it 
makes buidling an ABNF tree easier but it does add some 'duplicate' 
content (although very little from what Ive seen).

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

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Nov 2002 12:55:11 -0700

Thanks - I added '; As defined in [iCAL]'

[email-masked] wrote:
> other RFCs it is inheriting content from.  RFC 2234 is assumed because 
> it defines the ABNF notation.  Other RFCs are not assumed normally and I 
> can see no text that says "ABNF components from RFC 2445 and 3080 are 
> used in some cases below".  Mainly because I dont see much inheritance 
> to note.
> 
-- 

  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: [email-masked]
Date: Mon, 18 Nov 2002 11:08:40 -0500

> Thanks - I added '; As defined in [iCAL]'

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:

   msgno      = 0..2147483647

so that the allowed range is non-negative at least.  In the latency-seg 
case we may want to use something like:

   latency-sec = 0..2147483647

and then expressly define that a value of "0" means "Never times out" or 
some other exact definition. 

We could make the maximum value much smaller while we are at it since 
2147483647 seconds is ~24855.13 days or ~68 years.  I dont know about 
other implementors but I dont expect my users to make 1 command that needs 
that long to complete...

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.")
    B) If it does then we need to clearly say when, actions taken, etc.

2) What good is LATENCY=0 on a command if the lack of the LATENCY 
parameter effectively means "Never times out"?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 18 Nov 2002 09:58:01 -0700

> adopt the BEEP approach of expressly defining a range of allowed values 

And how does a positive integer like the following that I
sent go negative?

      p-integer   = 1*DIGIT  ; Where DIGIT is defined in [iCAL]

> 1) If there is no LATENCY= (and ACTION=) params on a command, does it 
> ever time out?

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.

> 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 :-)

--