--openmail-part-11792923-00000001
Content-Type: application/octet-stream; name="1.txt"
Content-Disposition: attachment; filename="1.txt"
Content-Transfer-Encoding: base64
UmVjZWl2ZWQ6IGZyb20gcGFscmVsMS5ocC5jb20gKHBhbHJlbDEuaHAuY29tIFsxNS44MS4x
NjguMTBdKSBieSB2ZW51cy5yb3NlLmhwLmNvbSB3aXRoIEVTTVRQICg4LjcuMS84LjcuMyBU
SVMgNS4wIE9wZW5tYWlsKSBpZCBIQUEyNjg0NiBmb3IgPGFsYW5fYmVya2VtYUBocC1yb3Nl
dmlsbGUtb20yLm9tLmhwLmNvbT47IFRodSwgMTIgRmViIDE5OTggMDc6MDc6NDIgLTA4MDAg
KFBTVCkKUmVjZWl2ZWQ6IGZyb20gbGlzdHMudW5kZXJzY29yZS5jb20gKHVzY29yZS0xLm12
LmNvbSBbMTk5LjEyNS44NS4zMF0pCglieSBwYWxyZWwxLmhwLmNvbSAoOC44LjYvOC44LjV0
aXMpIHdpdGggRVNNVFAgaWQgSEFBMTU0NDA7CglUaHUsIDEyIEZlYiAxOTk4IDA3OjA3OjMy
IC0wODAwIChQU1QpClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdCAoZGFlbW9uQGxvY2FsaG9z
dCkgYnkgbGlzdHMudW5kZXJzY29yZS5jb20gKDguNy41LzguNy4zKSB3aXRoIFNNVFAgaWQg
S0FBMDIzNjA7IFRodSwgMTIgRmViIDE5OTggMTA6MDc6MjggLTA1MDAgKEVTVCkKUmVjZWl2
ZWQ6IGJ5IHB3Zy5vcmcgKGJ1bGtfbWFpbGVyIHYxLjUpOyBUaHUsIDEyIEZlYiAxOTk4IDEw
OjA2OjA5IC0wNTAwClJlY2VpdmVkOiAoZnJvbSBkYWVtb25AbG9jYWxob3N0KSBieSBsaXN0
cy51bmRlcnNjb3JlLmNvbSAoOC43LjUvOC43LjMpIGlkIEtBQTAyMjEyIGZvciBwMTM5NC1v
dXRnb2luZzsgVGh1LCAxMiBGZWIgMTk5OCAxMDowNjowMCAtMDUwMCAoRVNUKQpEYXRlOiBG
cmksIDEzIEZlYiAxOTk4IDAwOjA1OjA0ICswOTAwIChKU1QpCk1lc3NhZ2UtSWQ6IDwxOTk4
MDIxMjE1MDUuQUFBMTAwMTFAc2xhbnQxLnB1cmUuY3BkYy5jYW5vbi5jby5qcD4KRnJvbTog
QWtpaGlybyBTaGltdXJhIDxzaGltdXJhQHB1cmUuY3BkYy5jYW5vbi5jby5qcD4KVG86IEdy
ZWcgU2h1ZSA8Z3JlZ3NAc2RkLmhwLmNvbT4KQ2M6IHAxMzk0QHB3Zy5vcmcsIFAxMjg0XzNA
bGV4bWFyay5jb20sIExhcnJ5IFN0ZWluIDxsc3RlaW5AZmFwby5jb20+ClN1YmplY3Q6IFJl
OiBQMTM5ND4gMTI4NC40IG92ZXIgU0JQLTIKSW4tUmVwbHktVG86IDwxOTk4MDIxMTAzMjEu
VEFBMjE2NTJAaHBzZGxnajEuc2RkLmhwLmNvbT4KUmVmZXJlbmNlczogPDE5OTgwMjA5MTYy
OS5JQUEyMjcxMEBiYXJsZXkuYWRuYy5jb20+IDwxOTk4MDIxMTAzMjEuVEFBMjE2NTJAaHBz
ZGxnajEuc2RkLmhwLmNvbT4KTWltZS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PVVTLUFTQ0lJCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdi
aXQKWC1NYWlsZXI6IEJlY2t5ISB2ZXIgMS4yMwpTZW5kZXI6IHAxMzk0LW93bmVyQHB3Zy5v
cmcK
--openmail-part-11792923-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="Re:"
Content-Transfer-Encoding: 7bit
I tend to favor option B as well.
I think Shimura san has some good points at the end of his message
that goes to the heart of what is still not clear with the option B
proposal. I think we need to work up some example scenarios and
explore exactly how this will work. Greg Shue got any ideas here.
regards,
Alan
______________________________ Reply Separator _________________________________
Subject: Re: P1394> 1284.4 over SBP-2
Author: Non-HP-shimura (shimura at pure.cpdc.canon.co.jp) at HP-Roseville,mimegw3
Date: 2/12/98 7:05 AM
On Tue, 10 Feb 1998 19:21:19 -0800 (PST)
Greg Shue <gregs at sdd.hp.com> wrote:
> > I await your responses.
>> OK, here we go...
OK, I'll follow...
> Larry Stein wrote:
>> > At this point in time we have apparently narrowed our potential solutions
> > to the following:
> >
> > A- 1284.4 with SBP-2
> > B- New SBP-2 command set with SBP-2
(snip)
> As I understood it, the ability for 'a peripheral to operate over
> various interfaces without requiring major architectural changes
> to the product' is provided by meeting the specified transport
> service requirements. As long as the transport requirements are
> met, no architectural changes are required of the product. Thus,
> the transport layers are all modular with respect to the product.
I agree. This was original intent of the HPT which Ueda-san and I
introduced from last June meeting.
(snip)
> Given all of this, I am compelled to support option B.
Basically, I also support to consider option B, but it is still not
clear for me how the data transfer of each direction is done
independently within single login in SBP-2 only solution.
If target request data transfer by "Data Available" flag in certain
status block, initiator will subsequently append "SND data-in" ORB in
the current task list. It will be possible for the target to check if
there is a "SND data-in" ORB in the task list BEFORE the initiator
appends the "SND data-in" ORB. After finding there is no "SND data-in"
ORB, the target may issue another unsolicited status which indicates
"Data Available". By this status, the initiator may append one more
(total two) "SND data-in" ORB in the task list. After that, the
target will need to abort the excessive ORB.
Is this a way the SBP-2 only solution works?
I think that aborting tasks implies subsequent task retries, and may
not be efficient.
It seems natural to make two independent logins for each direction,
one for down-link and another for up-link by using the idea to map
them into logical units. Furthermore, by extending this to allow to
allocate up-link in reverse fashion (i.e., the target of down-link
makes a login to the initiator of down-link), the link between two
devices will become symmetric if both ends have both initiator and
target functionality.
Any suggestions?
--
Akihiro Shimura (shimura at pure.cpdc.canon.co.jp)
Office Imaging Products Development Center 3
CANON INC.
--openmail-part-11792923-00000001--