Review of action
items

Hugo: docs for WSDL - making
progress, talking with Description WG in couple of days

Approval of minutes

Mark: approval of minutes - no
objections

minutes - April 11th

Getting out of LC

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

lc1

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

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."

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

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?

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

FTF meeting schedule

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.

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.

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."

LC20

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?

LC27

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."