Subject: Re: MEGACOHGCP10: Clarifications + Editorial corrections/comments

From: Brian Rosen <[email-masked]>
Date: Thu, 16 Sep 1999 08:04:36 -0400

> > > 3. What is the need of sending StatisticsDescriptor and
> > > ObservedEventsDescriptor
> > > in AuditCapabilities Response message ? These descriptors
> > > describe activity
> > > rather than a capability.
> > Statistics would return the list of statistics being kept
> (not the values).
> > We haven't defined what observedEvents returns.  One
> possibility is that it
> > would return the list of events possible.
> >
> > Probably need some text.
>
> PackageDescriptor contains the packages supported by the
> termination and thus
> implictly contains information on the statistics being
> supported by the
> termination. Therefore, there is no need of having
> StatisticsDescriptor.
>
> Similarly ObservedEvents is also not needed as the
> information regarding the
> list of possible events is getting covered in two descriptors
> - package
> descriptors - implicitly gives the list of all possible
> events that can be
> observed and the EventsDescriptor contains the list of events
> that are actually
> being observed for the termination.
I don't really care that much either way.  Probably
want to have some other voices.

> >
> > > 4. What does the profile parameter in ServiceChange
> > > Descriptor represent ? How
> > > is to be used by MG / MGC ?
> > Profiles can define things like what options are
> implemented, what kinds of
> > packages are supported, etc.
> > A profile is defined in some other document.  It has a name
> and a version.
>
> >
> > A knowledgeable MGC could look at profile
> > and quickly decide if it could serve an MG contacting it.
> > Profile is not, strictly speaking, required.  There are
> ways to figure out
> > what the MG implements without profile.
>
> Is there a standard of way of defining profiles (say
> something similar to that
> for packages), so that all MGs define their profiles in a
> consistent manner ? If
> not, then the usefulness of the profile would be limited
> because then the MGC
> would not know how to interpret the profile info and would
> use the audit to know
> about MG capability.
There is not, as yet, a description of what is in
a profile.  There is a proposal for an IPPhone profile,
which has generated some controversy on the list.

A profile could contain:
        Choices to be made where options exist in the
                protocol
        A set of packages to be implemented
        A set of conventions to be followed
        Additional specifications outside the
                protocol to be followed

I'd welcome anyone taking a crack at writing a description of a profile.  We
do have a description of how you write
a package.

Brian

---

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Sep 1999 08:45:49 -0400

Brian,

I note that in the syntax specification, the authentication data are
defined as "16HEXDIG", which makes for a fixed length 64 bits field.  I
don't believe that is the intent.  We should fix that at a minimum to
32(HEXDIG), to allow for MD5, and maybe to 32*64(HEXDIG) to allow for
further development such as SHA.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Sep 1999 10:05:15 -0400

Another syntax nit. There are a few constructs in the syntax of the type:
        LBRKT *(COMMA foo) RBRKT
Where foo may be for example actionRequest or actionAccept. This results in
an extra comma at the beginning of the encoding, as in:
        ! ca.example.net:1234 T=567890 {,ctx=${,add=COM2/1{...},add=RTP/${...}}
Note the extra comma before of "ctx" and the first "add."

While this is nothing that a parser could not handle, it is confusing and
prone to create problems. Any thought of replacing it by the more natural form:
        LBRKT [foo *(COMMA foo)] RBRKT
or possibly
        LBRKT [[COMMA] foo *(COMMA foo)] RBRKT
What do you think?

-- Christian Huitema

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Sep 1999 11:34:42 -0500

Christian,

I couldn't find a single production which included the syntax that you describe.  Could you
please identify the productions by rule name?

Christian Huitema wrote:

>      <snip>

--
Brian F. G. Bidulock
Associate Director - New Products
Inet Technologies Inc.

---

From: Abdallah Rayhan <[email-masked]>
Date: Thu, 16 Sep 1999 13:50:37 -0400

Christian,

First, which rule are you talking about ? I couldn't find any with your
description.

2- We don't have the intention of "*(COMMA command)". If it is there
then it must be a typo that should be fixed.

Abdallah Rayhan

---

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Sep 1999 13:52:06 -0400

>please identify the productions by rule name?

Oops.. I realize that I was merely the victim of poor formatting, not poor
syntax.  The production appeared on my screen as:

transactionRequest          = TransToken EQUAL TransactionID LBRKT
actionRequest
                              *(COMMA actionRequest) RBRKT

transactionAccept           = AcceptToken EQUAL TransactionID LBRKT
actionAccept
                              *(COMMA actionAccept) RBRKT
; still to be reviewed
transactionReject           = RejectToken EQUAL TransactionID LBRKT
                               *(actionAccept COMMA) actionReject RBRKT

actionRequest               = CtxToken EQUAL ContextID LBRKT
commandRequest
                              *(COMMA commandRequest)RBRKT

actionAccept                = CtxToken EQUAL ContextID LBRKT
commandAccept
                              *(COMMA commandAccept) RBRKT

Probably a problem with tabulation marks, or with the length of lines...
-- Christian Huitema