Article View: comp.protocols.iso
Article #840Re: FTAM, Contents-type attribute
From: David Grieve
Date: Fri, 09 Nov 1990 14:13
Date: Fri, 09 Nov 1990 14:13
46 lines
2763 bytes
2763 bytes
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. Axton
Technical Details
Message-ID:
<40288@cos.com>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!cos!grieveReferences:
<1006@sl10c.concurrent.co.uk>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cos!grieve From: grieve@cos.com (David Grieve) Newsgroups: comp.protocols.iso Subject: Re: FTAM, Contents-type attribute Keywords: FTAM, Contents-type, parameters Message-ID: <40288@cos.com> Date: 9 Nov 90 14:13:00 GMT References: <1006@sl10c.concurrent.co.uk> Reply-To: grieve@cos.UUCP (David Grieve) Organization: Corporation for Open Systems, McLean, VA Lines: 46