- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 16 Apr 2002 09:41:19 -0400
- To: www-tag@w3.org
Hello,
Minutes [1] available as HTML and text below.
- Ian
[1] http://www.w3.org/2002/04/15-tag-summary
======================================================
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
* 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
document.
Postponed:
* IETF best practices draft requiring URNs for XML
namespaces in IETF documents. Action to take?
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).
===========================================================
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.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 16 April 2002 09:41:52 UTC