How about this definition. If we move the NSA Id into the main ServiceExceptionType then we can make the downStreamException element a simple assignment. <xsd:complexType name="ServiceExceptionType"> <xsd:sequence> <xsd:element name="nsaId" type="tns:NsaIdType" /> <xsd:element name="errorId" type="xsd:string" /> <xsd:element name="text" type="xsd:string" /> <xsd:element name="variables" type="saml:AttributeStatementType" minOccurs="0" /> <xsd:element name="downStreamException" type="tns:ServiceExceptionType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> On 2012-03-22, at 8:07 AM, Henrik Thostrup Jensen wrote:

Hi everyone

Following the discussion in Oxford, here is a more concrete proposal for hierarchical error codes.

Some observations / statements:

* An NSA can choose to present a single error code or a hiarchy of errors.

* A requester might get an error code related to an unknown NSA. This is okay. How to handle this is undefined, and is - like most error handly - subject to policy.

* We need a timeout error code for to indicate a timeout error.

* We probably need a "downstream error" to indicate that the NSA is functioning correctly, but that an unrecoverable error happened downstream. It is also possible for an NSA to report a "regular" error code along with an error tree, in the case that an error happened both downstream and at the NSA itself.

Message Structure:

<ServiceExceptionType> <errorId> <text> <variables> <DownstreamExceptionListType> <DownStreamError> <NSA> <ServiceExceptionType> </DownStreamError> </DownstreamExceptionListType> </ServiceExceptionType>

Comments?

Best regards, Henrik

Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg