Draft Tag minutes from 10 Oct, 2006

Attached are the draft Tag minutes from 10 Oct.  Text version below.
-Ed


Weekly Tag Teleconference
10 Oct 2006
Agenda

See also: IRC log

Attendees
Present 
Ed Rice, T.V. Raman, Norm Walsh, Dan Connolly, Noah Mendelsohn, Vincent
Quint, Tim Berners-Lee, David Orchard, Henry Thompson 
Regrets 
Chair 
Vincent Quint 
Scribe 
Ed Rice 
Contents
Topics 
Administrative 
passwordsInTheClear-52 
submission of WS-Transfer 
futures 
Summary of Action Items 

------------------------------------------------------------------------
--------

 

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-sec
urity-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/d
nglobspec/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%20ove
r%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.

Summary of Action Items
[NEW] 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]
[NEW] 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]
 
[End of minutes]