W3C

Web Services Addressing Teleconference

13 Jun 2005

Agenda

See also: IRC log

Attendees

Present
Rebecca Bergersen (IONA Technologies, Inc.)
Andreas Bjärlestam (ERICSSON)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Martin Gudgin (Microsoft Corporation)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Philippe Le Hégaret (W3C)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Steve Vinoski (IONA Technologies, Inc.)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Absent
Abbie Barbir (Nortel Networks)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
Amelia Lewis (TIBCO Software, Inc.)
Jeff Mischkinsky (Oracle Corporation)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Rich Salz (DataPower Technology, Inc.)
Davanum Srinivas (Computer Associates)
Jiri Tejkl (Systinet Inc.)
Regrets
Prasad Yendluri (webMethods, Inc.)
Katy Warr (IBM Corporation)
Chair
Mark Nottingham
Scribe
Marc Hadley

Contents


<scribe> scribe: marc

Approval of minutes postponed until next week

lc72

proposal: <http://www.w3.org/mid/429F9454.2040202@oracle.com>

Two options: deal with SOAP 1.1 and 1.2 the same or differently

related to lc56

Anish: seems simpler to define header element for fault detail for both SOAP 1.1 and 1.2

Marc: Think we should use SOAP 1.2 as described

Dhull: define information and then describe where to put it for 1.1 and 1.2

Glen: points out misunderstood header in SOAP 1.2, prefers putting in detail for SOAP 1.2

<anish> to be clear, i prefer treating soap 1.1/1.2 in the same way, but can live with either

dhull: make it as easy as possible to dig out the required information

tom: live with doin things differently in 1.1 and 1.2

<RebeccaB> we can live with it either way

<bob> I am in favor of leaving each flavor of soap to its own way

<uyalcina> I agree with Bob

<PaulKnight> +1 with Bob

<uyalcina> wrap it baby!

Marc: thinks lc72 is independent of SOAP 1.1/1.2 differences, still need wrapper for both

Mark: any object to closing lc72 as proposed ?

No objection

lc56

Anish: should we have a common header element for all or do we use detail contents directly

mark: i.e. do we need to wrap the wrappers

marc: mild preference for a wrapper wrapper

<bob> +1

<scribe> closed, will create a SOAP 1.1 wrapper header block and let this contain the detail elements

lc76

http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0002

<anish> ?

tom: is proposal to add text that says whats wrong and include the faulty stuff ?

dhull: in general yes, duplicate ids - not sure how to report it

jonathan: where do you stop, send the whole message ?

dhull: true but need some structure to report the actual problem

tom: would like some data but not entire message
... would like to see a proposal for the detail contents

<bob> no now

jonathan: where do we draw the line ?

dhull: don't like the generic invalid header fault, wants more detail so one can identify the problem

tom: likes the idea but doesn;t see value in echoing all the information

define syntax and make inclusion optional, define a verbose errors flag to control how much detail included in fault

jonathan: not sure how much use extra info is without having the offending message in its entirity

paul: can do all this as the spec stands, just not standard

dhull: standardization will help with writing tools to process faults automatically

philippe: no point standardizing if only for debugging

mark: if we decide on this path, next step is to develop proposal and keep issue open

<dhull> +1

<dorchard> I'm interested

<anish> +1

<bob> +1

<TomRutt> interested in more fault codes, perhaps not detail info

<anish> as long as it is optional

<steve_winkler> I would be interested in hearing more details...

<PaulKnight> +!

<vikas> more faults but less detail

<MSEder> OK

<dorchard> any -1s?

<pauld> -1

<Nilo> Nilo is interested

<Marsh> -1

<RebeccaB> more fault types

<uyalcina> i am not sure what is the bar

Tom, Marc: would like to see next level of detail, fault detail schema etc

<uyalcina> no

