Re: AI for more detailed faults.

Marc Hadley wrote:

> I'm a little unclear on what you think we should be adding to core. 
> You seem to be advocating that we define abstract faults in core and 
> then bind them to SOAP faults in the SOAP binding doc - is that  right
> ? FWIW, I don't think we really need to do that.

>
> I expected a different form for your proposal, I was under the 
> impression that you would be proposing some spec text to augment the 
> existing Fault section in the SOAP binding - did I get that wrong ?

We're evidently a bit disconnected here.  I'm not even sure how one
would go about defining abstract faults in the core and so forth.  To be
honest, such a thought never crossed my mind.  I'm pretty sure it
wouldn't involve so many angle brackets.

The whole idea, I thought, was to flesh out the fault definitions in
section 5 of the SOAP binding to allow for more detail should the sender
of the fault choose to include it.  The section on "how to use this and
when" was more about motivating why the elements look like they do.  I'm
not sure how much we should say about this normatively.  It would be
good to say things like "If you do include this information, it should
look like this in the fault detail," as that's the main point of
defining this in the first place.

I think everything I defined here would fit under one of the faults
defined in section 5, directly or indirectly.  In particular, the
InvalidedMessageAddressingHeader catch-all pulls in MAPCardinality,
MalformedMAP, DuplicateMessageID and MismatchedAction directly, and
MalformedMAP pulls in MissingAddressInEPR and MalformedAddressInEPR. 
That leaves DestinationUnreachable, ActionNotSupported and
EndpointUnavailable, which go in the obvious places.

Frankly, I'm not sure how best to fold this into the text.  I'm
certainly willing to help out with that, but I'd like feedback.  My
intention was not to simply dump everything in the editors' laps.

>
> Thanks,
> Marc.
>
> On Jul 15, 2005, at 3:55 PM, David Hull wrote:
>
>> Here's a more rigorous treatment of the ongoing proposal for more 
>> detailed faults.  I've managed to fold together a few of the  cases. 
>> I've also added a few faults defined in the SOAP binding.
>>
>> As before, there is open content everywhere for adding location and 
>> other pertinent information.  All attributes and content are 
>> optional.  There are no defaults.  If it's not there, we don't know 
>> the value or we do but we're not telling.
>>
>> Please let me know if any of this is not clear.
>>
>> Detail Elements (pseudoschema) <!-- EPR problems --> 
>> <MissingAddressInEPR @{any}>{any}*</MissingAddressInEPR> 
>> <MalformedAddressInEPR @{any}> <badIRI>{any}*</badIRI>? {any}* </
>> MalformedAddressInEPR> <!-- MAP problems (which in some cases stem 
>> from EPR problems --> <MAPCardinality @propertyName={PropertyName}? 
>> @inRequest={boolean}? @{any}> <ActualCardinality @role={string}>
>> {int}</ActualCardinality>* <!-- One per role, if need be, so 
>> element, not attribute --> {any}* </MAPCardinality> <MalformedMAP 
>> @propertyName={PropertyName}? @{any}> ( {MissingAddressInEPR} | 
>> {MalformedAddressInEPR} | <MalformedIRI>{any}*</MalformedIRI> | 
>> <NonAbsoluteIRI>{IRI}</NonAbsoluteIRI> )? {any}* </MalformedMAP> 
>> <DuplicateMessageID @{any}> <MessageID>{IRI}</MessageID>? <!-- Same 
>> as infoset in 3.2 --> {any}* </DuplicateMessageID> <!-- Faults 
>> mentioned in the SOAP binding --> <MismatchedAction @{any}> 
>> <SOAPAction>{IRI}</SOAPAction>? <WSAAction>{IRI}</WSAAction>? {any} *
>> <MismatchedAction> <DestinationUnreachable @{any}> <Destination>
>> {EPR}</Destination>? <!-- Same as infoset in 3.2 --> {any}* </
>> DestinationUnreachable> <ActionNotSupported @{any}> <Action>{IRI}</
>> Action>? <!-- Same as infoset in 3.2 --> {any}* </
>> ActionNotSupported> <EndpointUnavailable @{any}> <Endpoint>{EPR}</
>> Endpoint>? <RetryAfter>{unsignedLong}</RetryAfter>? {any}* </
>> EndpointUnavaiable> <!-- This is a string, not a QName, on the 
>> assumption that we're complaining about properties, not infoset 
>> items --> PropertyName = "destination"|"source endpoint"|"reply 
>> endpoint"|"fault endpoint"|"relationship"|"relationship type" Where 
>> and how to use the above The EPR elements can be used in any fault 
>> complaining about a bad EPR.  E.g., I give you an EPR to send some 
>> sort of notification to, but its [address] is not well-formed.  
>> You'll probably want to send me back a fault if possible.  If you 
>> do, you can use wsa:MalformedAddressInEPR in the detail for that 
>> fault.  Similarly, anyone receiving a message with bad MAPs may use 
>> the appropriate detail elements above.
>>
>> In terms of the places where we actually mandate a fault:
>> In core section 3.3, we MUST fault if a request is missing a [reply 
>> endpoint].  The detail should look like this:
>> <MAPCardinality property="reply endpoint" inRequest="true"> 
>> <ActualCardinality>0</ActualCardinality> </MAPCardinality>
>> In core section 3.3, we MUST fault if a request is missing a 
>> [message id].  The fault will be as above, but with 
>> property="message id".
>> In SOAP Binding section 2.4 (and in more detail later in 4.2), we 
>> MUST fault if a the wsa:Action of the message does not match the 
>> SOAP http://www.w3.org/2003/05/soap/features/action/Action 
>> property.  The detail should look like this:
>> <MismatchedAction> <SOAPAction><!--Value of SOAP property--></
>> SOAPAction> <WSAAction><!--Value of WSA MAP--></WSAAction> </
>> MismatchedAction>
>> In SOAP Binding section 3.2, we MUST fault if there is more than  one
>> To, ReplyTo, FaultTo, Action or MessageID targeted at a  recipient. 
>> Suppose, for example, there is one ReplyTo targeted at  "role1" and
>> one targeted at "role2", and the recipient is playing  both roles. 
>> The detail should look like this:
>> <MAPCardinality property="reply endpoint"> <!-- inRequest might be 
>> true, false or absent --> <ActualCardinality role="role1">1</
>> ActualCardinality> <ActualCardinality role="role2">1</
>> ActualCardinality> </MAPCardinality>
>> SOAP Binding section 5.3 defines the InvalidAddressingHeader detail 
>> element.  This should be allowed to have any of MAPCardinality, 
>> MalformedMAP, DuplicateMessageID and MismatchedAction as child  element.
>> SOAP Binding section 5.4 defines the  MessageAddressingHeaderRequired
>> detail element.  There are at least  three possible approaches here:
>> Remove it in favor of InvalidAddressingHeader with MAPCardinality 
>> children. ("children", not "child", as the receiver might be  playing
>> multiple roles, none of which supplies the header.  The  role
>> attribute on the ActualCardinality element captures this).
>> Allow it to have MAPCardinality children.
>> Try to add the information that MAPCardinality conveys (in this 
>> case, mainly which roles were active) to 
>> MessageAddressingHeaderRequired directly.
>> SOAP Binding section 5.5 defines the DestinationUnreachable subcode 
>> with no detail element.  This should allow the 
>> DestinationUnreachable detail element, to show what destination we 
>> thought we were trying to reach.
>> SOAP Binding section 5.6 defines the ActionNotSupported detail 
>> element.  This looks fine, except that it should probably allow for 
>> open content like everything else, as shown above.
>> SOAP Binding section 5.7 defines the EndpointUnavailable subcode, 
>> with the RetryAfter detail element.  I've folded this into an 
>> EndpointUnavailable detail element with open content and a slot for 
>> the offending endpoint.
>> And it looks like that's it.
>>
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>
>

Received on Friday, 15 July 2005 20:46:20 UTC