AI for more detailed faults.

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:
          o 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).
          o Allow it to have MAPCardinality children.
          o 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.