Tom Rutt wrote:
> These issues deal with the semantics of poll response for messages
> which were not delivered due to a fault
>
> Current semantics of returning fault are as follows:
>
> For resposne reply pattern a single message fault is returned in the
> response to the reliable request.
>
> For callback reply pattern, a single message fault is returned in the
> callback containing the Fault element.
>
> It is not clearly stated, but the receving RMP could batch a bunch of
> acks in a single callback message, but there is not way to do this
> for faults.
from section 8.3 of the january face to face minutes:
Agreed to add the following clarifications to the document:
- for response reply pattern, the ack cannot be sent back on the
response to a later request.
- Multiple acks in same reply to are Allowed for callback reply pattern.
>
> Currently there is not way to indicate in a response to a poll that a
> message was not delivered due to a fault. The response to the
> poll merely lists all message IDs in the poll range which were
> delivered. Messages not in that list may be held, or may have been not
> delivered due to a fault condition.
>
> A fault element in a response to a poll, only indicates a problem wiht
> the poll request itself. It cannot be used to indicate a fault on a
> prior
> reliable messasge request.
>
> The current Response syntax is as follows:
>
> <!--
>
> Response Header Type and it's elements
> -->
> - <#> <xsd:complexType name="*ResponseType*">
> - <#> <xsd:complexContent>
> - <#> <xsd:extension base="*wsrm:RmBaseType*">
> - <#> <xsd:sequence>
> <xsd:element name="*RefToGroupId*"
> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
>
> We could add a new element to the responst type as follows
>
> <xsd:complexType name="*ResponseType*">
> - <#> <xsd:complexContent>
> - <#> <xsd:extension base="*wsrm:RmBaseType*">
> - <#> <xsd:sequence>
> <xsd:element name="*RefToGroupId*"
> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
> <xsd:element name="*RefToFaults*"
> type="*wsrm:FaultsRefType*" maxOccurs="*unbounded*" />
>
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> <xsd:complexType name="*FaultsRefType*">
> - <#> <xsd:complexContent>
> - <#> <xsd:sequence> <xsd:element
> name="*FaultCode*" type="xsd:string" maxOccurs="*1*" />
> <xsd:element name="*RefToGroupId*"
> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
> </xsd:sequence>
> </xsd:complexContent>
> </xsd:complexType>
> An example of the structure of the RefToFaults element (repeated here
> twice) would be as follows
>
>
> <RefToFaults>
>
> <FaultCode> processingError </FaultCode>
>
> <RefToGroupID> ... list of message ids in group a which had
> processing error fault ... </RefToGroupID>
> <RefToGroupID> ... list of message ids , in group b which
> had processing error fault ... </RefToGroupID>
> </RefToFaults>
>
> <RefToFaults>
>
> <FaultCode> BadHeader </FaultCode>
>
> <RefToGroupID ... list of message ids in group a which had
> Bad header fault ... </RefToGroupID>
>
> </RefToFaults>
>
> The major problem with this is the requirmenet for the receiver to
> remember which fault codes arose for each non-delivered message.
>
> However, it would give full functionality to the poll response.
>
> Tom Rutt
>
>
>
>
>
>
>
--
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
