🚀 go-pugleaf

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.