In a message dated 99-09-27 20:57:43 EDT, atsnaka at bsd.canon.co.jp writes:
<<Just for clarification...>>
More than just clarification, Ats---solid questions that aren't all resolved
in my mind either.
<<Does this ("pinging" ) imply that either: ALL PPDT initiators have to
support the message request/response mechanism, or ALL PPDT target have to
implement some retry counter to abort the reverse login process?>>
My HUNCH is that it will be impossible to require ALL PPDT initiators to
support MESSAGE_REQUEST and reverse login. I would prefer it if we could, but
my suspicion is that some widely available desktop operataing systems won't
have this functionality within the time frame we require. Perhaps someone in
a better position to know could provide some solid answers.
EVEN IF all PPDT initiators implement MESSAGE_REQUEST, it is an essentially
unconfirmed datagram service. It seems to me that targets will have to
implement retry counters and timers to manage the reverse login process.
<<...may I ask what this NOP function does?>>
Nothing. The zero value was already reserved, never to be used. I suggested
that we make it NOP, a fringe benefit that permits a target to determine that
an initiator has reverse login support without actually requesting a LOGIN.
<<Are we still going to stick with a initiator not having a unit directory?
Is the only way to discover a PPDT initiator is by the instance directory
keyword?>>
I apologize if I have lost track of a working group decision; sometimes the
minutes don't have as much detail as I would like.
I confess I am confused as to the current state of the working group opinion
on this matter. Clearly a target has an instance directory (with keywords)
that references one or more unit directories.
What DOES an initiator have? Nothing? An instance directory (as you suggest)?
I think the current draft of PPDT is silent on this matter.
Regards,
Peter Johansson
Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA 94707
(510) 527-3926
(510) 527-3856 FAX
pjohansson at aol.com