W3C

Web Services Addressing F2F

2 Jun 2005

Attendees

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

Contents


<anish> Scribe: anish

Agenda review

Mark: will go through the LC issues and if we have time will go through the WSDL issues
... + async TF report and discussion

Anish: what about the issue of splitting the WSDL binding doc?

Mark: W3C said that the WG may request it, but it will go to AC.
... Philippe said that it was a result of a compromise

anish: request for an agenda item for discussion of splitting of wsdl binding doc

mark: ok, we can discuss that

umit: what about the next f2f?

mark: lets discuss that tomorrow

jonathan: it might be better to talk about it today, as people might leave early. WSD WG may have a long concall in lieu of the F2F
... Glen had offered Boston (maybe)

AI review

<JacekK> Mark, could the issues list also be put in ~mnot/wsa/ ? 8-)

Approval of may 23 2005 telcon minutes

no objections to approving the minutes

minutes approved

LC37

Jonathan: this is a general soap problem. In Indigo, we plan to allow configuring the max soap message size.
... we can drop the first part

<pauld> sounds like ping-o-death .. 'soap-o-death'

Jonathan: the 2nd part is opening up lots of sockets. It is a general problem but before ws-addr there wasn't a way to do this
... this is still worth adding. we can decide whether we want to add this or not

marc: the last point is not just about faults but also replies

davidh: there is a general pattern, when someone gives u an EPR they are asking to send messages to that endpoint. There is trust involved there.

jonathan: we have a general issue about trust from marc

tony: don't run with scissors

anish: it is not necessary to have 'malformed messages'

jonathan: i don't think this is that important

mark: suggestion is to accept the last two sentences and add replies + removed 'malformed'
... any objections?

no objections

RESOLUTION: LC37 closed with the above resolution

LC89

Mark: this was from Nilo, we have accepted all the comments except #7
... we had asked Nilo to provide an example

Nilo: i haven't been able to do it, and i doubt if I can do that. So we should move on

Mark: any one willing to write the text?
... Proposal to close this issue with no action on comment 7
... any objection?

no objection

RESOLUTION: LC89 comment 7 closed with no action

LC77

Mark: we discussed this a bit previously. We did not come to a specific conclusion about it
... we had an action on it for Glen
... he is proposing that a note after section 3.4 in SOAP binding

jonathan: this is different than the issue

davidh: the main reason of raising this issue was that this could be done and had no idea if this was desireable
... we should say should or must

jonathan: we could do a should or must

hugo: i have an example where u do want to use this
... we exchange quite a bit of msgs. I sent someone the relationship and I want the relationship to be echoed back

davidh: if u want to pass info around u can define you header for this

anish: this is a general echoing mechanism and saying a MUST NOT is overly restrictive
... i may want to send the ACTION value cause it is required and without WSDL it is hard to get to

Katy: what is the client supposed to do when there is a conflict?

anish: well, it is a general issue about refps, but there is a conformance issue if the values in the EPR and the WSDL are different

glen: when we talked about issue 8 we talked about the idea that u as the sender of the message may care that someone has told you to put in GiveMeAllURMoney header
... it is ok for you to look in there based on the contact.

Hugo: katy gave the example of action, but we may create the problem as in issue 8. It is proper to have other specs to say something about headers sent thru refps.
... or should we put in text that provides priority
... this is a case by case basis and i'm not sure what we can say

Mark: i don't see any push back to glen's text
... any objection to accepting the text?

<mnot> http://www.w3.org/mid/80A43FC052CE3949A327527DCD5D6B270110C6BA@MAIL01.bedford.progress.com

<mnot> The insertion of SOAP headers into a message implies particular

<mnot> semantics. Since the reference parameter mechanism does not restrict

<mnot> the content of the generated headers, EPR suppliers should exercise

<mnot> appropriate caution to ensure their reference parameters do not cause

<mnot> unintended or erroneous semantics in the resultant SOAP message. For

<mnot> example, using a reference parameter to send a WS-Security header would

<mnot> be ill-advised (since other parts of the SOAP infrastructure will often

no objections to the above para

RESOLUTION: LC77 resolved by accepting the para above

Conformance Discussion

Mark: we have 6 issues about conformance

LC6

Mark: from prasad, have a couple of proposal
... he is asking for more specific stmts
... LC35 is from Jonathan. There is a proposal for this
... LC84 is about conformance of messages
... this is from DavidHull

DavidH: my suggestion is to be clear. The semantics are built around the idea of conformance message, but we don't define it
... 2 issues: can we tell what it means and can we agree on what it means
... this may well have overtaken cause of subsequent discussion

Jonathan: r u talking about msg in the general case (abstract case)

DavidH: i had thought of this as a Core stmt
... these are issues about the Core doc regardless of what we say in SOAP binding

Mark: we also have LC 85
... this is also about msg conformance
... We have LC82, which talks about processor faulting
... and finally LC62, which is Tom's issue about migration contract. We decided not to talk about this till we figure out the bigger compliance issue

DavidH: there are three/four diff levels of compliance that make sense
... we want to deal with compliant request msg, msgs that do have wsa headers but not in the right combination, full-request-reply all headers are present, no wsa-headers are present

Mark: jonathan sent a proposal on may 18th, which clarified the original proposal that he made

Jonathan: i would b happy to accept this revised proposal. The first issue we should take is what is a conformant message. There is conformant msg and there is SOAP conformant msg

DavidH: the model in the core is too restrictive
... we provide msg id for correlation. In particular binding we make restrictions. My proposal was to drop the MUST in Core

Jonathan: what specific small steps are there for us to go where we want to go

DavidH: one option is not to define what a conformant msg is

Jonathan: besides looking at each MUST, if u go back to issue 6 that points to the warning flags for Prasad and me
... we could just remove the stmt about conformance for messages in Core
... i might talk about conformance to reliability protocol and talk about conformance to ws-a in there

davidh: the main value is that here are some std headers and correlation

Jonathan: i prefer my proposal, but can live with davidh's proposal
... we should link testability and conformance together

davidh: we should talk about endpoint conformance rather then msg conformance

tomr: u need both

paul: i have been thinking about testing. i have been thinking of testing messages

<GlenD> U NEED BOTH

<GlenD> (egads, people)

<TRutt> Sender of a message must send conformant messages. Receiver of a message must also exhibit behaviour conformant to what the message contents requires to receiver to do.

<pauld> anish: don't think we're too far off. you can tell if a message is correct or not. you don't look at the message independent of the context. wrt endpoint conformance, you have to know the contract, e.g. WSDL,

<pauld> ... you have to know a lot more about the endpoint than addressing

davidh: we have 5 diff headers and 32 combinations. we have to specify what must happen and be explicit what we don't care about
... u test by sending 32 msgs

paul: u are asking for reference endpoints rather than test cases for messages

Glen: we specify both: structural constraint on the messages, we are also defining behavioral constracts
... it is a set of stuff that we want to support
... we should be able to test that set
... in CR we'll be testing the test scenarios

Davidh: we need reference test suites and not endpoints
... some set of echo operation

<umit> +1 to Glen

jonathan: i'm confused cause i hear david say that u want to nail down the behavior specifically, but at the same time u don't want use to say anything about behavior in the Core

davidh: i cannot look at the spec as it stands and figure out the answers for the 32 cases
... i would like precise specification and not many faults
... there aren't very many rules, we don't need a lot of machinary to do this
... there are three co-occurance restrictions that we move these constaints
... i have sent a proposal on the async list
... if we want to define a more general concept of req-res we can do that
... i'm more indifferent about where stuff is

jonathan: i would like to see specific changes to the spec

davidh: we can talk about taking all the MUSTs out of section 3.1 (the old section 3)
... strike the 'REQUIRED' in the abstract prop definition of [reply endpoint]
... strike the 'MUST' in [message id] abstract prop defintion
... strike the 'REQUIRED' in the abstract prop definition of [fault endpoint]
... section 3.3, i don't know what the 1st sentence means

Jonathan: we had a proposal to change that

Marc: the whole changes are making message id optional

davidh: if u want to specify a behavior that requires faults, we don't have the text right.
... jonathan is talking about what that means

Jonathan: my proposal is about SOAP, but i had a proposal to change the text in Core too

davidh: one reading is -- lot of don't cares. From conversations, it seems that the intention is to not do that.

Marc: the endpoint can do whatever it wants

davidh: but we have to say what it has to do when there is no conformant

jonathan: if a msg has wsa headers in it, then u check things and fault if not right

davidh: the text is not clear

marc: if u get a message that does not have any wsa stuff then we don't specify what the endpoint should do

davidh: we should specify for the 32 cases
... we don't say anything about 4 headers
... there is only one case where we say something -- definite semantics

jeff: there are 3 interesting cases: no headers, all four are specified, in between
... seems like we are safe if all four are specified. if none are specified if none are specified
... in the partial case, we can pick subset of these and specify

jonathan: we may not want to specify certain subsets

paul: i'm thinking of test cases and we can come up with test cases which bring out the ambiguity
... when u write the table, there will be several cells that are greyed out

Mark: we can address 6 and 35 with the text that jonathan proposed
... we also have 84 and 85 which is related to message conformance
... then we can look at 82 and 62. That is how i would like to proceed.

[BREAK]

<TRutt> ping

[back from break]

discussion of proposal from jonathan (in the soap binding)

mark: does this address LC 6 and 35?

jonathan: in addition to the text, there was removing 2 sentences (proposed by prasad) and use consistent term regd conformance/compliant
... does not address the strange terminology in section 3.3 in the Core

<scribe> ACTION: mark to look up on the 1st sentence in section 3.3 in Core (and whether we did anything regd this)

anish: little uncomfortable with the wsdl part in conformance section for soap

jonathan: me too, but could live with it
... paco wanted this

umit: without wsdl conformance how do we talk about endpoint conformance

anish: we can talk about wsdl binding conformance and if the wsdl contains soap bindings then it pulls in the soap conformance to ws-a and Core is always in play
... wrt to whether we want endpoint conformance independent of wsdl conformance, that is something to talk about

nilo: the last phrase about wsdl description, we can say that -- if there is a wsdl description it may pull in more conformance things from wsdl

mark: proposal is to close LC6 and LC35 -- using jonathan's proposal and remove the last part about wsdl and include things about wsdl conformance (which is a may), settling on compliant or conformant and weakening of the sentences (as pointed out by prasad)

katy: i want to ensure that one isn't required to send a fault when a non-conformant msg is received

jonathan: we don't specify when u formulate a reply

mark: any objections?

no objection

RESOLUTION: LC6 and LC35 are closed with the above proposal

LC84 and LC85

DavidH: there is already text in the issues for changes (two options)
... my preference is option 1
... delete three 'REQUIRED' and move the remaining 'MUST/REQUIRED' to section 3.3

mark: proposal is to go thru all the abstract prop stmts and move things to section 3.3

katy: does this change the behavior

davidh: that depends on your interpretation of what it says now

jonathan: going back to conformance, it makes more sense to associate conformance stmt with the testable artifacts
... in soap binding we should say that when u conform to Core section 3.3 then u must do something specific
... i would like see a concrete proposal before i agree
... the second section in the 1st option does not define a compliant processor

<GlenD> +1 to Anish

anish: why don't we just move section 3.3 to wsdl binding

glen: what is a reply concept without an MEP concept
... agree with anish

mark: the proposal is to move all the imperative stmts and move to section 3.3 and then eventually move this to the WSDL binding

glen: there should be a single concept of meps across soap/wsdls and bindings and they should be able to layer things
... lets say the wsdl req-res is the req-res MEP, but this should be directly implementable with soap with and without ws-addr
... the general concept is that there a message that goes from node a to node b and node b needs a property to figure out where the following message is to be sent

jeff: what is the scope of abstract req-res? is this about architecture?

glen: yes, but don't want to use that term

anish: have an example in the core and point to wsdl but not define what a req-res is

<GlenD> ("that term" meaning "WS-* Architecture"... since that was a particular effort that has it's own implications)

katy: the only concern i have is (maybe not), if we leave the req-res out of the core does this cause a problem to folks like bpel?

glen: u need to define req-res somewhere, we could do it here, but what is in it right not is not clear

davidh: i'm in favor of moving this out to wsdl
... it makes quite a few issue that i have raised quite redundunt

marc: are we suggesting that we remove section 3.3?

mark: yes and move it to core. move stuff in section 3.1 to section 3.3 and then move section 3.3 to wsdl

marc: that is a bad idea

<umit> +1 to Marc

marc: we can remove the request-res from core, but we should not take this whole thing about formulating the reply and move it to wsdl
... then there is no point to core

umit: +1 to marc. In bpel, we need some guidance

jeff: if we remove some of the stuff what does the core mean?
... not testable
... my question is -- where is the concrete stuff that i can claim conform to

<pauld> it's a bag of properties

michael: can someone submit changes by email, can we then look at it tomorrow
... also these changes may affect going to LC again

davidh: +1 to anish, i am comfortable with defining abstract stuff only in core
... the wsdl doc defines how to define req-res
... why talk about just req-res, what about one-way and robust-in

vikas: the purpose of having conformance stmt in core is for new bindings that you create
... i don't look at core and say that an endpoint is compliant
... if i create a new binding then it should be compliant to the Core

paul: the purpose of core is that it is a bag of properties and how those properties interact
... conformance in the core is not useful
... we only have one binding, if we had another binding then it might help us understand

umit: it seems that everything has to be testable and since we cannot test the Core
... the core is somewhere in between and proposes guidance for request-resp which is different from wsdl req-res
... there is req-res that occurs as a composition

<bob> +1 to umit's point

mark: having the req-res in Core does not define the concept for everything

davidh: if we are trying to create a concept of req-res in general then it needs to be only as restrictive as necessary and no more
... we need to be careful about the rules that we have defined

jonathan: i think we should go for the minimal thing here. I don't think conformance stmt for endpoint makes sense. Conformance stmts about binding makes sense, but does not provide high value. The bidning specs will do what they do.

vikas: u have to say what minimal thing must be present to say that the message is using ws-addressing (and the specific binding)

jonathan: not much value

marc: +1 to jonathan

<umit> I actually did not want to say that everything has to be testable. I observed that the core can specify some general guidance/behaviour that you can expect.

marc: i still thing the core can specific some expected behavior, it is not expected that the binding should define this

davidh: we already talk about what to do with refps
... in section 2 we already say that echoing of refps is required

katy: i think the Core is a place to put reusable aspect of the spec. The notioin of req-res is reusable and should be in the Core.

jonathan: summary -- moving must stmts from 3.1 to 3.3, marc suggests that we reword section 3.3 and talks about reply messages, we haven't resolved anything about conformance

mark: we need to see a proposal

davidh: it needs to be clear when we are specifying behavior and when we are not
... we need to be clear what our scope
... is

anish: there is another issue of where section 3.3 should be, there isn't a consensus about whether it should be in Core or WSDL

mark: lets have folks work on a proposal during lunch and then we can discuss this during lunch
... two choices: do it after lunch or next week. Next week will mean we will lose context

marc: needs more time, hard to do during lunch

mark: lets try to do this over lunch and see if we can discuss this after lunch

[lunch break]

<bob> scribe: bob

<scribe> Scribe: bob

review of section 3.1

marc presented the re-drafts of section 3.1 and 3.3 of core that were accomplished over lunch

marc pointed out that there were major issues in this morning's discussion concerning conformance to core

<scribe> new language tightens up 3.1 and removes redundancy

this new text is intended to close lc84; David Hull indicates happiness with this conclusion

lc85

underlying issue remains concerning behavior concerning violation of cardinality as indicated in spec

pauld thinks one cannot be compliant to core, but must be compliant to a binding

core serves as guidance to binding writers

bob suggested that language be added that no binding may be constructed that violates the principles defined in core

Editors will augment text to enhance definition of cardinality notation as well as describing that derived bindings must not violate these constraints.

<pauld> how can you test my implementation represents action as 'string action' as opposed to 'string action[]'

<marc> i can test whether your implementation emits messages that contain multiple [action] MAPs

no,yes,no,yes,yes you can, no you cant;balderdash

The teacup was filled with a swirling mass of dense cloud; the strong arm of Zeus set forth lightning which struck throught the room

<pauld> chad, hi

question posed: conformance and cardinality

proposal is:that cardinality notation will contain a statement that statements will place constraints on bindings written to wsa core

formal vote: yes:10 no:6 abstain: 3 yes carries

Resolution: lc 84 closed without objection

<hugo> Yes: CA, Ericsson, Fujitsu, HP, IBM, IONA, Nortel, Oracle, SAP, Sonoa

<hugo> No: BEA, BT, Hitachi, Microsoft, Sonic, Sun

<hugo> Abst: Nokia, Tibco, W3C

concern expressed about behavior upon the receipt of a message that contains no addresing headers at all

<TIBCO-dmh> 0/x/x/x/x/fault

<TIBCO-dmh> x/0/x/x/x/fault

<TIBCO-dmh> x/x/0/x/x/fault

<TIBCO-dmh> 1/1/1/x/0/fault

<TIBCO-dmh> 1/1/1/x/1/OK

<TIBCO-dmh> and that covers everything

<TIBCO-dmh> however, we would like

<TIBCO-dmh> 0/0/0/0/0/OK

<TIBCO-dmh> and I would like to see a lot more "OK"

dmh has determined that the matrix is well formed

Resolution: lc85 closed with no action; dmh satisfied

lc82

Resolution: close lc82 without action

lc62

<Marsh> Append to the Conformance section: "Endpoints are allowed to continue to invoke operations outside the scope of WS-Addressing (i.e. omit WS-Addressing headers in response to messages that don't contain WS-Addressing headers.)"

<TIBCO-dmh> Endpoints MAY continue to accept and respond to messages which contain no WSA headers.

<TRutt> Conformant endporinta may omit WS-addressing headers in response tomessages that don't contain ws-addresssing headers.

<TIBCO-dmh> In the faults they MUST send back??

<TIBCO-dmh> Core should say "if no MAPs have values, no fault." SOAP should say "no headers means no values (i.e., no defaulting)"

<TRutt> Endpoints MAY accept and respond to messages which contain no WSA headers.

<TRutt> Endpoints MAY continue to accept and respond normally to messages which contain no WSA headers.

in new comformance section:

<mnot> Endpoints MAY accept and respond to messages which contain no WSA headers normally.

<TRutt> Endpoints MAY accept and respond to messages which contain no WSA headers.

formal vote on resolution to lc62

question is is mnot's text above acceptable to close lc62

<hugo> Yes: BEA, BT, Ericsson, Fujitsu, Hitachi, HP, IBM, IONA, Microsoft, SAP, Sonic, Sonoa, W3C

<hugo> No: Oracle, Sun

<hugo> Abstain: CA, Nokia, Nortel, Tibco

results yes: 13 no: 2 abstain:4

<marc> voted no because believe the problem should be solved in the broader sense rather than adding specific exception

break for 15 min; return at 3:45

resume at 3:52

lc20

<TIBCO-dmh> proposed request/reply rules from 7 April:

<TIBCO-dmh> All MAPs other than [destination] and [action] are OPTIONAL.

<TIBCO-dmh> If the request message defines a [message Id], the outbound message's [relationship] MUST contain the pair (in-reply IRI, ID), where ID is the [message Id] of the request.

<TIBCO-dmh> If the outbound message is a reply and [reply endpoint] is defined, the outbound message MUST be sent to the [reply endpoint].

<TIBCO-dmh> If the outbound message is a fault and [fault endpoint] is defined, the outbound message MUST be sent to the [fault endpoint]

<TIBCO-dmh> (optional rule) Otherwise, if a [source endpoint] is defined, the outbound message MUST be sent to the [source endpoint]

<TIBCO-dmh> (anonymous behavior)

<TIBCO-dmh> Otherwise, if the binding defines a default means of delivering outbound messages, the outbound message MUST be sent by that means.

<TIBCO-dmh> (and otherwise you're hosed) Otherwise, the message has been constructed inappropriately for the binding. It will not generally be possible to signal this at message delivery time, but there will have been enough information in the WSDL binding to detect the situation prior to message delivery time.

<TIBCO-dmh> EOM

mnot reads through a number of issues he thinks may be related

<umit> including the pergammon museum...

<TIBCO-dmh> (aka "the museum of mind-bogglingly large ancient things"

<TIBCO-dmh> )

discussion ensued concerning the replyto (1..1) requirement and the recommendation against that by the WSDL working group

<TRutt> Old suggestion "/wsa:ReplyTo

<TRutt> This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is "http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the [children] of this element convey the value of this property."

straw poll supported reopening i50; some concern about potential for delay; chair reopens issue with plea to limit debate

i50 reopening

<Marsh> This element MUST be present if wsa:ReplyTo or wsa:FaultTo is present.

<JacekK> the value of replyto is epr, not uri

<Marsh> Change to "This element MUST be present if wsa:ReplyTo or wsa:FaultTo is present, or if a reply is expected."

proposal: This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is "http://www.w3.org/@@@@/@@/addressing/role/anonymous".

mnot: as part of the resolution of lc84, there was an intention to remove five instances of MUST in the description of elements

<pauld> chad, glen thinks you pong :-(

<GlenD> This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is an EPR which contains only an <address> property, whose value is "http://www.w3.org/@@@@/@@/addressing/role/anonymous".

note that the presence of wsa:replyto does not necessarily indicate that a reply will occur

<pauld> s/^chad, .*$//

<jeffm> definition of new information from the process document:

<jeffm> The Chair MAY reopen a decision when presented with new information, including:

<jeffm> * additional technical information,

<jeffm> * comments by email from participants who were unable to attend a scheduled meeting,

<jeffm> * comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).

<jeffm> The Chair SHOULD record that a decision has been reopened, and MUST do so upon request from a group participant.

paco objects that anonymous is not the same as no value and makes no sense if there is no way back

<jeffm> and from the charter -- The Chair will: .. 3. Reconsider a decision only when presented with new information. (W3C Process Document, section 3.3.4).

lc83

Resolution: close without action lc83, dhull present

lc103, lc107

<scribe> ACTION: Marc Hadley to make a proposal on resolution to lc103

lc78

resolution to make editorial changes to section 3.3 wording concerning population of a reply message's message addressing properties to make sure it is clear that it is a new set of properties

Resolution: lc78 closed with editorial changes

adjourned 17:05

Summary of Action Items

[NEW] ACTION: Marc Hadley to make a proposal on resolution to lc103
[NEW] ACTION: mark to look up on the 1st sentence in section 3.3 in Core (and whether we did anything regd this)
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/09 13:32:51 $
--------------------------------------------------------------------------------

Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique online 
event, giving you the first look at a new category of enterprise software 
built specifically for Service-Oriented Architecture (SOA).

Register Now.  It's Free!

http://www.bea.com/events/june15