Article View: comp.protocols.iso
Article #844Re: FTAM, Contents-type attribute
From: Alan Young
Date: Mon, 12 Nov 1990 11:23
Date: Mon, 12 Nov 1990 11:23
42 lines
2786 bytes
2786 bytes
I am afraid I cannot agree with your analysis.
In the first place it is possible that the Presentation context
supporting "iso standard 8571 abstract-syntax ftam-pci", in
which the F-OPEN pdu including the
F-OPEN.contents-type.proposed.document-type.parameter element is
encoded, is using something other than ASN.1 BER as its transfer
syntax. This means that one should only really discuss this
matter using ASN.1 value notation rather than the sizes and
contents of encodings. Bearing that in mind, however, it is
still illustrative to use BER encoding in an example.
You say:
> I believe the difference is that null parameters (case d) would be the
> parameter field encoded with a length of zero.
Now lets get this clear. The 'parameter' element (field) is defined to be
of type '[0] ANY'. Before such a type can actually be used there must be some
other type that is understood to be the real (actual) relevant type
definition; in this case the PARAMETERS type defined in the FTAM1
document type definition which is of type SEQUENCE.... The BER encoding
of any type is of a minimum 2 octets: one for the class/constructed/tag
3-tuple and one for the length. If the parameter element is present then
it must include some type and thus the minimum length for the entire
encoding is 4 octets, representing the value "parameter ::= PARAMETERS {}".
> Using your example -
> {FTAM-1, {,,}} - the parameter field would have a length of 6 (1
> identifier octet plus one length octet for each parameter -- no contents
> octet since the parameter is null). Case d would be encoded {FTAM-1, {}}
> so that the length of the parameter field would be zero. This is _my_
> understanding of the difference.
I am really very confused about what you are trying to say here. Could
you elaborate with either an example sequence of octet values or an
ASN.1 value notation. You seem to be suggesting that I could encode (for
example) the maximum-string-length element of the PARAMETERS sequence
by encoding its identifier octet followed by a length octet of value
zero, but this is an invalid encoding as maximum-string-length is of
type INTEGER which may not be encoded with a length of zero under BER.
Alan Young.
Technical Details
Message-ID:
<3179.658409023@concurrent.co.uk>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcsun!ukc!stl!concurrent!AlanReferences:
<1006@sl10c.concurrent.co.uk> <40288@cos.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcsun!ukc!stl!concurrent!Alan From: awy@concurrent.co.uk (Alan Young) Newsgroups: comp.protocols.iso Subject: Re: FTAM, Contents-type attribute Keywords: FTAM, Contents-type, parameters Message-ID: <3179.658409023@concurrent.co.uk> Date: 12 Nov 90 11:23:43 GMT References: <1006@sl10c.concurrent.co.uk> <40288@cos.com> Sender: awy@concurrent.co.uk Organization: Concurrent Computer Corp (ESDG), Slough, U.K. Lines: 42 Phone: +44 753 513316