Weekly Tag Teleconference

 

Administrative

Next teleconference next week, Oct 17.

Noah regrets for 24th and 31st of October.

T.V. and Dave Regrets for 17th.

 

<Norm> Can we add "minutes of the f2f" as an Administrative agendum?

One piece still missing from F2F minutes, could be finished today. Minutes to be reviewed / approved next week.

Agenda at; http://www.w3.org/2001/tag/2006/10/10-agenda.html

<Zakim> DanC, you wanted to request an agenum on HTML 4 -> XHTML as a possible new issue; perhaps under item 6

Resolution: Agenda approved.

passwordsInTheClear-52

<scribe> New draft out there, short notice so not much feedback yet.

ER: Norm sent feedback, thanks!

<Zakim> DanC, you wanted to advocate 2 best practice notes

<noah> Current text says: Therefore its imperative that any organization who wishes to safeguard its customers data start with secure transfers of user login and password information.

<noah> That's a bit too strong, in that it implies that all good security systems are login + password-based.

Dan: We should point out the two items; Sites should not solicit passwords in the clear and browsers should not transmit them.

<Zakim> noah, you wanted to mention editorial issues and at least two that may be substantive

<noah> Suggest something like: "...imperative that any org that uses password-based security to safeguard its customers data start with secure transfores of....

Noah: suggest adding this to the bottom of section 2.
... 2.2 on SOAP, 2 issues.. in the 2nd sentence SSL secures point to point, more complex if using intermediaries. (spelling)
... add after intermediaries.. or if data needs to be secured at the end-points.

