Agenda: WS-A telcon 2005-12-12

W3C Web Services Addressing Working Group - distributed meeting agenda
   Monday, 12 Dec
   21:00-23:00 UTC; 13:00-15:00 US/Pacific; 16:00-18:00 US/Eastern;  
21:00-23:00 UK/London; 22:00-24:00 FR/Paris; 7:00-9:00 (Tuesday) AU/ 
Brisbane; 8:00-10:00 (Tuesday) AU/Melbourne

   Dial-in information on WG Admin page <http://www.w3.org/2002/ws/ 
addr/admin>

1. Roll call, select scribe
(see scribe list below)

2. Agenda review, AOB

3. Call for corrections to the minutes
   - 2005-11-28: <http://www.w3.org/2002/ws/addr/5/11/28-ws-addr- 
minutes.html>
   - 2005-12-05: <http://www.w3.org/2002/ws/addr/5/12/05-ws-addr- 
minutes.html>

4. Review action items <http://www.w3.org/2002/ws/addr/ 
admin#actionitems>
     2005-11-28: i059 - Jonathan Marsh to maintain option 3 as a  
separate proposal.  PENDING
     2005-12-05: i066 - Jonathan Marsh to make concrete, non- 
referencing proposal.  PENDING

5. Test Suite Update

6. Proposed and New Issues

* i066 - wsaw:UsingAddressing as a policy assertion
   Owner: ???

7. Working Draft Issues <http://www.w3.org/2002/ws/addr/wd-issues/>

* i059 - Support for asynchronous / multi-MEP usage of web services
   Owner: Glen Daniels
   ACTION: 2005-11-28: Jonathan Marsh to maintain option 3 as a  
separate proposal.  PENDING
   Proposal 1: <http://lists.w3.org/Archives/Public/public-ws- 
addressing/2005Oct/att-0116/ProposalTake3.htm>
   Proposal 2: <http://www.w3.org/mid/D1503191-88CA-4537- 
A20A-1F891F43606D@Sun.COM>
   Proposal 3: <http://lists.w3.org/Archives/Public/public-ws- 
addressing/2005Dec/att-0010/ProposalLastWithoutDefaults.html>
   Proposal 4: <http://www.w3.org/mid/438CA309.9070406@tibco.com>
   Discussion: <http://www.w3.org/mid/239DAF7F-6BAE-47D6- 
A2FC-5B06F55575E5@Sun.COM>

8. Candidate Recommendation Issues <http://www.w3.org/2002/ws/addr/cr- 
issues/>

* cr10 - TAG Request for Change to WS Addressing Core
   Proposal 1: Add note: Web Architecture dictates that resources  
should be identified with URIs.  Thus, use of the abstract properties  
of an EPR other than wsa:address to identify resources is contrary to  
Web Architecture.  In certain circumstances, use of such additional  
properties may be convenient or beneficial, perhaps due to the  
availability of QName-based tools.  When building systems that  
violate this principle, care must be taken to weigh the tradeoffs  
inherent in deploying resources that are not on the Web.
   Proposal 2: The Web Architecture dictates that resources should be  
identified with URIs. Thus, use of the abstract properties of an EPR  
other than [destination] to identify a resource may result in it not  
being on the Web. In certain circumstances, use of such additional  
properties may be convenient or beneficial. When building systems  
that use non-URI identifiers, care must be taken to weigh the  
tradeoffs inherent in deploying resources that are not on the Web.
   Proposal 3: The Web Architecture dictates that resources should be  
identified with URIs. Thus, use of the abstract properties of an EPR  
other than [destination] to identify a resource is out of the scope  
of the Web Architecture. In certain circumstances, use of such  
additional properties may be convenient or beneficial. When building  
systems that use non-URI identifiers, care must be taken to weigh the  
tradeoffs inherent in deploying resources that are not on the Web.
   Proposal 4: The Web Architecture dictates that resources should be  
identified with URIs. Thus, use of the abstract properties of an EPR  
other than [destination] to identify a resource loses core benefits  
of the Web Architecture [AoWWW 2.1]. In certain circumstances, use of  
such additional properties may be convenient or beneficial. When  
building systems that use non-URI identifiers, care must be taken to  
weigh the tradeoffs inherent in deploying resources that are not on  
the Web.
   Proposal 5: The W3C Architecture of the World Wide Web [AoWWW]  
recommends as Best Practice [Section 2.1] the use of URIs to identify  
resources. Following this best practice precludes the use of abstract  
properties of an EPR other than [destination] to identify resources.   
In certain circumstances, such a use of additional properties may be  
convenient or beneficial.  However, when building systems, the  
benefits or convenience of identifying a resource using reference  
parameters should be carefully weighed against the benefits of  
identifying a resource solely by URI.

* cr13 - Two additional predefined faults

* cr14 - Relation of SOAP Headers to transport-level headers

* cr15 - Exact relationship of anonymous URI to SOAP  request-response
   Proposal 1:
          Replace the first two sentences of the section so that the  
section as a whole reads:
          In the context of a SOAP request-response MEP, sending a  
response message to an EPR whose [address] is "http://www.w3.org/@@@@/ 
@@/addressing/anonymous" means sending it as the response message of  
the MEP.  For instance, the SOAP 1.2 HTTP binding[SOAP 1.2 Part 2:  
Adjuncts] puts the reply message in the HTTP response.

9. Other Business

-----------------------------------------------------------
Scribe list

A participant from the Member at the top of the list is expected to  
scribe the meeting. If no participant from that Member is able to  
scribe, a participant from the the next Member on the list is  
expected to scribe, and so forth. After one participant from a Member  
scribes, that Member's name goes to the bottom of the list.

Systinet
Datapower
Novell
SAP
TIBCO
webMethods
Microsoft
Fujitsu
BEA
BT
Sonoa
Sonic
W3C
Nokia
Hitachi
CA
HP
IBM
Oracle
Arjuna
ERICSSON
IONA
Nortel
Sun

See <http://www.w3.org/2002/ws/addr/minutes.html> for more  
information about taking minutes.


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Thursday, 8 December 2005 23:49:04 UTC