Subject: Re: Descriptor processing order

From: Chip Sharp <[email-masked]>
Date: Tue, 14 Mar 2000 09:54:27 -0800

I think this would resolve ambiguities and possible anomalous results on
descriptor processing.  If the MGC wants the MG to process the descriptors
in a particular order, it would then have control.

In the particular example I cited, I would assume that the MGC would always
place TerminationStateDescriptor before EventsDescriptor (thus having
EventBufferControl processed before the new EventsDescriptor); however, it
would have the ability to reverse the order if it needed to.

Chip

At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote:
>Good point.  I think we should add text that says
>descriptors are processed in the order they appear
>in the command, just like commands are processed
>in the order they appear in the action.
>
>Brian
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:[email-masked]]
> > Sent: Monday, March 13, 2000 8:33 PM
> > To: [email-masked]
> > Subject: Descriptor processing order
> >
> >
> > Due to a previous question on event handling, I went through
> > the output of
> > SG16 (TD37) looking for text on the ordering of processing of
> > descriptors.
> >
> > However, I could find no text in the document that describes
> > in what order
> > a MG or MGC should process descriptors.  I was specifically
> > wondering if
> > the TerminationStateDescriptor was processed before the
> > EventsDescriptor.  This has implications in that the order of
> > processing
> > the value of the EventBufferControl parameter in the
> > TerminationStateDescriptor and the EventsDescriptor will
> > affect how events
> > in the EventBuffer are processed.
> >
> > If TerminationStateDescriptor is processed first and
> > EventBufferControl=Off
> > (previous LockStep), then all events are discarded.  If
> > EventsDescriptor is
> > processed first then at least one more event will be reported
> > before the
> > EventBuffer is flushed (ignoring the previous discussion as
> > to whether this
> > is desirable or not).
> >
> > It seems there may be any number of conditions like this that
> > will depend
> > on ordering of processing of descriptors in the command.
> >
> > Shouldn't there be some basic text in the spec that either
> > specifies that
> > the receiver of a command should process the descriptors in the order
> > received or that the receiver can process them in any order
> > desired?  I
> > prefer the former.  The latter seems a little indeterminate.
> >
> > If there is already text of this nature in the document,
> > please educate me
> > as to its location.
> >
> > Thanks,
> > Chip
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
> >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Christian Groves <[email-masked]>
Date: Wed, 15 Mar 2000 07:48:15 +0100

G'Day Chip and Brian,

Sounds like a good idea it what I've always assumed (but as we've found
out several times with this protocol, assumptions are dangerous). Is
this something for the implementor's guide or an error fix?

Cheers, Christian

---

From: Steven Magnell <[email-masked]>
Date: Wed, 15 Mar 2000 04:54:40 -0500

This discussion exposes a syntactic difference between the binary and text
encodings of the protocol. The binary encoding describes the list of
descriptors in the Add/Move/Modify commands as a SEQUENCE which follows the
order given by the abstract API descriptions of the commands. The text
encoding, on the other hand, specifies only a list of parameters where the
parameters are the separately defined as the descriptors, allowing
variations in the order of descriptors.

Chip's expectation that the order of descriptors can be reversed in order
to affect the order of processing is only possible using the text encoding.

Given this difference either the binary encoding syntax should be changed
or the order of descriptor interpretation should follow the order given in
the abstract API.

steve

---

From: Chip Sharp <[email-masked]>
Date: Wed, 15 Mar 2000 08:53:41 -0800

I hadn't thought of it before, but these are two separate issues.

The first issue as noted by Steve is that the text encoding doesn't specify
an order on the descriptors in the command.   This seems to apply only to
the text encoding since the binary encoding does restrict order.

The second issue is the order of processing, regardless of order of
descriptors in the command.  This issue applies to both text and binary
encoding.

There seems to be an agreement on some basic text to clarify the second
issue (process descriptors in order of receipt).  In fact I would classify
this as "errata".

The first issue is much thornier.  I don't really have an opinion one way
or other.

Chip

P.S.  Enjoy Adelaide.  I won't make it this time.

---

From: John Segers <[email-masked]>
Date: Wed, 15 Mar 2000 17:03:34 +0100

Chip,

It seems that if you want the flexibility that you proposed in an
earlier message in this thread, the issues get linked:

- processing in order of receipt
- variation in ordering of descriptors allowed, to allow, e.g.,
eventBufferControl to be set before or after processing new
eventsdescriptor.

I'm not sure that we need this flexibility, but I can imagine that it
will be hard to agree on a fixed order of processing.  I'm not going to
propose an order, but show how I think the ASN.1 would have to be
changed to allow variation in order of descriptors.  Instead of

AmmRequest ::= SEQUENCE
{
        terminationID           TerminationIDList,
        mediaDescriptor         MediaDescriptor OPTIONAL,
        ModemDescriptor         ModemDescriptor OPTIONAL,
        muxDescriptor           MuxDescriptor OPTIONAL,
        eventsDescriptor        EventsDescriptor OPTIONAL,
        eventBufferDescriptor   EventBufferDescriptor OPTIONAL,
        signalsDescriptor       SignalsDescriptor OPTIONAL,
        digitMapDescriptor      DigitMapDescriptor OPTIONAL,
        auditDescriptor         AuditDescriptor OPTIONAL,
        ...
}

we would get

AmmRequest ::= SEQUENCE
{
        terminationID           TerminationIDList,
        descriptors             SEQUENCE OF AmmDescriptor,
        -- At most one descriptor of each type (see AmmDescriptor)
        -- allowed in the sequence
        ...
}

AmmDescriptor ::= CHOICE
{
        mediaDescriptor         MediaDescriptor,
        modemDescriptor         ModemDescriptor,
        muxDescriptor           MuxDescriptor,
        eventsDescriptor        EventsDescriptor,
        eventBufferDescriptor   EventBufferDescriptor,
        signalsDescriptor       SignalsDescriptor,
        digitMapDescriptor      DigitMapDescriptor,
        auditDescriptor         AuditDescriptor,
        ...
}

It's quite a change if you count the number of lines changed, but it can
still be regarded as an erratum that fixes a discrepancy between ABNF
and ASN.1.

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Chip Sharp <[email-masked]>
Date: Wed, 15 Mar 2000 11:44:22 -0800

Sorry if I misled you. I really don't care about the flexibility.  Others
might.
:-)
Chip

>still be regarded as an erratum that fixes a discrepancy between ABNF

Ooo.  Correct usage of the singular form of errata.  Nice.  :-)

---

From: Steven Magnell <[email-masked]>
Date: Wed, 15 Mar 2000 12:17:48 -0500

Like Chip, I am not as concerned with the flexibility, but more concerned
with consistency and clarity.

John's proposal happens to address the consistency part for this element of
the protocol. It make the two encodings consistent. and defines the
operational order for processing descriptors. Chip's original note
addresses the operational ambiguity.

Both should be adopted as errata.

steve