See also: IRC log
<RebeccaB> Scribe this morning is Rebecca Bergersen; Jonathan Marsh this afternoon
Hugo: docs for WSDL - making progress, talking with Description WG in couple of days
Mark: approval of minutes - no objections
minutes - April 11th
Mark: scheduled end last call May
11
... May 11 also last day to register for Berlin F2F
... presentation on leaving Last Call
... number of requirements from process POV
... after last call comes candidate recommendation
... Process document outlines 10 steps
... 1 documentg all changes to document, both editorial and
substantive
... editors keeping change log
Hugo - when docs generated, diff is also generated
Mark: 2 indicate if "substantive" change in doc has occured
"substantive": change that invalidates an individual's review or implementation experience
Mark: substantive change means doc
needs to go back to Last Call
... we'll determine when we go to CR
... when we close an issue with a change we'll mark whether
"substantive"
<hugo> Meeting: WS Addressing F2F
<hugo> Chair: Mark
<hugo> Chair: MarkN
Mark: 3 - formally addressing an
issue is sending a substantive response to reviewer who opened
issue
... response delegated by AI with cc to comments list
... ask for ack, further comment within 2 weeks
... record of issues and responses must be kept - Last Call Issues
List
... issues considered before LC can't be reraised without new
info
... reviewer doesn't have to accept. If firm objection may be
reviewed by director when final review happens
... 4 - report formal objections
... objection to decision of WG, reported to director during
transition
Hugo: only W3C member can make objection
Marsh: diff btwn formal objection and onjection to comment?
c/onjection/objection
Mark: formal objection sent as formal objection via email, tracked, collected on web page
Hugo: go to director with issues list. He may ask if anyone unsatisfied with our resolution and we discuss our process and consideration
Mark: want to keep formal objection
and objection to our resolution separate
... will track on response whether acknowledgement, no
ackknowledgement or dissatisfaction
Hugo: will do more research on who may make objection
Mark: 5 - tell whether requirements
have changed
... 6 - review evidence - need to show wide review has taken place
(emailfrom outside WG, external orgs, etc.
... 7 - identify features at risk
... allows hedge against features we might remove; removal of such
doesn't constitute substantial change
... MUST be precisely identified; reviewers can formall object to
proposed removal of features
... 8: PR Entrance requirements
... 4 implementations, not 2
... (on #7) if feature appears to put interop at risk, may go on
list of risky features
... Lock period, Implementation period - how long think to
implement
<hugo> re formal objections, anybody can make a formal objection: http://www.w3.org/2004/02/Process-20040205/process.html#WGArchiveMinorityViews
Mark: we can allow external
implementations, by default, but we can constrain further if we
want
... process requires we test every feature - empty test suite
won
't do
Anish: need to make results public immediately? Mark: we'll get there
Mark: most immediately important
thing will be how we address issues and how we dance the dance on
responding to reviewers
... Now move into LC issues list
Last call issues list: http://www.w3.org/2002/ws/lc-issues/
Last call issues list: http://www.w3.org/2002/ws/addr/lc-issues/
Prasad: describing issue 1
Prasad: how can faults be received by sender if message id and fault endpoint reply properties not provided?
Anish - if reply-to required, how would work in one-way MEP
Glenn - do right thing if want right thing to happen
Prasad - add text to specs that props are needed if desire to handle faults
prasad: make SHOULD in text - if want
to receive faults, SHOULD define properties
... In SOAP binding spec, add sentence "in order to receive these
faults, message ID and fault endpoint or reply endpoint SHOULD be
supplied."
Marsh - put in first couple of para section 5
Marsh - first sentence 2nd paragraph section 5
Prfasad: no objection to adding to core if desired
Mark: "in order to receive..." is conditional phrase, so this might trip up some people
<scribe> ACTION: prasad write up text handling concern with conditional properly, send to self and mail comments list [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action01]
Hugo: relation to issue 50
Mark: Use lower case should, not
rfc
... lower case makes it English issue, not conformance issue
Marsh: Message ID and fault endpoint and reply endpoint properties facilitate delivery of fault back to originating party.
Mark: Message ID and fault endpoint and reply endpoint properties facilitate the delivery of faults.
Prasad: okay with text
Glenn - adds flexibility
Anish: Message ID doesn't help DELIVERY of fault, but correlates ]
Mark: Message ID and fault endpoint
and reply endpoint properties facilitate the delivery and
correlation of faults.
... resolution to issue 1, to be added to section 5, is "Message ID
and fault endpoint and reply endpoint properties facilitate the
delivery and correlation of faults."
<Marsh> ACTION: Marsh to respond to LC issue 1 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action02]
Mark: LC 2
... 20 minute break; restart ~10:50
Mark: section 2.2 example 2.1
... editorial - spelling, etc.
http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
WG walks through each of the editorial problems; short discussion of changes necessary
Mark: accept all suggestions, give
editorial discretion where no fix supplied
... no objections to resolution
Prasad: Many extension points described but not shown in pseudo-schema
Marsh: strike excess any in example 2-1
lc3 closed with acceptance of Marsh's recommendation
Prasad: confusing editorial note at end of status section "Note that this restricts use of Web Service Addressing to XML 1.0" but later state "...this is not requirement."
Marsh: note is incorrect
... remove editorial note or fix by removing sentence at end ort
clarifying to restriction of :some XML features..."
resolution - no objections to removing the note.
<anish> Prasad: why do we need [source endpoint]
<anish> jonathan: [source endpoint] is kinda strange since it is not referenced anywhere else, we could change the rules or drop [source endpoint]
<anish> marc: dropping is a better solution
<anish> greg: MAPs are extensible, so one can add itin
<anish> hugo: we define MAPs, we define rules for replying, someone may come up with an interaction pattern that uses [source endpoint]. I see this as a harmless and potentiall useful
<anish> mark: it is relevant that in CR we have to test interop for features, this is a feature.
<anish> marc: this comes back to davidh's issue around MAP extensibility
<anish> greg: one adv. is that -- we can prevent DoS attack
Anish - how does it prevent DOS attacks?
Hugo: where use from in email is in rules to reply to mshg
Glenn - expand rules to cover
Umit - source enspoint can be anon EPR
Mark: substantial change if we pull source
Greg: if no implementation actiually uses it ...
Glenn: some test case may use it
Anish: what rationale for not defaulting replyto?
MarcH - substantive change
Paul: fine the way it is at moment
Mark: Prasad, acceptable if mark as
feature at risk?
... no change at this point
Anish: I do see a use for the feature
Anish if use src EPR and reply EPR, you may have common proxy for whole bunch of things
Greg: if we start suggesting use, we
might want to make 1st class citizen by including in rules
... is change to rules substantive?
Umit - no - just plugging hole
Anish -aligns with email pattern
Hugo - wonders if forces to return to last call
Anish: Who decides if something substantial?
Mark: ultimately hope consensus of room; if push comes to shove, we'll see.
dhull: possible no from header but src abstract property defined?
Mark: decided at earlier issue not to
go there
... identify src endpoint property and places it exists and mark as
feature at risk
Anish object
c/object/objects/
Mark: needs test case
Marsh: test case: malformed header and see if response comes back
Glenn: real world - auditing / logging
Mark: two proposals - identify feature at risk or modify rules
MarcH: sounds significant change - worthwhile?
Hugo: significant change is to remove source endpoint
Mark: only identify as at risk, not remove it
hugo: use case contemplated by someone may be prevented by changing semantics
Paul: leave it in as informative text
paul do as response or add something in text as "it is here'
Paul: just document it
Anish: Marking feature as something at risk tgakes away some of the functionality in use cases we had in mind
Mark: indicates WG needs more
Anish: we've heard use cases
here
... so why mark as "at risk"?
... not mark as as risk - incorporate in rules
Mark: make the comment if that's what you feel
Umit: two probs Prasad wants to achieve - functionality and representation
Anish: message may be part of more complicated interaction - receiver may in future contact reply addr
Prasad: spec doesn't say anything about that
Anish: it identifies source of the message and use cases exist where that knowledge is impportant
Paul: agrees
Marsh: can set CR criteria to see some other spec out in wild that uses it.
Umit: what if my product is using it but no spec for it?
Marsh - spec or product, sure.
TRutt: poor man's multiple reply use case? Why not just a URI with some metadata?
Pauld: more info may be conveyed beyong just URI
Anish: supply proxy can use src EPR; message ID useful to receiver
Mark: is usefule to have this bucket
or indulging in differing semanticvs
... 1 option - identify as feature at risk, PR to make sure
external use cases, if decide later we can yank it
... 2: change defaulting rules so falls back to src EPR if reply
not there; concern if substantive change
... 32: status quo - our charter to provide feature for situations;
we don't need to provide rationale
c/32/3/
<abbie> can i vote
Mark: straw poll: feature at risk: 15 ; rules change 13 ; status quo 15
<pauld> chad, feeling ignored?
Mark: vote for one of three. Who has
preference for feature at risk? answer: 10
... prefer chanfging rule: 9
Mark keep status quo: 6
Mark: changing defaulting rules to justify existance of source endpoint is funny
Glen: no - dependency issue
Swinkler: majority seems to agree not to put at risk
Marsh: putting at risk only holds
feet to fire in terms of supplying use cases
... if not four implementations, we can remove it without
problems
Anish: Do you prefer defaulting to src endpoint when reply and fault endpoints not supplied as separate issue?
Glenn: use pattern must be specified or else that way lies madness. We should specifiy what pattern does.
Marsh: can always stick in reply endpoint, so why specify default action?
dhull: can we define a use case?
discussion of optimization....
Pauld: like status quo - should just leave and move on, but marking at risk gives us process advantages, so let's mark at risk and move on.
Anish: can always specify all properties, but if not all specified and fault occurs, what do you do about it?
Glenn: when go thru LC, it's expected
that comments make changes.
... minimum at end of LC, new LC can be requested
... unlikely we can get thru all issues without making "substantive
changes"
trutt: have tgo put in replyto if
expect reply. that goes away if we accept suggested change to this
issue
... that's substantive
Mark: defer resolving issue,, let discussion occur .. look for owner of LC5 - glenn volunteers to make proposal and drive discussion
Marsh: much like issue 35
... proposes text for his proposal for statements about SOAP 1.1
and 1.2 in issue 35 be added to conformance section
... addresseth LC6 and LC35
Anish: Is there better way of saying
it?
... when looking at conformance look as target - look at message,
look at rules and make determination - nitpicking over the
phrase
... say if follows rules then it's conformant
... if I get message without WSA header, I want to flag it as
non-conformant
text being debated is: "An endpoint which conforms to this specification understands and accepts
SOAP messages containing headers in the wsa namespace targeted to it,
and generates reply or fault messages it may send in response according
to the rules outlined in this specification."
Mark: that paragraph add something new that is a change from Prasad's LC6 concern
discussion in sweveral directions simultaneously
Mark: can we choose between Marsh's
and Prasad's wording?
... of first two paragraphs under conformance in LC35
... take wording to mail list and make last para topic of LC35?
<scribe> ACTION: jonatahn to start discussion of endpoint conformance on mail list [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action03]
c/jonatahn/Jonathan/
Anish: if include WSDL binding in mix, can we conclude conformance discussion?
Anish if say conform we require endpoint to emit something that can be examined WRT rules. If add WSDl binding to mix, would it make it easier to nail things down?
Anish: E.g. following rules for reply - behavior in addition to message
Mark: tracking all comments, all changes
Marsh: extremely minor
Mark: missing prefix, wrong prefix, use of pseudo schema consistently, comment
daveO: yea verily
(no objections to accetance)
lc8 Rationalize URI vs. IRI
Marsh: did global search and replace
of URI with IRI, but there are places where URI is
appropriate
... when talk about type of field, use IRI, but when talking about
string (i.e. specific instance), use URI
Hugo: may be confusing - can use IRI
everywhere, since URI isa IRI
... maybe at beginning of spec, say all URIs are IRIs
Hugo - All the IRIs used in the examples are URIs
Jonathan: wants to look thru spec to see if any exceptions to Hugo's proposal
c/Jonathan/Marsh/
Mark: W3C to never use "URI"
anymore?
... preference for Marsh proposal: 5
... preference for Hugo's proposal: 1
... everyone else abstaining
Hugo: web arch direction - uses IRI
everywhere
... may be confusing to sometimes see IRI, sometimes URI
Mark: resolition LC8 - go with Jonathan's proposal
c/resolition/resolution/
Luch break until 1330 (now 1236)
<Marsh> Scribe: Marsh
Mark: We have a FTF in June in
Berlin
... Next region in the rotation is East Coast in mid-late
July.
... Then there's the question of whether to take a holiday in
August.
... Who will not be available for a substantial portion of
August?
(7-8)
scribe: My expectation would be that
we'd have a FTF in early Sept. to get us back on track.
... That meeting will be here in the Bay Area.
... Theoretically the meeting after that would be overseas. (Late
Oct?)
... Looking for volunteers to host these meetings.
... Decide on August holiday at Berlin meeting.
... Only reason we wouldn't take a holiday is if we're at a
critical time in our schedule.
Bob: Informal poll on willingness of WG to meet in Japan?
Mark: Location is chair's decision,
Japan is something we'd like to do, I'll be looking at Japan late
this year or early next year.
... Have some other offers to host in London and Sri Lanka.
http://www.w3.org/2002/ws/addr/lc-issues/#lc9
Marsh: (introduces the issue)
TonyR: messageID absolute?
DaveH: Discussed this already.
RESOLUTION: Accepted Jonathan's proposal.
<scribe> ACTION: Greg to respond to LC9 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action04]
http://www.w3.org/2002/ws/addr/lc-issues/#lc10
Marsh: (introduces issue)
Anish: Implication that ref params have to have a namespace?
Marsh: Think that's what this text is trying to do.
RESOLUTION: Accepted Jonathan's proposal.
<scribe> ACTION: Tony to respond to LC10 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action05]
http://www.w3.org/2002/ws/addr/lc-issues/#lc11
Mark: (introduces issue)
Anish: I have a related issue, haven't sent it.
Mark: Please send to the list.
RESOLUTION: Accepted Jonathan's proposal
<scribe> ACTION: Paul to respond to LC11 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action06]
Topic LC12
http://www.w3.org/2002/ws/addr/lc-issues/#lc12
Mark: (introduces the issue)
... Does anyone know what was intended here>?
Glen: Seems to be about whether they appear as XML, HTTP headers, etc.
Marc: Not so much the "use of". More about serialization or encoding...
DaveH: Reification...
Marc: Amendment: Change "use" to
"serialization".
... SOAP would be the protocol here...
RESOLUTION: Accepted Jonathan's proposal as amended by changing "use" to "serialization."
<scribe> ACTION: Marc to respond to LC12 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action07]
http://www.w3.org/2002/ws/addr/lc-issues/#lc12
Marsh: word "each" no longer refers to something specific.
Hugo: EPR comparison was removed.
RESOLUTION: Accepted Jonathan's proposal.
<scribe> ACTION: DaveO to respond to LC13 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action08]
http://www.w3.org/2002/ws/addr/lc-issues/#lc14
RESOLUTION: Accepted Jonathan's proposal.
<scribe> ACTION: Vikes to respond to LC14 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action09]
http://www.w3.org/2002/ws/addr/lc-issues/#lc15
Glen: What if I send a message that is a combination of three. Can I resply to all of them?
DaveH: Don't want to preclude
something if we don't know it's harmful.
... There may be more than is dictated by the requirements of the
MEP.
Glen: Not particularly about a
specific MEP.
... Possible to indicate a set of messages.
DaveH: Underlying semantics are hazy.
Maybe a bug, maybe a feature.
... In request-reply there is a single reply message.
... In a different MEP there might be a different relation.
... Not so harmful to exclude for request-reply.
Glen: We could say the same thing
about ReplyTo.
... You're defining the MEP in a subtle way.
Anish: You're thinking app-level response to multiple messages? ('ack')
Glen: You're going to have to understand these messages in the context...
Anish: We already limit [reply endpoint] to maxOccurs 1.
Glen: Two ways to go: 1) crisp things up, but doesn't go far enough. 2) loosen it up, say "must contain appropriate relationship properties."
DaveH: This proposal moves further towards crisp.
Glen: I'd like to see ReplyTo defined in terms of request response, not reused elsewhere.
Nilo: Use case is bulk
acknowledgement.
... We call it acknowledgement at a high-level, at the WSA level
it's reply.
Glen: What's being teased out is that
there is some delicate semantics implied by "reply message".
... Either we should be clearer about what those mean or we should
remain abstract.
... reformulate as: "A message must contain zero or one
relationship properties with the URI ...reply."
Mark: 'A message MUST NOT contatin more than one "reply" [relationship]'
Nilo: What if I formatted some data
as several messages. How do I indicate a bulk ack?
... best to invent a new URI for that purpose.
DaveH: Now we've taken a little bit more of the WSDL req-resp MEP into the Core.
Marsh: We've changed the text but lost the requirement to have one.
Hugo: What is broken if we leave it
as is?
... The reply rules say you put in one.
Glen: When parties are communicating,
they have in mind the pattern that's engaged. If I send you a
message, and you respond with a relationship on it, we agree what
that means.
... I'd like things to be crisp, we need to have a way to describe
the contract implied by the relationships. You can introduce new
headers for slightly different semantics.
... Not hard to introduce new headers.
Hugo: We should then clarify that this is a reply with in a request-response pattern.
Anish: The idea of reply is in the description of the URI itself, yet we're not defining "reply". Seems like we should move this to the WSDL binding.
Umit: There is an agreement, but not
all exchanges need to be in WSDL. Two one-ways might constitute a
request reply.
... Doesn't have anything to do with WSDL binding.
Glen: One meaning is request-reply.
Another is a conversation, with request, reply, repliy, reply, ...
end.
... Any kind of lockstep conversation. Should we have a different
URI for that?
Anish: Up to you to define those URIs, why do we need that in the core?
Glen: We need some concept of a MEP somewhere (WSDL or elsewhere).
Umit: basic building block, don't
take it out of the core.
... I'm in line with crisply defining that reply can only occur
once.
Anish: If we try to define what reply means in absence of WSDL MEP it becomes hazy.
Glen: Use english.
Anish: Why would we constrain it as Jonathan proposes?
Umit: Describes when reply needs to occur.
Glen: When you do reply, it's only to one.
Nilo: Is the important thing the fact
that it relates to, or the semantics of how it relates?
... Leave the relationship type to some higher level.
Glen: What
... 's the utility of defining the relationship without the
patterns?
DaveH: Are these properties defined
in relationship to their WSDL MEP meanings or are we abstracting
out a notion of reply? We don't say which we're trying to do.
... If I see "Core" I'm expecting seeing addressing in general.
We've been bringing in more and more of the WSDL MEPs.
... If we do say it's bringing in the WSDL MEPs, we should
quarantine it to the WSDL Binding.
Glen: There is a more general
concept, in WSDL and in SOAP, of a message exchange pattern.
... If we were able to pull that into a realm where we could talk
about it.
DaveH: We can talk about MEPs that
don't have concepts of reply or fault.
... Let's say what we're doing.
Mark: Should we accept this proposal while we're investigating these larger issues?
Nilo: A message sent as a reply to
another must contain exactly one [relationship] property consisting
of the predefined reply URI and the message ID of the original
message.
... A message sent as a reply to another must contain exactly one
[relationship] property consisting of the predefined reply URI and
the message ID of the original message.
Anish: Same ambiguity as the first; constraint apply to the pair or to the relationship?
<scribe> New proposal: Keep the original text ('a relationship property'). Add "A message MUST NOT contain more than one 'reply' [relationship].
A reply message MUST contain a [relationship] property containing the predefined reply URI and the [message ID] property of the request message. A message MUST NOT contain more than one [relationship] containing the predefined reply URI.
RESOLUTION: LC15 closed: "A reply message MUST contain a [relationship] property containing the predefined reply URI and the [message ID] property of the request message. A message MUST NOT contain more than one [relationship] containing the predefined reply URI."
<scribe> ACTION: Hugo to respond to LC15. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action10]
http://www.w3.org/2002/ws/addr/lc-issues/#lc16
Marc: Alternate proposal: delete the paragraph.
Also see LC54.
Mark: Any objections to dropping it?
Umit: Like keeping this, as rationale for the design.
Marc: We can drop because we already say what these properties are for, dispatching is none of our business.
Umit: We've had a lot of discussion in WSDL about dispatch, like to see some rationale here.
Mark: What if we change "facilitate" to "may facilitate"?
Glen: Why do we need to say
"dispatch"?
... The important part is what you send, not how you process what
you recieve.
Marc: Kinda lame.
RESOLUTION: LC16 closed
with Jonathan's proposal, amended by "may
facilitate".
... LC54 also closed with LC16 resolution.
<scribe> ACTION: Nilo to respond to LC16, LC54. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action11]
20 min break
--resuming--
http://www.w3.org/2002/ws/addr/lc-issues/#lc17
Marc: The previous section talks about NAT and stuff, it seems like this is still talking about replies of some description. Are we prohibiting the use of anonymous in the To?
Tom: anonymous is the default for wsa:To, implies it's allowed.
Marc: Might need to do some work on the preceding sentence as well.
Vikas: The word anonymous means what in relation to NAT and DHCP, which are not anonymous.
Greg: The true address is not visible. It's unknown outside the NAT.
DaveH: Two things going on: it is the backchannel, and it's also anything you can't name. We need to nail down the intent.
Marc: Does it mean backchannel?
... or use some underlying protocol.
Marsh: Specific to the underlying protocol.
DaveH: Means "you know what to do with it" Seems like some interop issues there.
Glen: Because I'm using request reply, I'm saying get it back to me.
DaveH: Think the semantics aren't
very well defined.
... Perhaps define a backchannel URI to mean backchannel.
Mark: Seems like an issue on the
preceding text. Please raise an issue if you want.
... Ok with the resolution to this issue?
Marc: change to say "To allow these anonymous endpoints to send and receive messages..."
Marsh: OK by me.
RESOLUTION: Accept Jonathan's proposal for LC17.
<scribe> ACTION: Anders to respond to LC17. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action12]
http://www.w3.org/2002/ws/addr/lc-issues/#lc18
RESOLUTION: Accept Jonathan's proposal for LC18
<scribe> ACTION: Rebecca to respond to LC18 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action13]
http://www.w3.org/2002/ws/addr/lc-issues/#lc19
Anish: WebArch problems with simple string compare?
Marsh: Probably not - XML namespaces work like this.
RESOLUTION: Accept Jonathan's proposal for LC19
<scribe> ACTION: Anish to respond to LC19 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action14]
http://www.w3.org/2002/ws/addr/lc20
http://www.w3.org/2002/ws/addr/lc-issues/#lc20
Glen: Likes the first part, not the second.
DaveH: Distinguish backchannel from
other semantics.
... Some transports have backchannels, others don't. There might be
more that needs to be captured from the protocol.
... If your transport defines this, it should define it as a
sensible place to put replyTo and faults.
... In the case of HTTP the backchannel is the sensible place for
replies.
Tom: What does is mean to put it in the destination?>
DaveH: Assume it means send the message up the backchannel.
Glen: Unless you aren't in a
situation with a reasonable binding, in which case you barf.
... We all know what we want to happen.
Marc: Seems like an echo on the logical vs. physical which we never really closed on satisfactorily.
Glen: Continue to dance around the MEP issues.
DaveH: Considerably more tangible than log/phys.
Marc: Only because you're tying to backchannel responses. anonymous is fine for one-way if we delegate to the binding.
Glen: In a particular case it means a
particular thing doesn't preclude other cases.
... You don't even need a To in some cases.
DaveH: There are some transports that define a backchannel, we want to say use the backchannel.
Glen: Can generalize more: some transports can do more. What if I have a binding that is a single "wire".
DaveH: Can we say "anonymous" with a replyto or faultto means the backchannel - an error if there isn't a backchannel.
<umit2> This reminds me of what was in Message Delivery. Here is what was the description:
<umit2> A special URI value " http://www.w3.org/2004/04/ws-messagedelivery/destination/transport-specified" MAY be used to indicate destinations that either do not have a WSDL service description (such as Web service clients) or destinations that do not have a dereferenceable endpoint. The underlying transport mechanisms, such as HTTP connections, may be used to distinguish such destinations.
Marc: For SOAP/HTTP for a request sent in an HTTP entity body, anonymous means the backchannle.
Glen: There is a call for a middle ground that isn't HTTP-specific so you don't have to rewrite this thing over and over again.
DaveH: Backchannels are an important
fact of life. (BEEP, JMS). We want to capture it and give it it's
own name.
... We shouldn't use the same name for non-backchannel use.
Tony: Should be "binding in use" instead of "transport in use"?
(yes)
Tom: Gudge said "you know what to do with it"
DaveH: dangerous
Glen: Is there a way to more crisply define what that means?
DaveH: I have app logic that I want
to get my reply directly back. I'd like to pass that to the
infrastructure and have it do the right thing.
... If the infrastructure doesn't know what that means, I get
breakage. Things can move under your feet.
Marc: I'm with you if "backchannel"
was "connection". You might want to use "connection" for subsequent
messages in a conversation.
... Destination would be anonymous, replies to that message would
be anonymous.
Umit: "transport-specified"
DaveH: In HTTP you know what it
means, in other bindings you might not.
... If I don't know the binding in advance I can't use the value
safely.
Glen: At the app level, yes. Which layer is sticking this message into the envelope? A lot of frameworks may do this work for you.
DaveH: There's a monster behind the door.
Hugo: The spec says the use of anonymous no claim was being made. Could we say it's the "no claim" URI?
<GlenD> http://smollin.com/book/mikes/tmonstr/mon001.html
Hugo: We talk about the behavior being unconstrained in this spec (in the rules). Can we reuse text like this for anonymous URI?
<umit2> Tobe clear, I was not suggesting changing the uri to transport-specified to anonymous. Suggestion is to use the last statement as I quoted from message delivery
<dhull> I don't think that changes much either way
Umit: Do we like the first part of the proposal?
DaveH: I don't
Tony: It's appropriate to say "go look in the binding'
DaveH: We don't define any semantics in the core.
Glen: We either say what it means at
a high abstract level, and allow it to be clarified at the binding
level.
... Or we don't define it at all.
(discussion leaks a bit...)
Mark: Take it to the list.
http://www.w3.org/2002/ws/addr/lc-issues/#lc21
Marc: +1
<RebeccaB> +1
Mark: Step forward on the discussion we just had.
RESOLUTION: Accept Jonathan's proposal for LC21.
<scribe> ACTION: Arun to respond on LC21 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action15]
http://www.w3.org/2002/ws/addr/lc-issues/#lc22
<RebeccaB> +1 on proposal for lc22
Glen: I could use another header with mU to override this if I needed to.
RESOLUTION: Accept Jonathan's proposal for LC22
<scribe> ACTION: Tom to respond on LC22 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action16]
http://www.w3.org/2002/ws/addr/lc-issues/#lc23
Mark: Continuation of URI/IRI for SOAP doc.
RESOLUTION: Accept Jonathan's proposal for LC23
<scribe> ACTION: Bob to respond on LC23 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action17]
http://www.w3.org/2002/ws/addr/lc-issues/#lc24
RESOLUTION: Accept Jonathan's proposal for LC24
<scribe> ACTION: DaveH to respond on LC24 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action18]
http://www.w3.org/2002/ws/addr/lc-issues/#lc25
Anish: Does it make sense to have
things in the same namespace for versioning purposes.
... Different namespaces and schemas would help versioning
(independent of how many specs)
DaveO: Leaning towards doing it.
Rebecca: Might open up new problems. E.g. Anish's versioning problem, making it more difficult to avoid the implication that this is SOAP-specific.
Marc: I wonder if we should improve the separation by putting the XML representation in the SOAP binding.
Paul: Abstracting from XML
even.
... How do you apply the XML infoset to MQSeries?
Rebecca: Positioning problem.
DaveO: Majority case is SOAP, let's make it simple.
Mark: In the extreme we'd separate
abstract, XML, and SOAP. But I'm reminded of RFC2045 which buried
in media types.
... In the end we had to pull that out so we could reference it in
other contexts.
Marc: We could separate the abstract from the SOAP infoset. That would make it clearer by moving some of the XML infoset stuff to the SOAP binding.
Anish: Isn't the XML representation useful to more than SOAP?
Marc: Knock yourself out.
Mark: Thinks it's OK to have a single doc per our charter.
Marc: Prefers two docs.
... Would like to move the XML representation to the SOAP spec.
Mark: Strawpoll:
Option 1: Maintain the current split: 11
Option 2: Zip together: 3
Abstain: 7
RESOLUTION: LC25 closed with no change
<scribe> ACTION: Prasad to respond on LC25 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action19]
http://www.w3.org/2002/ws/addr/lc-issues/#lc26
Hugo: Would this align with SOAP
1.1?
... Action is not aligned (SHOULD vs. MUST) so we need to do it
differently in SOAP 1.1.
<scribe> ACTION: Marsh to look into the impacts on SOAP 1.1. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action20]
http://www.w3.org/2002/ws/addr/lc-issues/#lc27
<hugo> Discussion about action alignment: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0210.html
Marsh: pendantic
Glen: Could say "Each property that
is of type IRI MUST be serialized as an absolute IRI in the SOAP
header for that Message Addressing Property."
... Could say "Each property that is of type IRI MUST be serialized
as an absolute IRI in the corresponding SOAP header representation
for that Message Addressing Property."
RESOLUTION: Accept Jonathan's proposal for LC27, as amended by Glen.
<scribe> ACTION: Glen to respond on LC27 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action21]
<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc29
RESOLUTION: Accept Jonathan's proposal for LC29
<Marsh> ACTION: Pete to respond on LC29 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action01]
<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc30
Marc: IsReferenceParameter is SOAP-specific. We should define it there.
Marsh: Putting the definition in the Core is not central to the proposal. We could put it somewhere in the SOAP spec instead.
RESOLUTION: Accept Jonathan's proposal for LC30, amended by putting the definition in the SOAP spec somewhere instead of in the Core.
<Marsh> ACTION: Umit to respond on LC30 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action02]
Glen: We could fix on the presence instead of the value.
<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc31
RESOLUTION: Accept Jonathan's proposal for LC31
<Marsh> ACTION: Steve to respond on LC31 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action03]
<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc32
Glen: Is there any other SOAP-specific markup that might be added?
Marc: Any other soap markup will already be there.
RESOLUTION: Accept Jonathan's proposal for LC32
<Marsh> ACTION: Jeff to respond on LC32 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action04]
<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc34
Marc: Is there a problem when a node plays multiple roles?
<Marsh> ... We're making something illegal but there's a way to get around it.
Marc: If you write the text from the POV of the reciever, if you get more than one header targetted to you you fault.
Glen: SOAP says you union the roles you play and then iterate over those.
DaveH: What does it mean for an intermediary to have a ReplyTo?
Marc: Amendment: change "ultimate reciever" to "recipient".
<Marsh> ... "targetted to the same role"
Greg: Do you have to distinguish "next" and "ultimate reciever"?
Glen: We do intinerary-based routing, and like to be able to target sets at different nodes along a path.
Marc: Each node gets one MAP.
Glen: Don't know beforehand what distinguishes A and B.
Marc: If we don't preclude it we have to specify what happens.
DaveH: Where do we talk about this?
Marsh: SOAP section 3.3 after the bullet list is where I propose this goes.
Mark: Choose between "node" and "role".
Greg: Why not change "ultimate reciever" to "node"?
Glen: Precludes smart processing of multiple roles by a node.
Marsh: Can an entity act as if it were two nodes?
Glen: Yes...
DaveH: Can we define a new fault for this?
Glen: Nice to have another fault for this case - an intermediary might add the duplicate header.
Marc: reword without MUST - it's not a testable assertion.
<Marsh> ACTION: Marsh to rework proposal, adding a DuplicateProperty fault. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action05]
Mark: Get your issues in.
<Marsh> ... We'll start again at 9AM.