Subject: RE: [Megaco] Re: g/sc SigID list

From: "Tulpule, Naren" <[email-masked]>
Date: Mon, 6 Aug 2001 15:04:48 -0700

Hi Terry/List,
  I was under the impression that the "type" in a package refers to the type
of each VALUE, and that all productions allowed by parmValue can appear
after the eventParameterName. For example, following are valid:
al/ri{cad=1234}
al/ri{cad=[1234,5678]}
al/ri{cad={1234,5678}} ; syntactically valid but probably meaningless
al/ri{cad=[1234:5678]} ; ditto

Given this, is there any reason to specify "type" of sigID as list? Can we
just not say quotedString with the contents of each quotedString having a
particular syntax as follows inside the doublequotes:
sigIdValue = pkgdName / SignalListToken EQUAL UINT16 [ LBRKT pkgdName
*(COMMA pkagdName) RBRKT ]
And treat each DQUOTE sigIdValue DQUOTE as individual value in the
production for parmValue?

Similarly, what's the difference between saying tonedet/std can have "tl"
(list of tones) in events descriptor but "tid" (tone ID) in
observedEventsDescriptor? In both cases, can we not have these:
tonedet/std{tl=singleTone}
tonedet/std{tl=[tone1,tone2,tone3]}
tonedet/std{tid=singleTone}
tonedet/std{tid=[tone1,tone2,tone3]}
where singleTone, tone1, etc are defined unique tone IDs?

These views are mine alone, not those of Intel or Trillium.
-- Naren
Narendra C. Tulpule         310-442-9222
SMTS, Trillium (an Intel company)
12100 Wilshire Bl #1800 Los Angeles CA 90025
I took an IQ test and the results were negative.

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 07 Aug 2001 10:08:27 -0400

> al/ri{cad=[1234:5678]} ; ditto

That is part of the problem.  Syntactically anything legal in VALUE (text) or
OCTET STRING (binary) can appear here, but a package must specify which are
allowed.  The code that handles a package must know what to expect and how to
interpret it.

> production for parmValue?

Certainly this is ALLOWED but it is not what the current package says.  It may
not be the way I would have defined the package, but I am trying to remove
ambiguity not change the definition.  It currently says "list" and so I am
trying to clarify this list rather than change it to just "string".  If we all
agree that we want to change it to "string" (which could break some existing
implementation, but the current is so ambiguous that is likely anyway) that is
also possible.  We still must specify precisely what is in the string.

The definition you offer allows either a single signal or a single sequential
signal list but not a list of such so if you do not allow a sub-list of such
items (I think you are arguing against sub-list) then this is certainly not
equivalent to what is currently described.  And while this can also be used as
the value placed in OCTET STRING in the binary encoding, this would force a
binary implementation to be able to parse an ABNF defined string.  Requiring a
binary implementation to also have an ABNF parser big disadvantage to some.

> where singleTone, tone1, etc are defined unique tone IDs?

tid=[tone1,tone2,tone3]
is certainly NOT allowed by the current definition where tid is "enumeration"
not sublist or string.

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 Aug 2001 15:36:29 +1000

G'Day Terry,

I support not having to have an ABNF decoder for the binary protocol.
So do I understand correctly that you are proposing to have. A sublist
list of:
Signal ::= SEQUENCE
{
	signalName 		SignalName,
}

tag = a1 (Value : sequence of) 
length 
        tag = 04 (octet string) 
        length 
        value =         04 (octet string - double wrapped) 
                        length=4 
                1st signal ID 
        tag = 04 (octet string) 
        length  
        value = 04 (octet string - double wrapped) 
                length 
                2nd signal ID 
        : 
        :

Cheers, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 08 Aug 2001 09:47:28 -0400

Close, but to allow both simple signals and signals in a seq list I think it needs
to be a list of SignalRequest so each element of the list (that is, each OCTET
STRING in value) would be
SignalRequest ::= CHOICE
{
    signal           Signal,
    seqSigList    SeqSigList
}

And Signal in signal or deeper in the expansion of seqSigList would be as you say,
except that sigParList is not OPTIONAL so it would have to exist as a zero length
SEQUENCE.

Signal::=SEQUENCE
{
    signalName    SignalName,
    sigParList    SEQUENCE OF SigParameter    -- zero length
}

I am not real familiar with how the ASN.1 encodes into binary, but isn't there some
artifact in the binary from the zero length sequence?

I am urging that pkg properties defined as sub-list use existing ASN.1 structures
(perhaps with stated restrictions on use of OPTIONALs) rather than new ASN.1
definitions.  Similarly for ABNF they should refer to an existing ABNF structure.

---

From: Christian Groves <[email-masked]>
Date: Thu, 09 Aug 2001 14:19:15 +1000

G'Day Terry,

I can see your point in wanting to use exising structures and sublists
but I think that adding sigParList is really adding extra overhead
that's not needed. The SignalRequest is only part of a structure anyway,
so I don't know that you gain anything by keeping an existing ASN.1
structure??? 

I see the case for Signal or SeqSigList but I don't think having
sigParList encoded as 0 length helps anythying.
Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Mon, 13 Aug 2001 11:44:12 -0400

> so I don't know that you gain anything by keeping an existing ASN.1

Christian,

What you gain is the ability to specify simply "SignalRequest",
instead of "SignalName or SeqSigList" or

Foo ::= CHOICE
{
	sn		SignalName,
	seqSigList	SeqSigList
}

Terry doesn't want to write an ASN.1 entry like "Foo" he wants
to use an existing one, "SignalRequest".  This is a good intent.  
I wouldn't want to encourage/cause people to write custom ASN.1.

On the other hand, when you add all these conditions and exceptions
("must leave out all optional fields", "must reduce this non-optional
list to length 0"), your not really using existing contstructs any
more.  Your doing a one-off.  Developers will not be able to plug
in their exisiting enc/dec subroutines.  They'll have to do additional
checks.

Frankly, this brings into question the whole idea of using existing
constructs for g/sc SigID.  There's just not that much information
here and we're doing flips and twists trying to make it look like
something else.

On the third hand :), there is a major advantage to having an ASN.1
encoding, and it's not to avoid a little text parsing in your ASN.1
application.  It's because an ASN.1 only application won't want to
know all those possible TEXT package names and signal names.

Which leads me back in a circle to supporting Terry's "SignalRequest
with conditions".

(more below)

> > artifact in the binary from the zero length sequence?

Terry,

Any "SEQUENCE OF" specification can be satisfied by a zero length sequence.

> > definitions.  Similarly for ABNF they should refer to an existing ABNF structure.

Using existing structures is a good thing.  But again,
you need to separate this from the sub-list concept.
There's no reason to limit package-defined-types to
sub-lists.

-troy