- From: <Kevin_Thomas@ovid.com>
- Date: Tue, 22 May 2001 17:40:30 -0400
- To: rden@loc.gov
- Cc: www-zig@w3.org, www-zig-request@w3.org
Hello Ray!
Please excuse me, a thousand pardons, but we actually do use Diag-1.
Specifically, when an Ovid origin gets an AccessControlRequest that uses
Prompt-1, and if the origin's human user hits the "Cancel" key (or if the
origin decides to act as if that happened), then the Ovid origin uses
Diag-1 to send an indication in the AccessControlResponse, telling the
target that the request is rejected because of what happened.
At the target end, when we process AccessControlResponse, we simply test
for the presence of DiagRec -- if DiagRec is present, then we say "hey, it
failed" and do not analyze the contents of DiagRec. That is, our target
bags out long before it gets as far as caring about the difference between
the DefaultDiagFormat and the External within DiagRec. We coded the more
elaborate structure at the origin end, thinking that non-Ovid targets might
be interested -- obviously, we guessed wrong.
Except as noted in the preceding two paragraphs, we don't use Diag-1 at
all. Our target certainly doesn't send it in an InitResponse. Our origin
ignores Diag-1 if it's in an InitResponse (presumably from a non-Ovid
target).
Going forward, I'm changing the Ovid origin software to send
DefaultDiagFormat instead of Diag-1in AccessControlResponse. It's too late
to get the fix into the code that will surely be released in about 60 days
(hee hee), but it will be in the next major release after that.
Sorry for the delay in responding,
Kevin
Ray Denenberg
<rden@loc.gov To: www-zig@w3.org
> cc:
Sent by: Fax to:
www-zig-reque Subject: Re: Z39.50 diagnostics in Init
st@w3.org response
05/22/2001
11:25 AM
Please
respond to
rden
Mike Taylor wrote:
What's the problem here? We agreed to deprecate it because we
couldn't think of a way it was being used. Now we've thought of a
way, so let's not deprecate it.
The Diag-1 definition has two parts:
(1) "defaultDiagRec"
(2) "explicitDiagnostic"
While the defaultDiagnostic part is useful, the explicit diagnostic part,
a long and elaborate ASN.1 representation of diagnostics, most everyone
agrees, is useless baggage. (And it's about 90% of the definition; the
default part was thrown in, literally, as an afterthought.)
Please correct me if I'm wrong on that latter point. It's been my
perception that it's not useful to anyone, and when I proposed (last
summer) to depricate it, nobody objected. We did expect it would be useful
when we defined it in 1994, but I have never heard anyone say they've
implemented it.
So it seems unfortunate to have to carry along the baggage to retain the
useful part. My point is, we don't have to. Even though the "default"
part is useful, and its functionality is necessary, we have the
"General-diagnostic container" that also provides this functionality (and
more), more directly and more elegantly.
We could keep both, but consider the drawbacks: (1) there would be two
different ways to provide a diagnostic container -- Diag-1 on an Init
response and General Container for encapsulation and (2) if we retain
Diag-1, we retain its elaborate ASN.1 definition of diagnostics that will
never be implemented, and that just adds to the perception of Z39.50 as a
bloated standard.
So what do people suggest we do?
If anyone has implemented the "explicit" part, then we'll re-instate the
full Diag-1 (that is, not depricate it).
Assuming not, if anyone has implemented the default part, then we could
re-define Diag-1, for the purpose of retaining the OID, removing the
explicit part. If we do that, then we need to know: has anyone implemented
the Diagnostic Container? If not we could make Diag-1 a well-known object
and use it instead, where the Container is currently prescibed.
But if nobody has implemented any of Diag-1, please, let's just depricate
it.
--Ray
--
Ray Denenberg
Library of Congress
rden@loc.gov
202-707-5795
Received on Tuesday, 22 May 2001 17:40:54 UTC