Open XMLP issues that could be closed

Hi David.

Please find below below a list of issues that are close to closure:
- Not an issue: 24.
- Resolved: 100, 109, 111, 115, 118, 123.
- Might be able to be closed after clarification: 71, 107, 122.

I am going to edit the issues list to reference this email (from the
www-archive archive) for the specificied issues, and I am also going
to do the proposal/resolution switch.

------------
Issue 24[1]:
------------

The proposed resolution suggests that this is not an issue; the July
25th teleconference minutes[9] state:

   Issue 24. Proposed resolution sent to eric@microsoft. Chair will
             continue to investigate.

The issues list does not reflect progress about this.

------------
Issue 71[2]:
------------

The issue should be clarified, and might be closed. I propose to take
ownership of the issue and get some clarifications from the
originator (Mark Nottingham):

This issue has 3 parts:

  - SOAP allows targeting through the " actor " attribute. The value
    of the attribute may be underspecified; currently, there is no
    standard way to refer to intermediaries with a URI.

    I am not sure that this is really an issue. actor is of type
    anyURI, and people should be able to use any URI they want.

  - Additionally, it may be desireable to target an XP Block by means
    other than direct reference or 'hop-by-hop', as described.

    This would need more details. Any actor can have several
    identities, and a generic URI for, say, caching systems could be
    used, which might address this.

  - Also, SOAP's processing model does not dictate the order in which
    multiple headers should be processed, if targetted at the same
    processor.

    The clarification to made to the processing model in the July 9th
    draft[3] addresses this comment:

       It is possible that the processing of particular SOAP block
       would control or determine the order of processing for other
       SOAP blocks. For example, one could create a SOAP header block
       to force processing of other SOAP header blocks in lexical
       order. In the absence of such a SOAP block, the order of
       processing is at the discretion of the SOAP node.

-------------
Issue 100[4]:
-------------

The issue should be closed. I propose sending the following text to
the originator (Glen Daniels):

A proposed rewording[5] was accepted by the Working Group on the
August 8th teleconference[6], and the editors' copy states[7]:

   The SOAP mustUnderstand attribute is useful for detecting situations
   in which a SOAP block targetted at a node is not understood (see 2.4
   Understanding SOAP Headers) by that node; it is not intended as a
   mechanism for detecting errors in routing, misidentification of nodes,
   failure of a node to serve in its intended role(s), etc. any of which
   may result in a failure to even attempt processing of a given header
   block. For that reason, this specification does not require any fault
   to be generated based on the presence or value of the mustUnderstand
   attribute information item on a header block not targeted to the
   processing node. Processors SHOULD NOT generate such faults, and this
   specification includes no standard representation for such a fault.
   This rule applies to the endpoint as well as to intermediaries; it is
   not in general an error for a mustUnderstand header block targeted to
   a node other than the endpoint to reach the endpoint without having
   been processed.

The first processing model described applies here: "the processor
receives a message, decides which pieces are for them (via the actor
attribute and some magic which lets them know out-of-band whether or
not they are an intermediary or the ultimate destination), and then
applies the rest of the SOAP semantics (mustUnderstand in particular)
to ONLY those pieces".

-------------
Issue 107[8]:
-------------

It seems that, although the Working Group decided of a resolution, the
editors' copy does not reflect this decision. I might have missed it
though.

The Working Group resolved this issue in during the July 25th
telconference[9]. The editors' copy[10] contains the following change:

Section 4.2.3[7]:
  As described in 2.4 Understanding SOAP Headers, the SOAP
  mustUnderstand attribute information item is used to indicate
  whether the processing of a SOAP header block is mandatory or
  optional at the target SOAP node.

However, it is not clear that the following adopted change is present
in the specification:

  (ii) add the following sentence to the end of section 4.2.2 "The
  processing rules regarding mustUnderstand and the generation of
  faults apply to all headers, whether the ACTOR is implicitly or
  explicitly defined, and whether or not the ACTOR value is
  user-created."

I do not think that neither section 2.5[11] nor section 4.2.3[7]
explicitely say this.

I am going to contact Eric Jenkins (owner of the issue) for a
clarification.

--------------
Issue 109[13]:
--------------

I believe that this issue should be closed, and the following should
be sent to the originator (Chris Ferris):

During the August 8th teleconference[14], the Working Group decided to
remove the HTTP Extension binding; the editors' copy states[15]:

6.3 The HTTP Extension Framework
       
Editorial note: MJH                                20010809
   Due to it's status as an experimental RFC[17], all normative
   references to the HTTP extension framework[16] have been removed from
   this specification. Unless feedback to the contrary is received, the
   remains of this subsection, including this note, will be removed from
   the next working draft.

--------------
Issue 111[16]:
--------------

Issue 111 has been resolved and should be closed. The following text
should be put in the resolution section (the originator is Gudge and
took care of the resolution):

The Working Group has decided during the June 27th teleconference[17]
to use a closed model for the fault element. The July 9th Working
Draft reflect this change, both in the schema:

  <xs:complexType name="Fault" final="extension" >
    <xs:annotation>
          <xs:documentation>
            Fault reporting structure
          </xs:documentation>
        </xs:annotation>
    <xs:sequence>
      <xs:element name="faultcode" type="xs:QName" />
      <xs:element name="faultstring" type="xs:string" />
      <xs:element name="faultactor" type="xs:anyURI" minOccurs="0" />
      <xs:element name="detail" type="tns:detail" minOccurs="0" />
    </xs:sequence>
  </xs:complexType>

and in the specification:

  "Other Fault subelements MAY be present, provided they are
  namespace-qualified" was removed from the specification.

--------------
Issue 115[18]:
--------------

This editorial change was made in the editors' copy[10]. I propose to
close the issue and notify the originator that the specification has
been corrected.

--------------
Issue 118[19]:
--------------

Same resolution as issue 115.

---------------
Issue 122[[20]:
---------------

I propose to take ownership of the issue and to get back to the
originator in order to find out what the problem was since it is not
clear to me.

--------------
Issue 123[21]:
--------------

Same resolution as issue 115.

  1. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x24
  2. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x71
  3. http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383605
  4. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x100
  5. http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0065.html
  6. http://www.w3.org/2000/xp/Group/1/08/08-pminutes.html
  7. http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html#soapmu
  8. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x107
  9. http://www.w3.org/2000/xp/Group/1/07/25-pminutes.html
  10. http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html
  11. http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html#procsoapmsgs
  13. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x109
  14. http://www.w3.org/2000/xp/Group/1/08/08-pminutes.html
  15. http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html#httpextfm
  16. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x111
  17. http://www.w3.org/2000/xp/Group/1/06/27-pminutes.html
  18. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x115
  19. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x118
  20. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x122
  21. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x123
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Monday, 27 August 2001 12:34:23 UTC