<DanC> (I'm interested pointers to what Ed read yesterday about ws-secruity and TLS/SSL)

http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf

Vincent: More comments?

<DanC> (ah... that pointer looks familiar; I think I saw it in a msg from Paul C)

<scribe> ACTION: Ed to publish update in one week for discussion in two weeks 31st. [recorded in http://www.w3.org/2006/10/10-tagmem-minutes.html#action01]

submission of WS-Transfer

Dan: I made the request on Tim's behalf..

<noah> Back on the question about security headers in ws-security:

<noah> From: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Tim: If anyone on the call wants to go back over the issues on this, than do.

Dan: We dont have any recorded issues on this.

<noah> As elements are added to a <wsse:Security> header block, they SHOULD be prepended to the existing elements. As such, the <wsse:Security> header block represents the signing and encryption steps the message producer took to create the message.

Tim: Its been suggested that this specification provides the same functionality as HTTP but over web services.

<noah> I think that makes the case that SOAP headers are used to control encryption (which is, BTW, XML Encryption-based)

Tim: I thought the team may have some thoughts on this and if its architecturally broken

<DanC> ws-transfer submission request

<DanC> W3C team comment on ws-transfer

Tim: has anyone had time to read this?

Noah: I've skimmed this, but its not quite on the surface a replacement turned upside down.

<DanC> (ah... re Noah's 3 points, 2 of them are TAG issues: using SOAP rather than GET conflicts with our decision on issue whenToUseGet-7, and using EPRs rather than URIs is endPointRefs-47, still open)

Noah: I'm uncomfortable with EPR's instead of URI's

Tim: and you have a completely seperate caching system.

Noah: they appear to be trying to move binary through xml.

<Noah> What I really said was that there is a positive view, which is in the case that you were for some good reason going to use another protocol, such as durable queuing software (IBM's WebSphere MQ, for example), this does bring it somewhat closer to a Web model.

Welcome Dave Orchard

Tim: Maybe you can describe this paper to us Dave.

<DanC> (er... <wsa:To>soap://www.example.org/repository</wsa:To>? a soap: URI scheme? is that registered?)

<Noah> I do have some concern, other than the use of EPRs instead of URIs, that a WS-Transfer GET may well bind to an HTTP POST rather than HTTP GET in the particular case where you are going over HTTP.

Dave: The short answer is.. it comes mostly out of the management space where your managing resources and you have a constrained space for managing these resources and we want to be able to this using soap and over multiple protocols and reliable messages and ws policy and etc.

<Timbl> There are webdav-like features, etc but no content negotiation

Dave: I think its very similar to whats in HTTP. There are some web-dav kinds of things in there where you can get specific resources like put and get in http
... you would pick at deployment time which protocols you would actually use.

Tim: so the same URI would point to the same resource?

<noah> Surely you meant EPR, Tim? :-)

Dave: the same operation. but when you deploy it you could deploy it using HTTP or not so the end-state referance would be set at deployment time.
... In general, you'd probably pick the address of the URI at deployment time.

Tim: There is an example in there. A simple soap request which has a get request. Whats being requested there.

<timbl> http://schemas.xmlsoap.org/ws/2004/09/transfer/Get

<noah> I think the GET is directed to the wsa:to EPR

Noah: My recollection is that there is this trick thats played with EPR's where an EPR has a bunch of properties but when its mapped to soap each of these properties gets its own header.

<timbl> """ <xxx:CustomerID>732199</xxx:CustomerID>

<timbl> <xxx:Region>EMEA</xxx:Region>

<timbl> """

<timbl> There are the EPR

Dave: exactly, the expectation is that it will be used with WS-Addressing and will be used to pass around resources.

<noah> Those xxx:CustomerID & Region things presumably came from the mapping of the EPR into separate SOAP headers.

Dave: from a web architecture perspective, I admit that I'm torn about this specification. When you take soap and you add in ws-addressing, ws-transfer starts looking like HTTP with angle brackets.
... but if your protocol independence you kind of have to.

<DanC> (DOI is one of the parties in the un/registries discussion)

Tim: This protocol independence is the reason for DOI etc, but it sounds like your writing your own protocols. Various people say they need to be protocol independence and sometimes it leads to something we consider a bad thing.

Dave: Yes, because it forces you to reinvent the protocols your trying to be independent from.

Tim: Yes, exactly.

<DanC> (oddly, "doi" doesn't occur in http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml v 1.21 2006/08/17 ... er... is that current?)

Dave: Well, if we had come up with a framework so we can be protocol independent and mix and match at different levels to get that. However, this has frankly not been interesting to the people driving the WS-* specifications.

<DanC> ("The DOI System is for identifying content objects in the digital environment." http://www.doi.org/ )

<noah> tnx

Noah: Well, for the example of saying I want to do something like an http get but I don't mind if it takes hours to get a response or if the network is down it can wait. In this case, I can see where something like this may make sense.

Tim: Of course, I think Roy if he were here would probably have a lot to say about this.
... HTTP protocol is designed to be a bit of a gateway function and allows you to encompass different protocols such as FTP.

<DanC> (in sum, I don't see any new issues here. I think there's a clear clash between WS-Transfer and whenToUseGet-7 in some cases (maybe this is new information that merits reopening that one), and our EPR issue is still open.)

Tim: So essentially as HTTP is a gateway protocol, its a bit of an extraction so it can connect to other protocols.

Noah: if the keep alives don't work on the wire though, they need a way to store that transaction and process it later as opposed to http get which wouldn't allow this.

Dave: Noah, good point. We at BEA tried to some reliable messaging using http post, similar to what IBM did with httpr but nobody uses it. I'm not sure if its because of marketing or nobody knows about it or what.

Noah: But just to be clear, there is a large amount of business use of these reliable messaging systems.

<Zakim> DanC, you wanted to ask for help finding the http reliable messaging thingy

Dave: I'd say of the ws-* things going on, reliable messaging has got the most attention.

<DanC> (http://www.goland.org/draft-goland-http-reliability-00.text SOA-Reliability (SOA-Rity) for HTTP November 7, 2005 )

<Vincent> doceng 2006

Dave: if you look at the core part of the REST architecture is this sort of stateless architecture.

<DanC> (was it Dave or Noah who said that? maybe it doesn't matter.)

Dave: so one of the questions is, from a web architecture perspective what is the view of ws-addressing. From a base blush it appears to be a parallel architecture and I dont know how bad that is.

Tim: Yes, from first blush it appears it is.

<noah> I think Dave pointed out that individual HTTP interactions tend to be stateless.

Tim: its bad because it weakens deployment of Http system, it weakens the caching system since everyone has to duplicate everything.

<noah> I made the point that at a lower level, reliable queuing systems tend to keep durable state on disk relating to point-to-point connections, and that state is typically retained across multiple messages sent between the same two endpoints.

Tim: and of course that its a new protocol so it has to go from the ground up from what HTTP had to go through.

<noah> So, when you tunnel HTTP interactions over MQ, the HTTP interactions work fine and appear stateless, but at the next level down there is a typically a lot of point-to-point statefulness.

<noah> Perhaps what's harmful is: WS-Transfer GETs over HTTP don't map to HTTP GETs

Dave: So you mentioned exactly the rub. But if you were going to say anything as the TAG we should have done that at the EPR level.

Tim: We did, didnt we?

<noah> I think it's worth going back and finding our response. Will see if I can do it quickly.

Dave: almost everything you see in a reference parameter has an :id at the end of it so it looks like an EPR. But I think the horse is kind of out of the barn.
... I agree it doesnt promote more use of HTTP URI's.

Noah: I found the reference.

<noah> http://lists.w3.org/Archives/Public/www-tag/2005Oct/0057.html

<noah> Quoting from that:

<noah> Taking all these factors together, the TAG today resolved to ask that the Web Services Addressing Working Group include the following note in a suitable section of the Web Services Addressing 1.0 - Core Proposed Recommendation:

<noah> Note: Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to Web Architecture. In certain circumstances, use of such additional properties may be convenient or beneficial, perhaps due to the availability of QName-based tools.

<noah> When building systems that violate this principle, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web.

Dave: so what would happen if the TAG says WS-Transfer is really bad for the web architecture.

Noah: Well, lets turn it around and say yeah, this stuff is protocol independant but a get should turn into a get and that would force you to look at http URI's.

Dave: yes, but to get there I'd say there is some technology needed.

Noah: yes.

<DanC> oops; there it is.

<noah> Specifically, what I'm saying is, that it would be a good goal in principle if in the particular case where this is mapped to SOAP over HTTP, it turns into an ordinary GET that (probably) results in an envelope of media type application/soap+xml

<noah> I have some doubts that the communities promoting this will want to go that way, and it obviously is harder to do in the cases where the EPR parameters are used to carry identifying information.

Tim: Well EPR's used to have URI's in them.

Dave: They all do.

<timbl> <wsa:To>soap://www.example.org/repository</wsa:To>

Noah: what your reading isnt the EPR but the soap binding of the EPR

Vincent: Tim, this was put on the agenda because you suggested that we could have some comments on it, but do you expect something more of the TAG?

Tim: We've already made a fairly muted statement on this. I do think it would be useful to have a TAG comment on this and to point these things out.
... As Dave said, if we let this go by without saying something strong then why and we'll think we've let ourselves down and let the community down.

DanC: We should make a decision about when to use HTTP-Get7 and clarify this to the W3C teams.

welcome back Dave

<Zakim> DanC, you wanted to ask about the soap: URI scheme: (a) is that hypothetical or deployed for real, and (b) is it registered? and if not, who owns it, i.e. who should I pester to

<DanC> SOAP-over-UDP http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/soap-over-udp.asp

Vincent: ok, its time to move on to the rest of the agenda, but before that we had a discussion and a few ideas came up during the discussion and these are in the IRC.
... Dan/Tim, do we need to do more?

Dan: I move to re-open issue 7.

<noah> Spec for SOAP over HTTP: http://msdn.microsoft.com/ws/2004/09/soap-over-udp/#search=%22soap%20over%20udp%22

Vincent: which was closed 2 years ago

Dan: Yes, but now we have new information.

Vincent: yes, but does that address the request from the team.

Dan: When we close it again, I would expect to have a response to the teams question.

Noah: So isn't this -47?

Dan: Yes, but we haven't closed that one yet.

Vincent: ok, we have a motion to re-open issue 7 because of this new information, what do others think?

Dave: Ok, that's fine.

Dan: We often have owners for action items.. and I suspect Dave we close to volunteering.

Vincent: do we have opinions about reopening issue 7?

Norm: I think its a fine idea.

Tim: Ok, I'm happy with that.

<DanC> http://www.w3.org/2001/tag/issues.html#endPointRefs-47

Noah: Yeah, I think we should open it and know that its that issue together with EPR's as an umbrella for this issue.

Vincent: Ok, so lets re-open this.

RESOLUTION: Re-Open issue 7.

<DanC> timbl, I nominate you to call for discussion of issues 7 and 47 and ws-transfer on www-tag.

Noah: I think someone should frame it more. Its going to be a political hot potato.

Dave: I'm open to having Tim send it to Tag only and have Noah on critical path.
... Yes, this could take a fair amount of tag's time over the next little while.

Noah: We can point to the ERP API discussion and the fact that the soap community agreed to do some things and to point out that a direction has been set there and that the TAG has an interest in seeing things carried forward in that direction.
... so maybe one of things we could do in a note like this is to point out the gap that SOAP agreed to do things like use GET properly but that ws-transfer doesnt appear to support that.

Timbl: what we agreed specifically was that you would take the soap request and encode as a URI.

Vincet: Ok, we're really running out of time. I'm interested in any action that would allow the issue to be better framed and to keep the ball rolling.

Vincent: Dave, would you be interested in sending a message to re-open the issue?

Dave: no.

Tim: Should I draft it and noah should edit it?

Noah: Yes, lets send it to the private tag list first until we edit it. Tim needs to be involved.

<noah> NM: Sure, I'll take a look, but I don't see this as specifically mine to take the lead. Everyone on tag@w3.org can review, but I certainly will try.

Vincent: The proposal is; Time to send a message to the private tag list and Noah and maybe Dave will contribute to polishing the message for the public list.

Tim: Ok, I'll try and do it tomorrow.

<noah> Actually, what I said above was not "Ws-Transfer doesn't appear to support that", but rather, "it would be nice to find out that they can support it"

<noah> I'm not necessarily optimistic that they can, but I think it

<noah> it's an appropriate positive goal.

<scribe> ACTION: Timbl to send draft of issues 7 and 47 and ws-transfer to tag@w3 for revision and discussion internally. [recorded in http://www.w3.org/2006/10/10-tagmem-minutes.html#action02]

futures

Vincent: this will wait and we can do this via email.