However, when it came time to construct a feature directory for an initiator
(with one entry, that identifies its support of "reverse login" ... or not),
I recalled a bit of history I wish I had remembered face-to-face in Denver.
At an earlier meeting (I don't recall if it was Copenhagen or Anchorage), the
idea of a feature directory for initiators was discussed. The working group
consensus was NOT in favor. My recollection is of two reasons: a) service ID
discovery was is still too poorly articulated to be of much use to targets
querying initiators and b) if the ONLY purpose of an initiator feature
directory is to characterize support for "reverse login" it is much simpler
for the target to just send something to MESSAGE_REQUEST and see what happens.
Especially in light of the NOP function added to the MESSAGE_REQUEST format,
the second point seems particularly relevant.
In short, unless someone thinks that we should add an initiator feature
directory for other purposes, I'm in favor of "pinging" an initiator at
MESSAGE_REQUEST to see if it supports "reverse login".
Comments?
Regardless of the outcome of this thread, I'm going to publish PPDT_r07 in a
few days. There's lots of other useful information we agreed in Denver.
Regards,
Peter Johansson
Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA 94707
(510) 527-3926
(510) 527-3856 FAX
pjohansson@aol.com