Subject: RE: ABNF syntax query

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 9 Jul 2001 14:52:30 -0400

In this case, since it's an identifier in a package, it follows 
the syntax for pkgdName.  If it was a list of integers, it 
would follow the syntax for integer.  There are no 
items that allow commas (except those in enclosing brackets,
such as a parameter list in a list of parameterized items
and quoted strings).

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Monday, July 09, 2001 2:41 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: ABNF syntax query
> 
> 
> 
> What's an "item"?  Can my item be a comma or contain a 
> comma?  What syntax *is* allowed?
> 
> We need an actual type indication ("String", "Integer",
> "Boolean", etc.) to know how to encode it or decode it
> (in both text and ASN.1).
> 
> -troy
> 
> 
> "Rosen, Brian" wrote:
> > 
> > Lists are items separated by commas in the ABNF.
> > In this case, it's a list of identifiers, the same as,
> > for example, the tone list in tonegen.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Troy Cauble [mailto:[email-masked]]
> > > Sent: Monday, July 09, 2001 1:26 PM
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > Subject: Re: ABNF syntax query
> > >
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I must have been asleep
> > > >
> > > > I don't remember a discussion of making SigId a string.
> > > > Why?  It's a list.  That should be sufficient.
> > >
> > > List of what?  "List" doesn't really convey any type information.
> > >
> > > Don't say "signal", "signal" is not a type either.
> > >
> > > -troy
> > >
>

---

From: Troy Cauble <[email-masked]>
Date: Mon, 09 Jul 2001 16:44:13 -0400

> such as a parameter list in a list of parameterized items

Brian,

I would say that there are no "items" (-> VALUEs) that allow
commas except for those that are double quoted.

Note that a parmValue can be a "list", but a VALUE ("item")
is either a collection of SafeChar or a quotedString.

Let me try another approach...

Below is an example based on the text describing the allowed
values for E.1.2 SigID.  It's possible I misunderstood the
text, but it is more complex than just a pkgdName.

> 2.Reporting a  signal inside a sequential signal list:
> SigID="SignalList = 1 {pkg1/sig1}"

I used double quotes because without them, the example
would not pass the ABNF of Annex B.  " ", "=", "{", and
"}" are not SafeChar, so the VALUE must be a quotedString.

One of the points of IG 6.80 was to have a consistent
expectation of whether the SafeChar or quotedString
form would be used, based on the type.

Given that quotes are needed, why not just call SigID a String,
which also tells us how to encode the ASN.1.

We could modify 12.1.2, 12.2, IG 6.80 and IG 6.46 for a new
"SigID identifier" type, but I think that's overkill.  You 
might as well use String.

Calling something an "item", a "pkgdName identifier", or
anything not mentioned in 12.1.2, 12.2, IG 6.80 *and* IG 6.46, 
doesn't tell us:

1) how to encode the text (Should I use quotes?),
2) how to decode the text (Should I strtol() it, expect 
   "on" or "off", etc.?), or
3) how to encode or decode the ASN.1.

Package elements are protocol holes that package developers
can fill in later, provided they don't break Annex A or B.

The quotedString form is a wider whole than the SafeChar form, 
because more delimiter characters are allowed.

While it's possible to extend 12.1.2, 12.2, IG 6.46 and IG 6.80 
for complex types (as long as you don't break the definition of 
VALUE), there's little gain over the use of String.

-troy