Re: [wsrm] Closing Rel-87

["iwasa" <kiwasa@jp.fujitsu.com>]

Sunil,

Could you let me know any document
(Eg. Minutes, or email) that the resolution was agreed?

The resolution for Rel-46 makes me believe
we will have FaultCode sub-element which was RMFaultCode
previously, under Fault element in SOAP header.
But I might miss the following discussion.

Thanks,

Iwasa

--
REL-46 Spec 4.4 fault Design Closed Sunil Sunil
Title: Sending Faults in Header rather than Body
Description:
As per SOAP 1.1 spec. for Faults (section 4.4),
"soap:detail MUST NOT be used to carry information
about error information belonging to header entries.
Detailed error information belonging to header entries
MUST be carried within header entries". Unfortunately,
this is not the case with the initial WS-Reliability spec.
as all WS-Reliability specific faults are sent in /Body/detail.
[[Actually, this is more an outstanding issue. It was in the
Issues list at one point, but it was removed when Issues
list was converted to Futures list as this is too low-level
(technically) to fit into the former. ]]
Payrits reminded us this is a major issue since we are
presently incompatible with SOAP 1.1. ACTION ITEM
to Sunil: Provide a proposal (or URL of same in the archive).

29 Jul 2003: Sunil sent an email today discussing REL-46
replying to Paulo's email. His proposal for this issue is
found in another email. Doug wondered why we needed the
RMFault wrapper, Sunil agrees this would be fine. Will
leave that low level detail for later.

Proposal: Stop using soap:detail and add RMFault as a
header element. Agreed to go a bit further: Define one new
header element in our namespace: RMFaultCode. This will
(likely) have the same schema defnition as current rm:faultcode
element.
Resolution: Proposal accepted, amended to use a single
RMFaultCode element.
--


>
>  Iwasa,
>
>  Fault doesn't  have any sub-element. It just wraps
>  a QNAME.
>
>  -Sunil
>
> iwasa wrote:
>
> > I got an email mentioning some portion of the
> > proposal is not correct.
> >
> > The current Header format would be:
> > MessageHeader
> >  - GroupId : MessageID [RFC2392] (see REL-37)
> >  - SequenceNumber : unsignedLong
> >  - Timestamp : UTC
> >  - ExpiryTime : UTC
> >  - ReplyPattern : STRING
> >
> >  Request
> >  - AckRequested
> >  - DuplicateElimination
> >  - MessageOrder
> >
> >  Response
> >  - RefToGroupId : MessageID [RFC2392] (see REL-37)
> >  - RefToSequenceNumber : unsignedLong
> >
> >  Fault
> >  - FaultCode
> >
> > --
> >
> > Only elements are listed above, but not for attributes.
> > And this format may be changed later to solve other issues.
> > (Eg. Multiple Acking)
> > Please let me know if you find any error above.
> >
> > Thanks,
> >
> > Iwasa
> >
> > ----- Original Message -----
> > From: "iwasa" <kiwasa@jp.fujitsu.com>
> > To: "wsrm-TC" <wsrm@lists.oasis-open.org>
> > Sent: Thursday, October 23, 2003 4:47 PM
> > Subject: [wsrm] Closing Rel-87
> >
> > >
> > > Rel 87 should be closed, because
> > > it was agreed in the F2F in September,
> > > and already updated in the spec WD 0.52.
> > >
> > > Thanks,
> > >
> > > Iwasa
> > >
> > > --
> > > REL-87 Spec  meta Design Active Sunil Kunisetty Sunil Kunisetty
> > > Title: New WS-R Headers
> > > Description:
> > > Here is a proposal for WS-R Headers based on REL-36, REL-39, REL-46.
> > > We will have 4 Headers. Once we finalize it, I can create a schema.
> > >
> > > Proposal:
> > > MessageHeader
> > > - GroupId - MessageID [RFC2822]
> > > - SequenceNumber- MessageID [RFC2822]
> > > - TimeStamp UTC
> > > - TTL or MED or whatever UTC
> > > - ReplyPattern -STRING
> > > - ReplyTo attribute - uri
> > >
> > > Request
> > > - AckRequested
> > > - DuplicateElimination
> > > - MessageOrder
> > > - status attribute = Begin, Continue, End
> > >
> > > Response
> > > - RefToMessaageId - - MessageID [RFC2392] (see REL-37)
> > > (Should be changed to RefToGroupId/RefToSequenceNumber)
> > >
> > > Fault - QNAME
> > >
> > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from the roster
of
> > the OASIS TC), go to
> >
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
> > >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>