Subject: FW: [MEGACO] ServiceChangeReason - Optional or not?

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 18 Jan 2001 18:23:02 -0500

Resend

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Tuesday, January 16, 2001 4:22 PM

First off, it's true that the status of ServiceChangeReason is ambiguous.
Given its universally applicable nature, I would propose that we agree to
make it mandatory in requests.

Secondly, could we agree to a double wrapping solution for this one in the
ASN.1, where the interior structure is
  ServiceChangeReason
  {
       code INTEGER,
       explanation IA5String OPTIONAL
  }

Comments?

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 12:10 PM
> To: [email-masked]
> Subject: Re: [MEGACO] ServiceChangeReason - Optional or not?
>
>
> Raju wrote:
> >
> > > Troy Cauble wrote:
> > > >
> > > > Hi all,
> > > >
> > > > ServiceChangeReason is optional in the ABNF encoding,
> > > > but not in the ASN.1 encoding.
> > > >
> > > > All of the sample messages in Appendix A that
> > > > have ServiceChangeRequests omit it.
> > > >
> > > > Is it optional or not?
> > > >
> > > > -troy
> > >
> > > OK.  I guess an EMPTY serviceChangeReason Value
> > > will correspond to a missing serviceChangeReason
> > > in the ABNF.
> > >
> > > So now the question is, how do I encode the following
> > > specification as an OCTET STRING?
> > >
> > > From 7.2.8:  [The ServiceChangeReason parameter] consists
> > > of an alphanumeric token (IANA registered) and, optionally,
> > > an explanitory string.
> >
> > The ServiceChangeReason is an 'alphanumeric token'.
> > H.248 doesn't follow the ErrorDescriptor (IANA numeric
> error code + optional
> > explanatory string) conventions (see H.248 7.3) for the
> ServiceChangeReason
> > (which is an IANA alphanumeric string). Why H.248 didn't do
> this is, these
> > ServiceChangeReason error cases are part of GW/Termination
> dynamics, it's
> > not an "error" (may be some failure).
> >
> > The following are the registered IANA ServiceChangeReason
> tokens (each line
> > is an IANA token):
> >
> >  900 Service Restored
>
> <... snip>
>
> >
> > One can optionally add an explanatory string add the end of
> this token (it's'
>                                                ^^^^^^^^^^^ assumption
> > still an OCTET STRING).
> > The receiver can easily get the ServiceChangeReason Code
> (900 to 915) using
> > sscanf(), if it is needed. This is possible because by
> adding optional
> > string the sender won't change the ServiceChangeReason
> token string, it's
> > just a string append.
>          ^^^^^^^^^^^^^ assumption
> >
>
> Raju,
>
> I understand that an 'alphanumeric token' and an explanatory string
> can be easily combined to make another string.  (Although it's poorly
> specified:  Do we assume that they're separated by whitespace?  Do we
> assume the order of these two elements?  We're assuming string
> concatenation already, probably because of the word "token".)
>
> My real issue (like always:) is encoding a character string as an
> ASN.1 OCTET STRING.  You don't address this except to say
> "it's still an OCTET STRING".  Which seems to imply that
> you think the OCTET STRING will be a byte for byte copy
> of the source string.
>
> OCTET STRING is for protocol hole for opaque, 8-bit data.
> How a character string is encoded into this has not been
> specified and should not be assumed.
>
> Someone else might assume it's compressed some way to take
> advantage of the wasted 8th bit in each byte.  Or two parties
> might assume it's a byte-for-byte copy, but differ on whether
> the NULL is included.
>
> Even worse, serviceChangeReason is no longer an OCTET STRING,
> it's a SEQUENCE OF OCTET STRING.  Maybe I'll put the alphanumeric
> token and the explanatory string in separate OCTET STRINGs.
>
> If the serviceChangeReason is intended to (always) be a character
> string, it should be specified as an ASN.1 IA5String or UTF8String
> or one of the many other ASN.1 character string types.
>
>
> -troy
>

---

From: Troy Cauble <[email-masked]>
Date: Thu, 18 Jan 2001 18:28:16 -0500

Re-comment:

Unlike the property param values we double wrapped earlier,
the service change reason TYPES should not vary based on
something like a package definition.

So there is no point in double wrapping.  I propose
just changing the ASN.1 to use your new structure below.

That is, in ServiceChangeResParm, change

        serviceChangeReason     Value,
to
        serviceChangeReason     ServiceChangeReason,

Double wrapping works, but adds no value other than
not changing Annex A.

-troy