awy@concurrent.co.uk (Alan Young) (11/06/90)
I have a problem with interpretation FTAM Part 2 (ISO 8571-2 or BS
7090:Part 2:1989) concerning section 12.3 "Contents Type" and the use of
the Contents-type attribute on an F-OPEN request (ISO 8751-3 section
17.1.2.4). I am afraid I rather "brushed it under the carpet" when I
first noticed it but now that I have started looking at conformance test
cases I has come back to haunt me.
Considering only the document-type form of a contents-type attribute the
standards suggests that when a contents type, other than
"contents type unknown", is proposed on an F-OPENrequest there are three
possible forms (paragraphs c, d and e of section 12.3). To further
simplify this discussion I will restrict this text to that relating to
reading a file and for the possibility of a relaxation, not a
simplification:
c) a document type name without parameters, in which case the match
must be exact;
d) a document type name with null parameters, in which case the name
must match, but the parameter values are supplied from the attribute
value;
e) a document type name with non-null parameters, in which case the
name must match, and the parameters must match or be a relaxation.
The relevant ASN.1 definitions are:
Contents-Type-Attribute ::= CHOICE {
document-type [0] IMPLICIT SEQUENCE {
document-type-name Document-Type-Name,
parameter [0] ANY OPTIONAL
-- The actual types to be used for the values of the
-- parameter field are defined in the named document
-- type.
},
...
}
and an example parameter type definition for FTAM-1 documents:
PARAMETERS ::= SEQUENCE {
universal-class-number [0] IMPLICIT INTEGER OPTIONAL,
maximum-string-length [1] IMPLICIT INTEGER OPTIONAL,
string-significance [2] IMPLICIT INTEGER {...} OPTIONAL
}
Note, for these parameters the absence of an individual parameter may,
in itself be significant; e.g. there is no way to specify unbounded
strings without omitting the maximum-string-length parameter.
So here are my questions:
For case (c) above, when the document type name matches that of the file
attribute value, should the parameters be taken to be those of the file
attribute value, as is explicitly stated in case (d)? I am at a loss to
see any other interpretation.
For case (d) what are "null" parameters? Presumably for the FTAM-1
example a SEQUENCE with all the optional elements (all the elements in
this case) omitted. How is this different from the case (which would be
covered by paragraph (e)) where the real parameters of the file
attribute value are significantly omitted? If the parameters of another
document type were defined:
PARAMETERS ::= INTEGER
then how would one specify "null" parameters, case (d), as opposed to
omitting the parameters, case (c)?
Case (e) would appear to be straightforward except for the influence of
case (d). If I wish to read a file whose contents-type attribute has
the value {FTAM-1, {,80,}} (i.e. a maximum-string-length of 80 and with
universal-class-number and string-significance unspecified therefore
taking on default semantics as defined in the text of the document type
specification) and I wish to relax the maximum string length to no
maximum string length (as I am permitted to do by ISO 8571-2 section B.1
paragraph 11.1.1.2), then I must specify on the F-OPEN a contents type
of {FTAM-1, {,,}} which would seem to imply case (d) above and will
therefore take parameter values from the file attribute value (i.e.
maximum string length of 80) which is not what I intend. (I realise
that this example may be a little contrived and that one could ask why
should I want to do this in the first place, but I do not think that
that is the point here.)
My investigations so far lead me to believe that this matter has already
been discussed in various circles, in particular EWOS, but I have been
unable to find the relevant minutes etc. This subject is already very
confused (at-least to me) so I should be pleased to receive precise and
detailed replies, especially from those who have already considered it.
Regards, Alan Young. grieve@cos.com (David Grieve) (11/09/90)
In article <1006@sl10c.concurrent.co.uk> Alan Young <awy@concurrent.co.uk> writes:
]I have a problem with interpretation FTAM Part 2 (ISO 8571-2 or BS
]7090:Part 2:1989) concerning section 12.3 "Contents Type" and the use of
]the Contents-type attribute on an F-OPEN request (ISO 8751-3 section
]17.1.2.4).
]..
](paragraphs c, d and e of section 12.3).
]
] c) a document type name without parameters, in which case the match
] must be exact;
]
] d) a document type name with null parameters, in which case the name
] must match, but the parameter values are supplied from the attribute
] value;
]
] e) a document type name with non-null parameters, in which case the
] name must match, and the parameters must match or be a relaxation.
]
]For case (c) above, when the document type name matches that of the file
]attribute value, should the parameters be taken to be those of the file
]attribute value, as is explicitly stated in case (d)? I am at a loss to
]see any other interpretation.
Yes. 17.1.2.4 states that if the open regime is successful, then the
response conveys the contents type file attribute. In otherwords,
the attributes with which the file was created are returned.
]For case (d) what are "null" parameters? Presumably for the
]FTAM-1 example a SEQUENCE with all the optional elements (all the
]elements in this case) omitted. How is this different from the
]case (which would be covered by paragraph (e)) where the real
]parameters of the file attribute value are significantly omitted?
I believe the difference is that null parameters (case d) would be the
parameter field encoded with a length of zero. 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.
--
uunet!cos!grieve | Opinions expressed are not | Typos are intellectual
1750 Old Meadow Rd | necessarily those of the | property of the author.
McLean, VA 22102 | Corporation for Open Systems | "Ask me why and my reply
+1-703-883-2718 | or any standards body. | is 'Why not?'" H. Axtonawy@concurrent.co.uk (Alan Young) (11/12/90)
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.