[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Closing Rel-87
Ok, here are the notes from the July 19th con. call minutes.
It reads "amended to use a single rm-fault code element". My intention and interpretation
was that element name is Fault (was RMFault) with the fault code QNAME as the value.
Infact, in my initial and accepted proposal for REL-87, the Fault part just says:
Fault
- QNAME.
Hope this clarifies the issue,
-Sunil
------------
Sunil summarized that the detail sub element of fault should not be used. Instead we will send them as a new header rm-fault.
Sunil stated that this will make us soap 1.1 compliant.
Doug B asked why we need the rm-fault wrapper, Why not define a RM-fault code. Why do we need both fault code and fault in rm namespace.
Sunil agreed it is better for One soap header element rmfault code with xsd:Qname as value.
Sunil moved to close issue 46 with the above resolution, amended to use a single rm-fault code element. Seconded by Doug B.
No opposition, issue 46 is closed with resolution.
---------------
Sunil Kunisetty wrote:
> 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.
>
> 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]