Summary of 2002-04-15 TAG meeting

Note: This is an edited version of the 15 April 2002 TAG IRC log.

Previous meeting: 8 April [Minutes approved at this meeting]| Next meeting: 22 April | TAG home

Participants: Tim Berners-Lee (TBL, Chair), Tim Bray (TB), Dan Connolly (DC), Paul Cotton (PC), Roy Fielding (RF), David Orchard (DO), Norm Walsh (NW), Stuart Williams (SW), Ian Jacobs (IJ, Scribe)

Absent: Chris Lilley

Note: The TAG agreed that Stuart Williams should chair the TAG when TBL is not present. TBL will not be present next two weeks.

Agenda

Postponed:

Action items

Completed:

  1. IJ: Create separate page with list of findings.
  2. SW: Amend TAG Finding: Mapping between URIs and Internet Media Types
  3. DC: Write up summary of resolution for whenToUseGet-7 by showing support for RFC2616 section 9.1.1.
  4. TBL: Write draft on when URI variants are considered equivalent (URIEquivalence-15). See Axioms of URIs

Open:

  1. DO: Write text about "Web as information space", to be integrated by IJ into arch doc intro.
  2. IJ: Integration of 1-page summaries. See initial draft
  3. TBL: Draft comments on RDF+HTML for namespace documents; work started but not yet available.
  4. RF: Write up discussion of RFC3205 based on www-tag input.
  5. TBL: Take uriMediaType-9 finding to IETF and IANA. DC recommends mailing uri@w3.org, Larry Masinter, Donald Eastlake as next action.
  6. TBL: Take question of HTTP Query to W3C/IETF liaison (issue whenToUseGet-7).

No new actions in this meeting.

Follow-up on "Mapping between URIs and Internet Media Types"

Given revised TAG Finding: Mapping between URIs and Internet Media Types:

[DanC]
I'd suggest uri@w3.org , Eastlake as next step for TimBL's action.
[Ian]
TBL: LM asked for discussion to be carried out on "xml in ietf list"
TBL, TB: That's problematic.
[DanC]
er... there's supposed to be a URI Coordination Group in W3C sometime soon, btw. (oops)
[Ian]
TBL: I will respond to LM about where to continue this thread; we'd like this discussion on www-tag since we don't have anyone to follow it on IETF list.

Mailing list policy for www-tag

[Ian]
TB Proposal: Post agenda to www-tag and ask people to focus on these issues. Let's try that for a while.
SW: Also, we should prioritize issues. (See SW email to tag list).
TBL: TOC of arch doc was to be clustering.
DC: Sounds like SW's clustering and the TOC line up.
[DanC]
pls put some issue names/numbers in the subject line when you send agendas to www-tag
[Ian]
DO: I'm not sure that this will prevent some people from saying what they want to say.
TBL: I think we should do what TB said, but also respect www-tag as a place where people raise issues. I hear SW saying "let's spend more time on dispensing with issues" but let's not close ears to new ones. I hear SW proposing more organized stacking of agenda items

Is the TAG doing too much design work?

[Ian]
PC: One reason we're getting flooded with mail is that we're doing technical design. (e.g., on the nature of a namespace document). After enough pointers from people, I thought that this was starting to feel like a technical working group. But I think that writing principles has a higher priority. We might ask w3c to assign job of implementing to appropriate WGs.
DC: I am of two minds on this: On the one hand, I don't know that we need to cross all the t's, but if we don't, people will keep asking us for it.
TBL: We have gotten a few principles along the way, even in discussing nature of namespace docs.
PC: I don't think we have as much agreement as TBL things.
NW, DO: I agree with PC.
TB: I'm surprised, I thought we were converging on this.
[DanC]
if we're not agreed (that you should put *something* there, at the end of a namespace pointer), I'm willing to spend whatever time it takes to get agreement.
[Ian]
PC: I would prefer if TAG stayed at requirements level rather than design level.
[Dave]
My requirement is that the xhtml must be human-writable [sic].
[Ian]
PC: I agree that many of us agree that there could be a namespace doc at end of namespace, some votes are conditional on the nature of the document. I'm suggseting that the TAG doesn't need necessarily to resolve that.
TB: I think that at our level of operation, distinction between arch and design goes away. I don't believe in the model where we do principles and hand off design to others.
DO: I am sensitive to PC's point - if we act as a WG, we will get less done on principles. But I agree that in this case (namespace docs) my final view depends on syntax. I'm not decided on whether we should do this work. This issue of the namespace is helping us figure out our process.

