OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] Closing Rel-87



 Hi Iwasa,

 My initial proposal did have RMFaultCode under RMFault. This was
 discussed in one of the con. calls and DougB mentioned why do we
 need the extra wrapper. So we got rid off RMFaultCode and just
 have RMFault, which later became just Fault.

The schema also reflects the same.

While the resolution hints that we should have no wrapper and there should
 be only one element; it seem to indicate that the element is FaultCode and
 not Fault as I was expecting.

 I need to check the con. call meetings for what was discussed then.

 ---------------
 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.
------------------------------------------------------------


 Thanks,
 -Sunil

iwasa wrote:

> 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.
> >
>
> 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]