<mnot> ACTION: David Hull to refine lc76 proposal to include fault structure [recorded in http://www.w3.org/2005/06/13-ws-addr-minutes.html#action01]

F2F planning

Week of 18th

July

<dorchard> I can't make July 18th for any meetings.

Mark: Meet on 18th, 19th, may meet on 20th AM

<uyalcina> +1 to anish

lc68

http://www.w3.org/2002/ws/addr/lc-issues/#lc68

Mark: doesn't think we had a previous issue about this specifically

glen, jonathan: think we did - issue 42

mark: anyone opposed to considering this now

jonathan: at the moment, yes. still discussing inside MS

mark: since this has been discussed previously then we shouldn't discuss it again

glen: would like it to be reconsidered, have come across some use cases we think are important

<RebeccaB> we think this is something that should be done.

paco: ok with current text, glen use case (policy) is compelling, would support re-opening

lc 75, 88

<dhull> The value of [message id] uniquely identifies the message.

http://www.w3.org/mid/E1Df7pM-0002Yb-Ou@lisa.w3.org

<dhull> When present, it is the responsibility of the sender to insure that each message is uniquely identified.

<dhull> A receiver MUST treat all messages that contain the same [message id] as the same message.

<dhull> If a reply is expected and a back-channel may not be available, [message id] MUST be present.

<dhull> No specific algorithm for the generation of unique values of [message id] is given, however methods such as the use of an IRI that exists within a domain

<dhull> owned by the sender combined with a sequence satisfies the uniqueness criteria but may not be the best practice from a security perspective.

bob: message id mandatory if there's a possibility that back channel may not available

dhull: given that we've broadened use of message id beyond correlation, would like to see that addressed

bob: proposal is restricted to use with correlation

dhull: for correlation all that's really needed is echoing of message id

paco: dhull should bring up specific issues if thinks that message-id is not suitable for other uses

<TomRutt> there is a queue

<uyalcina> Paco, can you clarify what the 4th sentence should be in your opinion in the proposal?

paco and dhull have fast wordy exchnage that the scribe has difficulty in capturing

tom: our message id is not useable for any reliability specs out there
... our semnatics are for correlation only, reliability should define their own id
... supports dhull viewpoint
... relates to mandatory for replies, would need to change that too

mark: thought we decided in berlin that message id optionality will stay as the status quo

dhull: closed message id optionality on grounds that it was useful outside of correlation, if thats not the case then we shoudl reconsider

paco: original message id was designed to support security and reliability

dhull: don't we say that message id should not be used for detection of replay

bob: our message id does support duplicate elimination aspect of reliability

tom: not enough for sequencing though
... only put the semantics we need on message id, if other specs want to re-use our id then they can further constrain it

<Marsh> +1 to paco

dhull: do we have a clear picture on what the requirements of other specs are

paco: can tell you that we support them

dhull: your use cases not just correlation but also security and reliability

paco: yes

<steve_winkler> reliable delivery of a message requires a unique id for dedup.

tom: relying on uniqueness

paco: s/global unique/unique within scope of interaciton/ ?

<anish> i'm not sure how message-id allows for reliability? It does provide for duplicate elimination, but only with a large(infinite) storage

gudge: people use message id as part of uniqueness, timestamp for other part

<steve_winkler> a unique id doesn't allow reliability, but it's a mandatory component of it.

<uyalcina> i am curious how can we clarify what the scope is since it is dependent on other specs that build on WS-Addressing...

<anish> but the unique id (for reliability) has two components (group id and seq number) and expiration time associated with it

<steve_winkler> that's true, but if I understood paco correctly, he was just arguing that uniqueness shouldn't go away...

scibe gets a little lost

bob: current proposal aspect related to back channel is problematic

<mnot> The value of [message id] uniquely identifies the message. When present, it is the responsibility of the sender to ensure that each message is uniquely identified. A receiver MAY treat all messages that contain the same [message id] as the same message. No specific algorithm for the generation of unique values of [message id] is given, however methods such as the use of an IRI that exists within a domain owned by the sender combined with a sequence satisfies the u

<bob> should be ensure

<TonyR> "insure" means it can be wrong, but we get financial compensation if it is. "ensure" means it can't be wrong :-)

<steve_winkler> I agree with tom here. We define it's the same message and let people do what they want with that information.

<uyalcina> i think the semantic is up to the usage scenerio provided by the receiver, Marc.

marc: not clear on meaning of "A receiver MAY treat all messages that contain the same [message id] as the same message."
... would it be clearer to say that WS-Addr doesn't constrain the bahaviour of a receiver when it gets two messages with the same id

<steve_winkler> marc, were you suggesting that MAY isn't strong enough because it's not testable? From that point of view, is MAY ever useful?

i'm asking what is the behaviour we are expecting of a receiver that complies with this requirement

drop the duplicate, fault, ...

<steve_winkler> Ah, I see.

<mnot> ACTION: Marc Hadley to respond to new lc75/lc88 proposal [recorded in http://www.w3.org/2005/06/13-ws-addr-minutes.html#action02]

<uyalcina> adios

meeting adjourned

Summary of Action Items

[NEW] ACTION: David Hull to refine lc76 proposal to include fault structure [recorded in http://www.w3.org/2005/06/13-ws-addr-minutes.html#action01]
[NEW] ACTION: Marc Hadley to respond to new lc75/lc88 proposal [recorded in http://www.w3.org/2005/06/13-ws-addr-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/15 13:05:06 $