When to use GET finding; Web services

Refer to Draft findings on safe methods from Dan Connolly.

[Ian]
DC: How close to agreement on first couple of paragraphs?

A very important principle when designing Web applications is:

  • safe methods (GET/HEAD) should be used for safe operations: read, query, view, ask, lookup
  • safe methods must not be used for unsafe operations: write, update, modify, tell, buy, agree

DO: I have a concern about the word "should" instead of "may" in first bullet. How does this relate to Web services world and the use of POST with SOAP messages?
DC: "Don't do that" is my answer.
DO: In the Web services world, it's a well-documented "fact" that most uses of SOAP messages are through POST. E.g., classic get stock quote is done through POST. POST is used to navigate shared something space.

[DanC]
The use of POST for "get stock quote" is wrong.
[Ian]
RF: Yes, it's wrong.
TB: People have been using POST for years due to large lists of arguments. But you can't bookmark as a result. When you can do it with GET, you should do so, and that adds to the utility of it. Utility of Web services would be increased by use of GET.
TBL: I propose we ask DO to take this message back to the Web services community: tools creating services need to help designer make choice that end up with proper implementation.
DO: I don't agree that the way that Web services work is the wrong way to do it.
PC to TBL: One of the problems with this sort of design is that it presupposes that you know what kind of message you will be sending.
In SOAP 1.2, one doesn't know about the messages.
TBL: We're talking about changing the situation, not just observing the current state of the spec and software.
PC: Are specs factored correctly for one to be able to carry out this chore?
TBL: If WSDL does not capture whether there's a safe method, that's a bug.
PC: SOAP 1.2 has been written without knowing that WSDL exists.
TBL: Then it needs to go into SOAP and possibly other things.
PC: What does HTTP binding use today in SOAP?
DO: POST.
[DanC]
hmm... how would it go into the SOAP 1.2 spec?
[Dave]
DanC, the SOAP HTTP binding in part 2 uses POST
[Ian]
IJ: What are DO's objections to using GET in the Web services context?
DO: I do not believe that the way that Web services groups are moving forward is incorrect. I'm not prepared to go to them and say that what they are doing is wrong.
[DanC]
DaveO, pls answer Ian's question: what's wrong with the principle that "* safe methods (GET/HEAD) should be used for safe operations: read, query, view, ask, lookup"?
[Ian]
DO: I don't think that idempotency has come up in web services activity. The way to move forward is to have a mtg with the web services arch WG. I'm suggesting that this is a bigger issue than DC's one line.

DC: But in what way do you disagree?

DO: It gets into the shared information space. If you're dealing with the shared information space, you care whether the info is idempotent or not. When you are doing things from a service perspective, or shared processing space, that feature becomes less important. I would argue that from a web services developer perspective, it's unduly complicated.
RF: The way that web services is designed, there is no generic interface. So there is no concern about safe or unsafe methods. In general they don't have methods in the web services space. SOAP should not be tunneled over HTTP. The point is that web services space doesn't deal with methods at all at this point because when you're operating via a web service, both sides know the semnatics of the service, or they don't interoperate at all. Whether GET/HEAD/POST is only relevant for the HTTP transfer mechanism (for tunneling of web services) and this is not HTTP-compliant to begin with and should not be done. So this is a non-issue whether you take this to Web services groups or not.
TBL: When there is an object that is a service that is in HTTP space, POST is there to submit things to it. To submit an operation to is it reasonable.
There is a loss when the operation is just a read of the space. I see this loss all the time when I interact with my bank. I can't use the back button since the browser keeps warning me that I"m resubmitting the post. It's more work on the bank server as well. It's inefficient from everyone's point of view (user, network, server). That mistake is being transferred into web services. Web services are still young; their effect on the Web has not been seen. I disagree with RF that you should never submit information to a service with POST. But I think we need to encourage web services to split information into safe and unsafe bits. I think we should go to the Web services community and get a change.
RF: I don't think we disagree, TBL.
TBL: The web services people can keep the web services model, but the bindings should be safe when they can be. Use the underlying/existing caches, etc.
TB: RF said that you shouldn't run SOAP over HTTP. Well, they're going to.
RF: Intermediaries will break when it happens.
TB: So it's appropriate for us to make architectural assertions about this. I agree with TBL that there's a right way and wrong way to do this.
TB: I think that:
  1. It's appropriate to say you should use GET.
  2. It's also appropriate for Web Services Architecture people to consider this.
  3. Web Services people may feel they don't have an issue here because it's all machine-to-machine, and the "client" program will know what's going on. But I disagree - in a future with a much more programmable brower, I think it would be interesting and good to have a pointer from a human-readable web page to a web service. And in that mode, GET is definitely the way to go.
