ST_ITS (initiator transport server) state machine question

[Elliott, Robert (Server Storage)]

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1412011_f.htm">HTML-formatted message</a>

A TASK frame is valid at any time - there's no special state after an
XFER_RDY frame that promises to keep certain other frames away.  The TASK
frame has its own initiator port transfer tag, so it won't be confused with
the frames for the command(s) it is managing (for QUERY TASK and ABORT TASK,
the INITIATOR PORT TRANSFER TAG TO MANAGE field inside the TASK frame is what
ties them together).
Not ever seeing DATA frames triggers the initiator response timeout (if
enabled).
---
Rob Elliott    HP Server Storage
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Friday, 28 November, 2014 5:15 PM
To: t10 at t10.org
Subject: ST_ITS (initiator transport server) state machine question
I am receiving reports of what seems like a quirky behavior vis a vis the
SPL-4 working draft.
The observed events are as follows.
  1.  A write command is sent to the device server.
  2.  When the device server responses to host with an XFER_RDY IU, one
normally expects the application client to send DATA IUs.
  3.  Instead, the task manager receives a TASK IU with the TASK MANAGEMENT
FUNCTION field set to 80h (i.e., QUERY TASK).
  4.  The task manager responds to the TASK IU with the Service Response set
to FUNCTION SUCCEEDED, but ...
  5.  The device server never receives the DATA IUs expected as a result of
the XFER_RDY IU.
SPL-4 r01 appears to say that there is one ST_ITS state machine for each
possible command and task management function, which suggests to me that
there should be no interactions between the XFER_RDY IU and the TASK IU
(unless the TASK IU causes the command to be aborted, as specified elsewhere
in SPL-4).
What am I missing?
All the best,
.Ralph