Don Wright provided the details for the next PWG meeting:
Savannah Marriott Riverfront
Savannah, GA 31401
100 General McIntosh Blvd.
Savannah, GA
912 233-7722
September 28-October 2
$165 room rate
He announced the draft meeting schedule for 1999, indicating that it
would be discussed further at the PWG Plenary meeting on Wednesday:
. Jan 18-22 Maui (Joint PWG/PWG-C)
Jan 27-29 1394TA Maui
. Mar 1-5 Miami
. Apr 12-16 New Orleans
Apr. 4-9 Comdex Tokyo
. May 24-28 Philadelphia
May 11-14 WWW8 Toronto
May 10-11 W3C AC Meeting
May 31-Jun 4 N+I Tokyo
Jun 22-24 PC-Expo NYC
. Jul 5-9 Copenhagen, Denmark (other European site?)
Jul 12-16 IETF Oslo
Jul 14-16 Comdex Canada
. Aug 16-20 Alaska
. Sep 27-Oct 1 Denver
. Nov 2-6 San Juan, Puerto Rico
Nov 8-12 IETF Wash DC
Nov 15-19 Comdex
. Dec 13-17 Los Angeles
1394 PWG Meeting, August 17-18, 1998
Greg LeClair presented the proposed agenda topics:
. GAP Control
. Recovery
. Command Set
. Open Profile Issues
3.
Ueda-san presented a few slides on the _gap control_ method used to
maintain coordination and recovery of command processing between the
Initiator and Target.
He believes that the _enforced sequential command tag_ approach is
inefficient for command set recovery, because there can be overhead
introduced even in normal operation situations. To avoid the
inefficiency two rules are proposed:
. Target determines whether the command is ahead or behind
current position based on the sign of the distance between
them.
. Initiator is responsible to keep the actual sequence of tasks
in the task list to be recognized correctly by the target.
Shimura-san has distributed a description of the proposal via e-mail.
Ueda provided example cases illustrating different situations that may
occur in an error recovery situation.
There was some discussion about the process of aborting a task by using
a _dummy orb_. Greg Shue explained the Abort Task Set management
function. He feels that the Abort Task command can possibly cause
problems. The issue about aborting a task is that there is no guarantee
that the Initiator will actually respond to the Abort Task request.
Greg Shue asked Ueda-san what the _normal condition_ would be that
would cause inefficient operation. Ueda gave the example of a paper-jam
or out-of-paper condition. After a bit of discussion, there is still
unresolved disagreement about how frequently this situation will really
occur_and therefore how much efficiency is really gained by the
proposal.
ISSUE: Once a Target's fetch agent has transitioned to a dead state,
how long will it wait for an Initiator to do error recovery before it
takes action on its own? How long do we stay in a dead state? This
issue is currently felt to be beyond the scope of the specification
because it is application specific. If it needs to be resolved at a
higher level, we may need to provide a mechanism to achieve it.
4.
Recovery
Ueda-san also gave a presentation on the Error recovery model used in
Canon's SHPT proposal. A few optimization methods were proposed:
. use same physical memory for application buffers and transport
buffers
. use same size buffer as 1394 transaction for error recovery
1394 PWG Meeting, August 17-18, 1998
. sender can directly write data to buffer in receiver specifying
the 1394 address
For error recovery, the Initiator must keep the contents of the data
buffers associated with the ORBs in the linked list, and the Target
must guarantee not to execute any data and command twice. [The slide in
Ueda's presentation was missing the word _not_.]
The Initiator must guarantee that the contents of the data buffer will
not change over a Bus Reset.
Ueda proposes that a special value of 0 for Max_T2I_DATA_SIZE should
indicate that the Target does not need to guarantee to hold and re-send
data. (The Initiator will guarantee to maintain the contents over a Bus
Reset.)
Greg Shue pointed out that the value of zero is already used to
indicate that no data will be transferred in that direction. He
suggested that another (new) parameter could be defined to indicate the
capability proposed by Ueda.
Greg agreed that the capability to indicate to a Target that the
Initiator will retain the data contents of a data block and its
Sequence ID over a Bus Reset was a reasonable feature. However,
discussion of the method for indicating this feature was deferred until
the Command Set topic was addressed.
Much discussion occurred about whether the contents of the page-tables
for the buffer could be relied upon after a Bus Reset. Generally,
people feel that the Target should re-read the page table (in case the
pointers to the data contents have changed.)
5.Command Set
Greg Shue has issued revision 0d of the PWG 1394 Transport Command Set
Proposal. He led the group in a page-by-page review of the latest
revision, asking for comments.
Ueda-san commented that the Open and Close Transport commands are not
symmetrical. The Transport_Open command is issued for both queues, but
the Transport_Close is issued for only one queue at a time. Greg
explained that the reason for this was to allow the Initiator to
indicate that no more writing to the write queue will occur, but
reading will continue on the read queue.
The group discussed whether or not Greg's reason was a valid situation.
After not being able to identify a specific situation to justify the
capability, the group agreed to change the Transport_Close to apply to
both queues. However, Greg noted that once a Close is done to both
queues, there is nothing that can be done next_except a Logout.
Therefore, he suggests that the Transport_Close command is redundant to
the Logout command. (Although unsolicited status could be generated
before a Logout, it was not felt that this was a reasonable event.)
If Transport_Close is eliminated (because it is redundant to Logout),
this would also create an asymmetrical situation for Transport_Open.
The Get_Transport_Capabilities command was discussed. Brian noted that
when a Target responds with certain transport capabilities, it must
reserve those capabilities for the duration of that Login.
Greg LeClair suggested that we should keep the Close command to allow
some kind of acknowledgment of the Close command. Using Logout does not
provide any chance for a reply.
After much discussion about the above issues, no consensus was reached,
and the topic was deferred.
ISSUES:
. Should we have a Transport_Close command of any type_either
applicable to a single queue or both queues?
. What behavior should occur after a Close and after/during an
Open?
. If we eliminate the Transport Close command, should the Open
command be renamed?
ISSUE: What should be done about the following case? An initiator opens
a connection, carries on a conversation, closes both queues for
communication, and then does a TARGET RESET? Presumably, this would
allow another TRANSPORT_OPEN to be issued without having the initiator
Logout, though it would affect all other initiators logged in to that
target by generating a UNIT ATTENTION condition. Because we must
support TARGET RESET to be SBP-2 compliant, this situation must be
supported as well.
ISSUE: Should we support ABORT TASK?
Greg Shue points out that the Target has the option to ignore the ABORT
TASK command_once it has fetched the ORB.
Greg LeClair claims that if an Initiator Aborts a task, it must Abort
all the remaining ORBs in that queue, and must resubmit them with the
same sequence IDs.
ISSUE: What do we do if the Target responds to an Abort Task with _I
completed the ORB_ (instead of acknowledging it as a Dummy ORB?) This
condition might cause the Target to process data that shouldn't have
been. This can cause problems for a printer data stream.
CONCLUSION: The PWG Profile will state that the client SHALL NOT issue
an Abort Task (because we cannot guarantee the execution of an Abort
Task request, and this might cause unpredictable behavior.) [It was
also noted that Microsoft does not support the Abort Task capability.]
Greg LeClair suggests that any desire to abort a large print job should
be handled at a higher level_perhaps on a job cancel basis.
ISSUE: Abort Task Set is used by a _soon-to-be_ commercially available
O/S in response to a timeout condition. The group needs to examine and
understand what the condition details are.
The group agreed to add a new parameter to indicate that the Initiator
will maintain data buffer content integrity across Bus Resets (to
address the proposal made by Ueda-san earlier.)
1394 PWG Meeting, August 17-18, 1998
ISSUE: The Profile document should include an explicit statement on the
padding order and the placement of data bytes less than a full quadlet
(e.g. a diagram showing a five-byte data value.)
MOTION: At the end of the page-by-page review, Alan Berkema made a
motion to include the latest revision of the Command Set document into
the Profile document. Greg Shue seconded the motion.
Ueda-san requested that additional evaluation and changes to the
Command Set information should still be possible. Greg LeClair (and
others) agreed that comments and changes are still possible, but that
the motion is primarily a convenience to the Profile editor_and an
acknowledgment that the Command Set information is _relatively stable_.
VOTE: The motion passed unanimously. Alan Berkema will incorporate the
material into the next revision of the Profile document.
ISSUE: How do we pass down Sockets implementation information into the
Command Set? No resolution was reached on this issue.
6. Config ROM Review and IEEE 1212r
Greg LeClair briefly reviewed the latest activity in 1212r and
referenced his CSR and Config ROM proposal that is posted.
According to Greg, the FDS proposal and other discovery concepts have
been _stabilized_ at the Bath meeting last month. (Greg noted that this
doesn't necessarily mean that it can't become unstable in the future.)
The group believes that there should be a class registry monitored and
maintained by the 1212r group.
Next meetings for 1212r are planned for September 9-10 in Chicago and
October 15-16 in Maui.
Alan Berkema asked if the Config ROM document is ready to be included
into the Profile document. The group decided that we should wait until
the document is updated to reflect the most recent 1212r activity and
reviewed by the group.
7. PWG Profile Document
Alan Berkema led the group in a _page-by-page_ review of the latest
Profile document.
It was suggested that a re-write of the Purpose section be considered
and proposed on the e-mail reflector for review. A few individuals felt
that the current description is not as accurate as it could be. There
was a question on how specific we should be in terms of addressing
specific device classes. Should we really attempt to address all
imaging devices_or consider separate documents for each device class?
It was suggested that the current document be considered as a sample
_template_ for other imaging devices_but that it focus only on the
printer class.
1394 PWG Meeting, August 17-18, 1998
The definition of Queue should be changed to reflect a sequence of
ORBs_not just a collection.
The Config ROM block diagram (Figure 2) should be updated for accuracy.
It was noted that Section 7 will eventually be replaced by Greg
LeClair's document on Config ROM. The group then reviewed the Config
ROM document contents, identifying several edits that Greg will include
in the next revision.
There was a long discussion about the section on Device Discovery (in
the Config ROM document.) A concern was raised about whether a Bus
Reset should be generated every time the device configuration changes_
and a corresponding change to the values of the Config ROM is possible.
(This could certainly lead to excessive bandwidth problems.) It was
suggested that the Profile document should inform an implementor that
any change in the Config ROM values shall not be made until the next
Bus Reset. However, it should be worded in such a manner that does not
encourage Bus Resets unnecessarily.
Section 9 of the Profile document will be re-worded so that it does not
say every command will have the ORB notify bit set to zero. Not every
ORB needs to have its notify bit set.
Sections 10 and 11 will get replaced by the Command Set description
content.
Figure 4 in Section 11.2 _ There was some concern that the diagram
might be confusing because it has too much detail. Isoda-san was
volunteered to change his _Whole Model_ diagram into an editable Word
format or PowerPoint format. The group would like the diagram replaced
by a sequence of (four?) drawings_each one showing a progression of
detail in the communication flow between the client and server:
client/server, 1394 PWG, _SBP-2 cloud_, and _SBP-2 details.
Section 11.3 will be removed.
It was suggested that Section 12 should include a reference to
maintaining _fairness_ of access when supporting multiple Logins.
Sections 13, 15, 18, 19, 20, and 21 will be replaced/superseded by the
Command Set description content.
The list of Issues contained in the Profile document (Sections 23-27)
were very briefly reviewed and evaluated.
The group decided that Unsolicited Status Register service will not be
provided to a higher layer. Therefore no policy is needed.
The Profile document will include a list of timers that should be
defined. The discussions identified three timers: Reconnect timer,
Management Command response timer, and the timer used by the Initiator
to issue an Abort Task Set due to Target inactivity. Alan will start a
discussion via e-mail to identify any other timers that might be
necessary.
ACTION: Brian volunteered to write up a description clarifying the
differences between datagram- and datastream-based services.
1394 PWG Meeting, August 17-18, 1998
ACTION: Alan said that he will update and issue a new version of the
Profile by September 10.
ACTION: Greg LeClair will maintain a prioritized _List of Active
Issues_ for tracking and reference within the group.
ISSUE: The Profile document should include an explicit statement on the
padding order and the placement of data bytes less than a full quadlet
(e.g. a diagram showing a five-byte data value.)
8. Greg Shue believes that we are ready to (begin to) create a set of
scenarios for testing interoperability. It was suggested that we should
plan to discuss possible scenarios at the next meeting.
Greg LeClair asked if any companies might be ready with a prototype for
interoperability testing before December. Epson, HP, and Canon all
indicated that they might have something.
9. OUI Issues
Greg LeClair discussed the issue of Organizationally Unique Identifiers
(OUI):
. Do we need to have an OUI for the 1394 PWG Profile?
. Cmd_Set_Spec_ID in the Unit Directory
. possibly needed for `Printer' value of the Function_Class
entry in Instance Directory (formerly FDS)
. useful as a Spec_ID for other locations
. Options:
. select a standards body and get a RAC assigned OUI
. buy OUI as 1394 PWG
_ maintenance and administration problems?
Greg asked: _Would the individual companies represented at the 1394 PWG
group be willing to contribute $$$ to pay for an OUI?_ If the group
does buy one, how will it (and sub-identifiers) be administered,
maintained, and managed?
It was suggested that we obtain an OUI from the 1394 TA. However, they
will not give one out until we have a completed document_and we agree
to abide by their by-laws.
MOTION: Brian Batchelder made a motion that the 1394 PWG members
request that the PWG organization purchase an Organizationally Unique
Identifier (OUI) from the IEEE RAC. This OUI will be maintained and
administered by that organization.
VOTE: The motion passed unanimously.
Meeting adjourned.