Everyone agreed to cancel next Monday's teleconference because the face-to-face starts on Tuesday. Chair to send out email confirming this.
Chair: expects the main aim of the f2f to be closing issues. Will send out agenda soon (Friday at latest). Asks everyone to send proposals for resolving issues or issues to be discussed to the mailing list.
Working draft of specification was published last week. Chair. asked about the status?
Hugo: has worked on publication. Almost finished final version. Ready to be send out to the publication team soon (by 8th of December). However, there was one issue that remained to be solved: the namespace URI has not been updated? Is that a mistake?
Chair asked if the working group has an objection to changing the namespace URI, but it was pointed out that it has been changed in line with previous agreements.
Hugo will check, but assumes he (or his tool) made a mistake.
Chair asked if this issue is actually necessary? Getting a media type published and registered has taken a lot of time and effort elsewhere. Mark was worried that this may take up too much time for this group, particularly if there is no real requirement.
However, it was mentioned that all we have to do is put a registration template into the document and notify IANA. So maybe there isn't much effort after all.
Hugo reiterated the original question: how much use is this? He doesn't understand whether we really need to have one defined.
There was no strong preference either way from the rest of the group, so Chair. asked if we should just close this issue with no action?
Greg suggested that there may be a use case, so was given ownership of issue 36.
Chair began by asking for an owner of this issue. Harris agrees to take it but because he is new to is asked for help. Hugo agreed to help out.
<scribe> ACTION: Gudge to own this and come up with a proposal for text by f2f.
Hugo believes this is mostly editorial.
<scribe> ACTION: Hugo will take ownership and resend his original proposal to the group.
Chair asked if this wasn't open ended and out of scope for this group?
General discussion that this wasn't intended to require the definition of a security framework. However, this is something that several people agree needs addressing because it is a real world problem. What kind of signature do you need to include to make sure people can trust the EPR?
Chair was still worried about whether or not this is in charter.
Gudge expressed concern that if we don't do anything then people will reject EPRs based on the specification. He sees this happening already. So, should they be able to?
There was a general discussion about the fact that this happens today anyway with URIs, so what is the difference? If there are mechanisms to secure URIs (or at least allow users to trust them in some way) then why can't they be applied to EPRs?
<scribe> ACTION: Chair and Gudge agreed to sit down next week at the f2f and see if this issue can be addressed in scope.
Gudge would like to see something in the specification.
Chair suggested that this is related to Issue 16. There has been a long discussion on the mailing list.
<scribe> ACTION: Dims to take action and bring proposal forward. With help from Glen. Available for the f2f.
Chair. then ran a straw poll to see who agreed that by inspecting the message it should be possible to see what parts of it were generated by reference parameters and reference properties:
Yes: Glen, Mark H, Hugo, Tom Rutt, Steve Winkler, Mark P, Bob Freund, Mark L, Arun, Dims, Anish
No: Gudge, Jonathan, ??
Unsure: Yin Len, Mike L, Jeff, Paul
Tom Rutt asked if there was ever a need for a reference property to be targetted to anything but the ultimate destination? He hadn't seen any use cases that indicated this was the case.
However, apparently Dave Orchard has a use case where the user is not the ultimate destination.
Anish asked if it is really necessary to discriminate between reference properties and reference parameters? Why are there two types?
Chair said that this issue is how can be differentiate them from other parts of SOAP headers. Then a subissue may be whether we need to differentiate them from each other?
<scribe> ACTION: Glen to take the action to give a formal proposal for the wrapper model.
Hugo said that a proposal for this had already been sent to the group. He walked the group through it.
Anish: asked to clarify properties. Is the idea to say what values properties would be in the WSDL?
Hugo: some may be set at runtime and some at design time in the WSDL. For example, wsa:Action would be in the WSDL. Not sure about Reference Properties. Reference Parameters are probably at runtime.
It was then asked whether we need to go through all properties and define whether they are for runtime or design time?
Hugo: yes, maybe the current proposal is lacking in that area.
Anish: maybe it's also useful to define in the WSDL not necessarily a value for a property, but just the fact that the property has to be set? (There are many optional properties in the specification.)
Hugo: not sure how we would say that in WSDL.
Anish: agreed that he hadn't thought about the syntax only the requirement.
Paco: +1 for Anish.
Chair asked that the group give Hugo guidance on QName and URI options to assis in getting a proposal for people to consider.
<scribe> ACTION: Hugo to develop proposal for specification. For f2f.
Chair: Features and properties versus open content model.
Hugo prefers open content model, but asked the group if there was a preference. No strong preference either way. Hugo will go with URI and can always change later.
Harris is owner.
<scribe> ACTION: will submit proposal to allow explicit "No faults please".
Gudge: but what does this mean? If you don't understand a message then just bin it.
Anish: can we not use an anonymous URI for FaultTo?
Gudge: that won't work, but maybe some equivalent of /dev/null
Paco: the text in the specification is ambiguous and this isn't really an issue. The text implies that in one-way messages the sender is just incapable of receiving anything. Wasn't sure if we actually want to get into defining some kind of /dev/null structure for this issue.
Chair asked if Paco thought we could clarify the text instead of changing the specification.
Paco & Harris: yes
Anish asked if it is the MEP that defines whether faults can be sent back? If so, then WSI says that one way messages cannot send faults.
Gudge: it is up to the client.
Anish: ok, but that has lead to interoperability problems in the past.
Paco said that protocol level faults may not be reflected in the MEP, but application level faults (such as those from WS-Atomic Transaction) may be.
Harris: yes, but then they are to different endpoints (e.g., the transaction coordinator).
Paco still believes that we can close this issue with an editorial change.
Chair agreed.
Straw poll on making wsa:Action optional:
Yes: Anish, Mark L, Rebecca, Tom Rutt, Yin Len, Arun, Glen, Dims, Mark P, Jeff, Mark H.
No: Gudge, Hugo, Harris, Paul, Mike Leeder.
Abstain: Steve Winkler, Bob Freund.
Gudge: is this for WSDL 1.1 or 1.2 definitions?
Rebecca: both.
Hugo: couldn't the URI actually be an arbitrary document rather than just WSDL?
Rebecca: yes.
Chair asked the group to give any feedback to Rebecca.
Hugo will send his text on this to the list.
The problem is that faults have a fixed action URI, which isn't determined using the same algorithm as general message actions.
Paco: not sure about the issue. Maybe another misunderstanding in the specification.
Gudge: people should put actions for faults into WSDL.
Marc: agreed but we need to be consistent and put all actions in WSDL - get rid of algorithm.
Chair summarized that the concern is that we aren't consistent.
Marc: there shouldn't be a default for any message including faults.
Tom Rutt suggested that if action is optional (Issue 31) then maybe this isn't an issue any more?
Chair suggested that we normalize the defaulting between normal messages and faults. Asked Marc to flesh out a proposal.
Marc wants to hold off expending effort until Issue 31 is resolved.
Chair will schedule Issue 31 for early in the f2f agenda.