TB: I look forward to a future where one can put a URI to a web service in a web page. If GET is never used, we may not have this much more interesting web. So I support "Should use get" and work with Web services community to take advantage of what web offers.
DO: I could live with "GET should be used for browser-centric sort of things." I take issue with "GET should be used in all areas".
[DanC]
No, "brower centric" is beside the point.
[Ian]
TBL to DO: Would you be willing to lead a charge in the web services community to set up the job about what would need to be changed, and who would need to be involved, to introduce the idea of binding SOAP to GET?
[Ian]
DO: I disagree with the position, but will be happy to organize a liaison.
PC: One way to execute what TBL would like is to have the TAG review the SOAP 1.2 spec.
TB: What's current status of SOAP 1.0?
DO, PC: We're a couple of weeks from going to last call.
[DanC]
I can see how to put this into the WSDL spec, but not so much the SOAP spec.
[Ian]
SW: I have been wrestling internally with these issues. I can see the merit of GETs for safe operations. I can see that when you are uncertain, POST may not be a bad choice. [SW acks thinking on the fly here...] There has been a tension since creation of WG between SOAP having character of thing it's bound to, or thing with character of its own. I've been wrestling with tunneling issues. I can see a view that "SOAP is just a content format [that you can use with HTTP]"
RF: We should tease out the principles in the findings. What TBL wants is an indication of the semantics of the action visible to all participants before the action is made. A client may need to know whether an operation is safe in order to execute the action. Same with proxy. That's independent of HTTP (or HTTP method used).
TBL: I want to push back on the idea that HTTP GET only applies to browsers. It applies even more to an agent. When a piece of software will click on a link, will be done without the user's oversight. The way that web services is working (services between different companies across trust boundaries) is different from rpc; you want to keep a record of transactions. I think that this principle applies absolutely to clients acting on a user's behalf.
TB: I think we should send a message to web services that we have a concern here.
[DanC]
Where to go next: I suggest actions be assigned to anybody who disagrees with "* safe methods (GET/HEAD) should be used for safe operations: read, query, view, ask, lookup"
[Ian]
DC: I heard a majority in favor of "should/must not". I suggest that whoever disagrees has the ball to follow up.
TB: I suggest to post DC's finding to www-tag with "should/must not".
[DanC]
Why should I spell-check it? wouldn't that give the impression that it's more done than it is?
[Ian]
SW: I think we should wait a week, and get some more discussion, before trying to get consensus around this.
DC: Then I shouldn't say to www-tag that "most people agree with this"?
TBL: Let the meeting record show that we do not have consensus on DC's proposal.
agenda?

Integration of one-page summaries into arch document

Refer to first draft of integrated summaries.

[Ian]

TB on style of introduction: Good but too much of it. There's a sweet spot in-between terse and what's currently there.

[DanC]
Bray, I don't think Ian has written anything newer than what you've seend.
(er... I haven't seen anything newer, that is)
[Ian]
IJ: Please expect fuzziness at first, then some will be pared away.
TB: Each word carries serious normative weight. Keep the verbiage down.
NW: I think that TB's point is well-taken. Words will be scrutinized.
[DanC]
re appendix: pls no. pls let's find whatever balance is the right balance
[Ian]
IJ: By the way, I support TB's point as well. Working towards it.
TBL: The doc consists of the four areas of web arch with a prepending introduction.
[TBray]
I think something like what Ian's written needs to be written... I'm just not sure this is the right place for it.
[Ian]
RF: I think that this doc will ultimately have different outline than four chapters we have now. I'm happy to start this way.
IJ: But I'm writing the intro based on these chapters...
TBL: I thought that 3 wasn't about summarizing REST. But more about how the protocols implement the information space. Role of chapter 4 is to talk about the services as such.
RF: I thought 3 would describe the application state of portraying the hypertext view of the world.
DC: I agree.
RF: I have a hard time speaking to the four chapters. I'm not entirely sure that docs come second. I'm sure that we'll talk about properties we want out of a web arch. That's not there now.
RF, DC: Put the stuff in and see what happens.
DC: Anything less than words we agree to won't get us what we want.
TBL: I don't think that section 3 as elaborated will fulfill the role I have in mind.
RF: I agree with TBL. It doesn't fit.

Note: After the meeting, TBL, RF, and IJ met to discuss the document and reach better understanding about the nature of chapter 3.