Summary of 15 April 2002 TAG meeting


Minutes [1] available as HTML and text below.

  - Ian



                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.


  * Review of action items
  * Follow-up on "Mapping between URIs and Internet
    Media Types"
  * Mailing list policy for www-tag
  * Is TAG doing too much design?
  * When to use GET finding; Web services
  * Integration of one-page summaries into arch

  * IETF best practices draft requiring URNs for XML
    namespaces in IETF documents. Action to take?

Action items


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


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
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
5. TBL: Take uriMediaType-9 finding to IETF and IANA.
    DC recommends mailing, Larry Masinter,
    Donald Eastlake as next action.
6. TBL: Take question of HTTP Query to W3C/IETF
    liaison (issue whenToUseGet-7).

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

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

   I'd suggest , Eastlake as next step
   for TimBL's action.

   TBL: LM asked for discussion to be carried out
   on "xml in ietf list"
   TBL, TB: That's problematic.

   er... there's supposed to be a URI Coordination
   Group in W3C sometime soon, btw. (oops)

   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

   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

   pls put some issue names/numbers in the subject
   line when you send agendas to www-tag

   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?

   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
   TBL: We have gotten a few principles along the
   way, even in discussing nature of namespace
   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.

   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.

   PC: I would prefer if TAG stayed at requirements
   level rather than design level.

   My requirement is that the xhtml must be
   human-writable [sic].

   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

When to use GET finding; Web services

Refer to Draft findings on safe methods from Dan

   DC: How close to agreement on first couple of

A very important principle when designing Web
applications is:
   + safe methods (GET/HEAD) should be used for
     safe operations: read, query, view, ask,
   + safe methods must not be used for unsafe
     operations: write, update, modify, tell, buy,

   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.

   The use of POST for "get stock quote" is wrong.

   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
   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.

   hmm... how would it go into the SOAP 1.2 spec?

   DanC, the SOAP HTTP binding in part 2 uses POST

   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.

   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"?

   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
   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".

   No, "brower centric" is beside the point.

   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?

   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.

   I can see how to put this into the WSDL spec,
   but not so much the SOAP spec.

   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
   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.

   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"

   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".

   Why should I spell-check it? wouldn't that give
   the impression that it's more done than it is?

   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.

Integration of one-page summaries into arch document

Refer to first draft of integrated summaries.

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

   Bray, I don't think Ian has written anything
   newer than what you've seend.
   (er... I haven't seen anything newer, that is)

   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.

   re appendix: pls no. pls let's find whatever
   balance is the right balance

   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.

   I think something like what Ian's written needs
   to be written... I'm just not sure this is the
   right place for it.

   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
   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
   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.

Ian Jacobs (
Tel:                     +1 718 260-9447

Received on Tuesday, 16 April 2002 09:41:52 UTC