Subject: Re: OCTET STRINGs in H.248

From: "Taylor, Tom-PT" <[email-masked]>
Date: Tue, 7 Nov 2000 20:36:45 -0500

In general you have to go into the detailed description of each field to
understand how to parse it.  For example, I've just put to bed an update of
the Advanced Audio Server packages.  The parameters in this package are
defined in gross terms as strings, but there's a lot of detail in the
package definition telling how the strings are constructed and interpreted.

To take your first few examples, interpretation of SecurityParmIndex,
SequenceNumber, and Authdata are covered by the text of section 10.2.  When
it comes to signal parameters, each has to be tackled on its own.

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2000 4:41 PM
> To: [email-masked]
> Subject: Re: OCTET STRINGs in H.248
>
>
> Brian, Tom, John, et. al.,
>
> Anyone want to take a shot at these?
>
> -troy
>
>
> -------- Original Message --------
> Subject: OCTET STRINGs in H.248
> Date: Sat, 4 Nov 2000 00:28:30 -0500
> From: Troy Cauble <[email-masked]>
> Reply-To: Troy Cauble <[email-masked]>
> To: [email-masked]
>
> Hi all,
>
> Maybe I've missed some subtle beauty in the OCTET STRING,
> but it seems like an OPAQUE structure that's overused in
> the ASN.1 H.248 encoding.
>
> For example, these seem to represent integers:
>
>            SecurityParmIndex ::= OCTET STRING(SIZE(4))
>
>            SequenceNum       ::= OCTET STRING(SIZE(4))
>
> But how do I extract an integer value?  ntohl()?  Feed the
> octet string to an ASN.1 function for decoding integers?
> Why wasn't an ASN.1 Integer used?
>
> What can I conclude about the internal structure of the
> following?
>            AuthData          ::= OCTET STRING (SIZE (12..32))
>
>
> The "quotedString" element in the ABNF isn't much better.
> The worst cases are
>
>         In the ASN.1    Value ::= OCTET STRING
>         In the ABNF     VALUE  =  quotedString / 1*(SafeChar)
>
> Many protocol elements use the above definitions.
>
> The value component of a SigParameter (or EventParameter or
> StatisticsParameter, etc) is OCTET STRING.  How do I decode
> this opaque data representation?
>
>         From decoding the SignalName and the sigParameterName
>         I'll know the implied type (if I support that package).
>
>         Section 12.2 lists all the allowable types.  But it
>         doesn't specify the ASN.1 or text *encoding* of those
>         types.
>
>         What is the text representation for an "Integer"?
>                 sprintf("%d") ?  %x ?  0x%x ? %o ? 0%o ?
>         What about a "Double" ?
>
>         How do I get the integer value of an OCTET STRING
>         that's known to be "Integer: 4 octet signed integer"?
>         An ASN.1 function for integers or ntohl()?
>
>         "List" is specified in the ABNF, but they're lists
>         of (OPAQUE) VALUEs.
>
>         Lists are handled in the ASN.1 *PropertyParm* as
>         "SEQUENCE OF OCTET STRING".  But can't lists be
>         used in the parameters to Events and Signals too?
>         Those elements just have a "Value" "OCTET STRING".
>
>         If I know the type is "String", how do I get from
>         the ASN.1 "OCTET STRING" to a char*?  Just cast it?
>         Or call an ASN.1 decode routine specific to "UTF-8
>         octet strings"?
>
> -troy
>

---

From: Troy Cauble <[email-masked]>
Date: Wed, 8 Nov 2000 14:25:29 -0500

Tom (or anyone),

I hope I'm being dense and missing something, but...

OK.  Your package uses strings as parameters and tells
me how to build those strings.  This I understand.

My question is: How are those strings ENCODED as ASN.1
OCTET STRINGs?  Byte for byte copy?  If so, is the null sent?

Note that an ASN.1 "OCTET STRING" does not mean the
same as an ASCII or UTF-8 "string".  It means a sequence
of opaque bytes of storage.

So if a package says to use the string "foo" does the OCTET
STRING contain a series of 3 bytes that contain 'f', 'o', 'o' ?
Or 4 bytes that contain 'f', 'o', 'o', '\0' ?
Or some less obvious guess?

*The ASN.1 encoding is not fully specified for parameter values.*

Similarly, if a package says a parameter type is "Integer",
we know from section 12.2 that "Integer" means "4 octet
signed integer".  But we don't know how to encode it as an
ASN.1 OCTET STRING.

