What about a Target Feature Directory?
Alan
-----Original Message-----
From: Gregory LeClair [mailto:gleclair@agentz.com]
Sent: Thursday, September 23, 1999 9:10 AM
To: 'PJohansson@aol.com'; P1394@pwg.org
Subject: RE: P1394> Feature Directory for an initiator?
This seems reasonable to me to leave out the initiator feature directory.
Greg LeClair
-----Original Message-----
From: PJohansson@aol.com [SMTP:PJohansson@aol.com]
Sent: Wednesday, September 22, 1999 6:23 PM
To: P1394@pwg.org
Subject: P1394> Feature Directory for an initiator?
I've made almost all the changes ratified in Denver to a new PPDT_r07.
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