W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

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

From: David Orchard <dorchard@bea.com>
Date: Sun, 4 Dec 2005 21:58:44 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF14C024DD@ussjex01.amer.bea.com>
To: "Mark Nottingham" <markn@bea.com>, "WS-Addressing" <public-ws-addressing@w3.org>

Partial regrets, I will be virtually attending the TAG f2f @ much the time.

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Mark Nottingham
> Sent: Sunday, December 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 05:58:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT