Is the issue: 'How does a target know that an
initiator supports MESSAGE REQUEST / RESPONSE?'
It may not have been captured. Let me try to recall:
OLD
1. The target needs to know the address of an
initiator who is interested in receiving these
requests.
That information can be provided in multiple ways.
PPDT_r0x does not take a stand on how the information
is provided.
2. The case of a previously registered initiator who
is no longer servicing requests exists. A target must
deal with it. A variety of retry options exist, if so
desired.
Is the wording in PPDT too vague? Can you suggest
changes to make it more clear?
3. Although the Feature directory on host Config ROM
entry is a possibility (See #1), it seems out of scope
for PPDT.
NEW
4. PPDT now provides a PING like operation independent
of the SBP-2 transport via the NOP
value on Message Request / Response.
We have to be careful of this being a fringe benefit
with no purpose that becomes mandatory....
Cheers,
-gl
--- PJohansson@aol.com wrote:
> In a message dated 99-09-27 20:57:43 EDT,
> atsnaka@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@aol.com
>
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com