| DISCUSSIONS: |
- From May 18th, 1998 Meeting in Crystal City, VA
- Imaging Profile
- Many updates were made to the current draft of the Imaging Profile.
- The document is still missing a section for the Command Set.
- NOTE: With this point noted, a new action item is spun off which is 980513-013 - SBP-2 Transport Command Set.
- Material in the Profile document is redundant with material in the SBP-2 and IEEE 1212 documents. Group decided to remove these sections and replace with a reference to the appropriate sopecification documents.
- Draft Review
- Action that Berkema, Shimura, Shue will integrate command set issues into profile.
- The updated document will be distributed via e-mail for review prior to next meeting.
- There will be a "page-turner" review of the next revision at the next meeting.
- The group decided that unsolicited status will be considered "out-of-scope" for the Profile document. Editor will remove the existing material in the document on this topic.
- From July 6th, 1998 Meeting in Monterey, CA
- Imaging Device Profile Review
- Editor decided to include issues and their resolutions in the profile.
- (ED Note: SBP-2 drafts maintained a running log of issues and resolutions at front of specification.)
- No comments noted in minutes on profile review.
- From August 17th, 1998 Meeting in Toronto
- Imaging Device Profile Review
- Summary:
- Suggestion 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? Suggestion that the current document be considered as a sample _template_ for other imaging devices_but that it focus only on the printer class.
- 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. Noted that Section 7 will eventually be replaced by Config ROM document.
- Suggestion 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 excessive Bus Resets.
- 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. Agreement to replac the diagram 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
- SBP-2 details
- Section 11.3 will be removed.
- Suggestion 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.
- Previously stated as out of scope - when did it re-appear?
- The Profile document will include a list of timers that should be defined.
- Reconnect timer
- Management Command response timer
- the timer used by the Initiator to issue an Abort Task Set due to Target inactivity.
- 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.)
- From September 28th, 1998 Meeting in Savannah, GA
- Imaging Device Profile Review - Revision 0.52
- Summary of Changes:
- removed several items
- added Command Set and related fixes
- added issues from last meeting and e-mail discussions
- Document available as: pwgpro52.pdf
- Review of Issues:
- Suggestion that the closed issues be collected and moved to a section separate from the open issues.
- Noted that the numbers associated with each of the Issues will change in the next draft as the auto numbering cannot track our intent.
- Issue 14.7 – Much discussion occurred about the behavior and timeout guidelines for a Target to cause a Logout.
Essentially, no one could identify a reasonable requirement for this feature.
Suggestion that the entire topic should be left up to the "upper layer(s)".
In conclusion, the group agreed to close the topic and not specify any Target Logout behavior in the document. Closed.
- Issue 14.8 – The issues about timers are all covered by existing SBP-2 functionality. Closed.
- Issue 14.9 – For Discovery details, the specification will contain both normative sections on what must be included, and informative sections on how that information could be used.
- Issue 14.10 – The group held another discussion about the alternatives of having a single Close command for both queues vs. dual Close commands—one for each queue.
- Discussion Points:
- The desired behavior(s) associated with supporting a connection termination from either end, and the suggestion of having the Initiator issue an "I'm done" command that would also serve as a Close request to the target.
- Summary:
- In conclusion of the discussion, the group decided that there is no need for an explicit TRANSPORT_CLOSE command. This command will be removed. Instead, a Logout command will be sufficient. (When the Target wants to terminate a connection, it will simply return ORBs unprocessed—until the Initiator recognizes that it should issue a Logout command.) Closed.
- Issue 14.11 – After a response to a TRANSPORT_CAPABILITIES command, it was decided that the Target should reserve resources (prior to a TRANSPORT_OPEN) only as long as a reconnect timeout period. This will also require an additional response to the TRANSPORT_OPEN command to indicate that the Target no longer has the resources previously advertised.
- Issue 14.13 – a) Greg LeClair provided an explanation for how TARGET RESET is used by drivers in commercial O/Ss. This explanation will be included in the next draft of the Profile document. b) No, we cannot define how broadly (or narrowly) the TARGET RESET event affects a device using our transport. It is currently defined in SBP-2. The Profile document will specify any additional behavior beyond that which is specified in SBP-2. (Currently, there is no additional behavior identified.)
- Issue 14.14 – Use unit unique id. Do we really need Multiple Unit Directories that are the same?
- New Issue:
- Do we need a Target to be able to issue a TRANSPORT_OPEN command?
- From November 9th, 1998 Meeting in Tucson, AZ
- Model Discussion - nothing noted on Profile
- From December 14th, 1998 Meeting in San Diego, CA
- Profile – Bridges
- Nothing to add at this point.
- Update of issue from January 21st, 1998 Meeting in Maui, HI
- Profile Review:
- None made at this meeting. Editor noted that changes from San Diego and this meeting would be rolled in before Miami.
- Open Issues Review
- Open Profile Issues
- Data packets vs. data string communication model (Winsock)
- Service discovery – Transport client command set information (?) (Toronto)
- Zero max T2I data size (closed since we removed the max T2I)
- Bridges
- Is there anything we need to do about this?
- SBP2 will require changes to work with bridges. There is nothing that can be done at this point by this committee. 1394.1 must clarify and freeze bridge spec.
- Must wait for ANSI to initiate the a bridge compatible "SBP-2 like" project through T10.
- Closed – Out of scope for version 1.0 of the standard.
- Update of issue from March 1st, 1999 Meeting in Miami, FL
- Profile Review:
- Review of PWGPRO55.pdf.
- Need to review chapter 8 drawings for the target and initiator and then merge this with the IDT_Rx and PWGPR49 documents.
- Spawned an action item to combine these proposals.
- Review of IDT (Image Data Transfer) Document:
- Reviewed document IDT_r01.pdf.
- Discussion:
- Discussion on the T2I and I2T data size vs. buffer size.
- What the operation should be for datagram and stream operations.
- T bit and what "residual" data size will be indicated.
- Issues:
- Action Item: Mike Fenelon will provide an example diagram for the use of the End_of_Message bit.
- Action Item: Reset Connection. Greg Shue will take a stab at defining the scope of this control function.
- Action Item: Peter will take the concepts from this discussion and incorporate them into the document.
- Update of issue from April 13th, 1999 Meeting in New Orleans, LA
- Profile
- Review of Open Issues and Action Items:
- Requested that we maintain a separate document on the web site that lists the closed and open issues.
- Noted in minutes to be at discretion of the WG chair.
- Open Issues Review
- Open Profile Issues
- Data packets vs. data string communication model (Winsock)
- Service discovery – Transport client command set information (?) (Toronto)
- Addressed in Document IDT_R01.pdf?
- Bridges
- Is there anything we need to do about this?
- SBP2 will require changes to work with bridges. There is nothing that can be done at this point by this committee. 1394.1 must clarify and freeze bridge spec.
- Must wait for ANSI to initiate the a bridge compatible "SBP-2 like" project through T10.
- Closed – Out of scope for version 1.0 of the standard.
|
