RE: Agenda: WS-A telcon 2006-01-09

Please add an item about next weeks f2f logistics.  I'd like to discuss
eating arrangements including dinner plans.  It shouldn't take more than
5-10 minutes.

Cheers,
Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Mark Nottingham
> Sent: Wednesday, January 04, 2006 2:57 PM
> To: WS-Addressing
> Subject: Agenda: WS-A telcon 2006-01-09
> 
> 
> W3C Web Services Addressing Working Group - distributed meeting agenda
>    Monday, 9 Jan
>    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-12-19: <http://www.w3.org/2002/ws/addr/5/12/19-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
>      2005-12-12: i067 - David Orchard to rework proposal.  PENDING
> 
> 5. Testing Update
> 
> 6. Proposed and New Issues
> 
> * i067 - SOAP 1.2 support for Async
>    Owner: ???
>    Proposal 1: <http://www.w3.org/mid/438CA309.9070406@tibco.com>
> 
> * i068 - One-Way SOAP 1.1 Binding for HTTP
>    Owner: ???
>    Proposal 1: <http://lists.w3.org/Archives/Public/public-ws-
> addressing/2005Dec/att-0080/ws-addr-wsdlProposedRevision1.62.html>
> 
> 7. Working Draft Issues <http://www.w3.org/2002/ws/addr/wd-issues/>
> 
> * i066 - wsaw:UsingAddressing as a policy assertion
>    Owner: Jonathan Marsh
>    ACTION: 2005-12-05: Jonathan Marsh to make concrete, non-
> referencing proposal.  PENDING
> 
> 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
> SAP
> Fujitsu
> BEA
> BT
> Sonoa
> Sonic
> W3C
> Nokia
> Hitachi
> CA
> HP
> IBM
> Oracle
> Arjuna
> ERICSSON
> IONA
> Nortel
> Sun
> TIBCO
> Microsoft
> webMethods
> 
> 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, 9 January 2006 20:50:49 UTC