RE: Agenda: WS-A telcon 2005-12-05

Mark, 

I see that my action item is pending. However, ProposalLastWithoutDefaults below (which is Proposal4) is the writeup that satisfies the action item reflecting the consensus from last week's concall. 

Thanks, 

--umit
 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Mark Nottingham
> Sent: Sunday, Dec 04, 2005 11:52 AM
> To: WS-Addressing
> Subject: Agenda: WS-A telcon 2005-12-05
> 
> 
> W3C Web Services Addressing Working Group - distributed meeting agenda
>    Monday, 05 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-21: <http://www.w3.org/2002/ws/addr/5/11/21-ws-addr- 
> minutes.html>
>    - 2005-11-28: <http://www.w3.org/2002/ws/addr/5/11/28-ws-addr- 
> minutes.html>
> 
> 4. Review action items <http://www.w3.org/2002/ws/addr/ 
> admin#actionitems>
>      2005-11-28: i059 - Ümit Yalçınalp to rework option 1, removing  
> defaulting attribute.  PENDING
>      2005-11-28: i059 - Jonathan Marsh to maintain option 3 as a  
> separate proposal.  PENDING
> 
> 5. Co-ordination
> 
> * TAG request for help
>     <http://www.w3.org/mid/OFC99039BA.A290C545- 
> ON852570C8.005A851F-852570C8.006A6181@lotus.com>
> 
> 5. Proposed and New Issues
> 
> * Proposed: wsaw:UsingAddressing as a policy assertion
>    <http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E8E3D115@RED- 
> MSG-10.redmond.corp.microsoft.com>
> 
> 6. 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: Ümit Yalçınalp to rework option 1, removing  
> defaulting attribute.  PENDING
>    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>
> 
> 7. 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.
> 
> 
> 8. 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
> Sun
> Novell
> SAP
> TIBCO
> webMethods
> Microsoft
> Fujitsu
> BEA
> BT
> Sonoa
> Sonic
> W3C
> Nokia
> Hitachi
> CA
> HP
> IBM
> Oracle
> Arjuna
> ERICSSON
> IONA
> Nortel
> 
> 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 Monday, 5 December 2005 18:16:48 UTC