Subject: Re: Unspecified Properties, Defaults and Value Replacement

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Apr 2000 12:59:36 -0500

Because they contain properties for which the documentation gives defaults
that make sense as a starting point.  That isn't true of the other
descriptors -- they are too situation-dependent.

In my errata document I've taken a more timid stand at this point, waiting
for comments.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Wednesday, April 26, 2000 9:59 PM
> To:   [email-masked]
> Subject:      Re: Unspecified Properties, Defaults and Value Replacement
>
> G'Day Tom,
>
> Why do we want the exception for Local Control and Termination State in
> (1) below?
>
> Cheers, Christian
> Tom-PT Taylor wrote:
> >
> > I have done some further thinking and research on the "unspecified
> value"
> > issue.  Here are my new thoughts.  I would very much welcome comments.
> >
> > Section 6.2.4 presents a data model which is not an accurate
> representation
> > of subsequent parts of the protocol document.  There are several
> statements:
> >  -- most properties have default values
> >  -- when a termination is created, unspecified properties are given
> their
> > default values
> >  -- when a termination is modified, unspecified properties retain their
> > previous values.
> >
> > As noted in a previous thread, a lot of our data behaviour is actually
> > specified at the descriptor level.  In addition, the sensible initial
> state
> > for most descriptors is either "no value" or "empty", although this
> could be
> > modified by provisioning for specific terminations.  Here's a complete
> list
> > of descriptors and the initial values I think we intend:
> >
> > Descriptor              Initial Value When Termination Created
> > ----------------
> > --------------------------------------------------------
> > Modem                  No value
> > Multiplex                No value
> >
> > Media                    See components
> > TerminationState    ServiceStates=InService; EventBufferControl=Off
> > Stream                  See components
> > Local                     Empty
> > Remote                 Empty
> > LocalControl          Mode=inactive[?]; Reservexx=Off
> >
> > Events                  Empty, RequestID=0[?]
> > EventBuffer            Empty
> > Signals                 Empty
> > Audit                    Empty
> > DigitMap               Empty
> >
> > I propose that the above table be added to section 6.2.4 and and the
> text on
> > initial values for properties be modified to refer to the table instead
> > (with suitable reference to packages where applicable).  The question
> marks
> > for Mode and RequestID are because we do not actually specify those
> defaults
> > in our text.
> >
> > The other point to be straightened out is the fact that descriptor-level
> > semantics are important.  I think the following are true statements of
> our
> > intent.  If so, sections 6.2.4 and 7.1.1 should be modified to reflect
> them:
> >
> >  (1) When a specific descriptor is specified in a command, the contents
> of
> > that descriptor completely replace any previous settings of properties
> > within that descriptor.  THERE ARE THREE EXCEPTIONS: DigitMap does its
> > replacement at the level of the individual named digit map, and we
> probably
> > want unspecified properties in TerminationState and LocalControl to
> retain
> > their previous values.
> >
> >  (2) If a specific descriptor is omitted from a command, its previous
> > contents are retained.
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: [email-masked]