Is the ASN.1 OCTET STRING four bytes long consisting of
the four bytes of a NETWORK BYTE ORDER integer representation?
Or do we sprintf() it to a string representation and
encode it like the "foo" example?  (Is "OCTET STRING" being
used to mean "string"?!)

Does anyone get my point?  Please point out whatever I've missed.

Similarly, the ABNF "VALUE" specification stops at "quotedString",
which (technically) doesn't fully specify the text ENCODING of
types like "Integer".

For the text encoding of "Integer" parameters, I doubt that we
want to allow "three".  But the text encoding specs stop at
"quotedString", so I guess it's valid.  A more reasonable GUESS
would be "anything compatible with atoi()", but it's not fully
specified.

Anyone?
-troy

> > Subject: Re: OCTET STRINGs in H.248

<...>

---

From: Christian Groves <[email-masked]>
Date: Fri, 10 Nov 2000 03:09:47 +1100

G'Day Troy,

I believe that the easiest way to cope with the use of Octet Strings in
ASN.1 is to say that if a package says a property is Integer (or string
etc) then it should be encoded in the Octet String has it would have
been if you have said "property INTEGER," in ASN.1 BER. T L V the value
would resemble INTEGER rather than OCTET STRING. OCTET STRING was used
to give you flexibility in the length. Something could go into the
implementors' guide to this effect.

The use of "\o" is a problem in both the text and ASN1 definitions. The
package probably needs to say whether this is to be encoded or not.

Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Thu, 9 Nov 2000 11:55:47 -0500

G'Day Christian,

Thanks for responding!

Are you proposing they be "double wrapped"?

The "double wrapping" approach is used in other protocols:
ASN.1 BER encoding PRODUCES octet strings.  So to encode
an integer (or whatever) you first use an ASN.1 BER function
for encoding integers (or whatever).  The octet data OUTPUT from
that function is the INPUT to the OCTET STRING encoding.

This would give a consistent approach that doesn't change
the current ASN.1 specification.

If on the other hand, you're proposing to encode an ASN.1 INTEGER
*instead of* an OCTET STRING, I think that would lead to
decoding troubles.  If an application doesn't support a package
it won't know how to decode the message.

-troy

> implementors' guide to this effect.

A standard ASN.1 "CHOICE" statement would've given the flexibility
we need.  OCTET STRING is a protocol "hole" that should be avoided.

---

From: John Segers <[email-masked]>
Date: Thu, 9 Nov 2000 17:47:58 +0100

Troy,

It's not you being dense, this is underspecified.

The intention of the OCTET STRING use is to have a general container
that can be used for new parameters defined in packages (signals,
events, properties).  The package defines a type such as boolean,
integer.  The encoding of an integer value should be done according to
ASN.1 BER (X.690), and the resulting octets are put into the octet
string.

On the receiving end, you get an octet string that is not decoded into
an integer value by the ASN.1 decoder because it does not know about an
H.248 package that says that this is really a integer.

The price that you pay for the flexibility of adding new parameters by
means of packages is the need to interpret the values for which OCTET
STRING is used in the application that knows the package.

Something similar holds for the text encoding.  There are some
additional issues with the text encoding because the octetstring of the
ABNF is really a text string and does not allow null characters.

Something that we did not specify is which type of string is used inside
the octet string if a package specifies that a variable is of a string
type.  It would be best to align with the strings allowed in the ABNF.

Cheers,

John

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

---

From: Troy Cauble <[email-masked]>
Date: Thu, 9 Nov 2000 16:59:10 -0500

> It's not you being dense, this is underspecified.

Thank you.  I was starting to wonder :)

> H.248 package that says that this is really a integer.

I think this is the same as the "double wrapping" that I
described in my reply to Christian.

> STRING is used in the application that knows the package.

I believe an ASN.1 "CHOOSE" would've given this flexibility.
But I'm not trying to change anything -- I'll be happy with
any technique that's fully specified.

I hope that statements in (or associated with) sections 12.1.2
and 12.2 will define how to encode these types for ALL packages.
Not that each package will define how *it's* integers are encoded.

> ABNF is really a text string and does not allow null characters.

I don't understand.  "octetstring" is not mentioned as one of the
possible parameter types...(?)  "octetString" is used for the SDP
information in the text encoding, but I just took that to mean the
UTF-8 SDP information.

I do think text encoding of parameter values should be more tightly
specified.

> type.  It would be best to align with the strings allowed in the ABNF.

Section 12.2 mentioned UTF-8 strings.  I believe there is an UTF-8 string
type defined in X.690.  "Integer" and "enum", too, I think.  "List"
might be less obvious.

> John

Thanks,
-troy