Subject: RE: encoding package values as ANBF VALUES

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 14 Apr 2001 21:33:04 -0400

Troy

One of the problems with ABNF is that it is not easy to create
very precise rules for parameters that are extensible.  You end
up creating productions that cover all possibilities, and then
using text to cover the actual syntax.  In this case,
section 12.2 tells you that a parameter to a parameter is
typed, and defines how the type is represented.

Since gain is defined as an Integer, 
  tdmc/gain=2 
is a legal assignment, but
  tdmc/gain="2"
is not legal (integers are not quoted strings)
and since tdmc/ec is typed as an Enumeration
  tdmc/ec=on
is legal, but
  tdmc/ec="on"
is not legal

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Thursday, April 12, 2001 5:53 PM
> To: MEGACO list
> Subject: encoding package values as ANBF VALUES
> 
> 
> 
> (Item 1)
> 
>    VALUE                = quotedString / 1*(SafeChar)
>    SafeChar             = DIGIT / ALPHA / "+" / "-" / "&" /
>                           "!" / "_" / "/" / "'" / "?" / "@" /
>                           "^" / "`" / "~" / "*" / "$" / "\" /
>                           "(" / ")" / "%" / "|" / ".
> 
> VALUE is used in many package elements (properties, event params,
> etc.).  
> 
> These are all legal ABNF encoded property forms
> 	tdmc/gain=2
> 	tdmc/gain="2"
> 	tdmc/ec=on
> 	tdmc/ec="on"
> 
> It would have been more straightforward to just require quotes 
> all of the time.  But it's probably too late for that.
> 
> I strongly feel that while a package can define the type of
> a property, that it shouldn't be able to define whether or
> not the quotes are to be used.  This is part of the ENCODING
> SPEC.
> 
> 
> (Item 2)
> In a similar vein, I've seem some packages with "complex string"
> values defined.  Forgive me for not tracking one down; naspkg
> may have been one of them.  Anyway, I've seen some package that
> stated that a value string would have the same form as the 
> terminationIDList.
> 
>    terminationIDList    = LBRKT TerminationID *(COMMA 
> TerminationID) RBRKT
> 
> It needs to be understood that any such string would have to be 
> encoded as the quotedString form of VALUE (since it contains 
> non-SafeChars).  It needs to be understood that packages do not 
> get to redefine the ABNF encoding of VALUE, but must work within
> it.  Note that this means there is no way to have a double quote 
> character within a package element value.
> 
> 
> (Item 3)
> This all ties into the lack of specifications for encoding package 
> element *values* as ABNF *VALUES*.  For example if a package 
> defines property foo/bar as having type Integer, there is nothing 
> in the spec that disallows these encodings:
> 
> 	foo/bar=seventeen
> 	foo/bar=XVII
> 
> We hammered out the analogous ASN.1 specs in the "Additions"
> document, section 1.1.  We need a similar addition for ABNF
> encoding that says how to encode strings, ints, enums, etc.
> in ABNF VALUES.  It should note the *possibility* of quotes as
> defined by the ABNF for "VALUE".
> 
> After the argument dies down, and if no one else wants to, I'll
> submit a proposal.
> 
> -troy
>

---

From: Troy Cauble <[email-masked]>
Date: Tue, 17 Apr 2001 11:27:41 -0400

> typed, and defines how the type is represented.

Brian,

Section 12.2 describes a representation, but it doesn't describe
the TEXT ENCODING.  It doesn't say if integers are always
decimal, or if they can be hex if they are preceded by '0x'.  
Are leading zero octal forms allowed?  How about 'XVII' and 
'twenty-three'?  Are these not integers?  This is the level of 
encoding that we need to specify.

Yes, I am being picayune, and you probably consider the answers
obvious.  But a protocol specification needs to be this detailed.

> is not legal (integers are not quoted strings)

Says who?  Annex B says that "2" is a legal VALUE.
This is not currently tied to the *type* of a VALUE.

(I don't think it's reasonable to read too much into the
fact that the ANBF construct is called "quotedString".
If need be, I can find other discussions where we established 
that the *name* of an ABNF construct wasn't particularly 
meaningful.)

> and since tdmc/ec is typed as an Enumeration

Same comments as above.  Also, where is the specification
that an enum value can't contain non-SafeChars?  Then it
would have to be quoted.

If you don't want quoted and unquoted forms to be legal
for *ANY INSTANCE* of a VALUE whose characters are all
SafeChar, we need to add comments to tie VALUE forms to 
VALUE types..

-troy

---

From: Troy Cauble <[email-masked]>
Date: Fri, 20 Apr 2001 17:09:54 -0400

Proposed addition below.

-troy

<Inserted at the beginning of Annex B.2, replacing
 two lines about "Boolean values".>

; NOTE -- The ABNF in this section uses the VALUE construct (or lists of
; VALUE constructs) to encode various package element values (properties,
; signal parameters, etc.).  The types of these values vary and are
; specified the relevant package definition.  Several such types are
; described in section 12.2.
;
; The ABNF specification for VALUE allows a quotedString form or a
; collection of SafeChars.  The encoding of package element values into
; ABNF VALUES is specified below.  If a type's encoding allows characters
; other than SafeChars, the quotedString form MUST be used for all values
; of that type, even for specific values that consist only of SafeChars.
;
; String:  A string MUST use the quotedString form of VALUE and can
; contain anything allowable in the quotedString form.
;
; Integer, Double, and Unsigned Integer:  Decimal values can be encoded
; using characters 0-9.  Hexadecimal values must be prefixed with '0x'
; and can use characters 0-9,a-f,A-F.  An octal format is not supported.
; Negative integers start with '-' and MUST be Decimal.  The SafeChar
; form of VALUE MUST be used.
;
; Character:  A UTF-8 encoding of a single letter surrounded by double
; quotes.
;
; Enumeration:  An enumeration can be encoded from alphanumerics
; and the underscore character.  The SafeChar form of VALUE MUST
; be used.
;
; Boolean:  Boolean values are encoded as "on" and "off" and are
; case insensitive.  The SafeChar form of VALUE MUST be used.
;
; Future types:  It is expected that packages will define types
; beyond these initial types.  Any defined types MUST fit within
; the ANBF specification of VALUE.  Specifically, if a type's encoding
; allows characters other than SafeChars, the quotedString form MUST
; be used for all values of that type, even for specific values that
; consist only of SafeChars.
;
; Note that there is no way to use the double quote character within
; a value.

<End Insert>