See also: IRC log
<scribe> scribe: marc
Approval of minutes postponed until next week
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
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
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]
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
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
<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