- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 23 Apr 2002 10:31:17 -0400
- To: www-tag@w3.org
Hello,
A summary [1] of the 22 April TAG teleconf is
available and quoted below as text.
- Ian
[1] http://www.w3.org/2002/04/22-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
========================================================
Summary of 2002-04-22 TAG teleconference
Note: This is an edited version of the 22 April 2002
TAG IRC log.
Previous meeting: 15 April [Minutes approved at this
meeting]
Next meeting: 29 April. See TAG home for more meeting
information.
Participants: Tim Bray (TB), Dan Connolly (DC), Paul
Cotton (PC), Roy Fielding (RF), Chris Lilley (CL),
David Orchard (DO), Norm Walsh (NW), Stuart Williams
(SW), Ian Jacobs (IJ, Scribe)
Regrets: Tim Berners-Lee. SW Chaired this meeting.
Agenda
See initial agenda:
1. Review of action items
2. Prioritization of issues list
3. Draft finding on Media-Types
4. Guidelines for the use of XML in IETF protocol
5. When to use GET; relation to SOAP
6. Status of architecture document
Action items
Closed:
* RF: Write up discussion of RFC3205 based on www-tag
input. Proposal to withdraw (accepted by Chair).
Will pick back up when we address issue
HTTPSubstrate-16.
Open:
* DO: Write text about "Web as information space", to
be integrated by IJ
* IJ: Integrate/combine one-page summaries. IJ
expects to make progress on this this week.
* TBL:
1. Take question of HTTP Query to W3C/IETF
liaison (issue whenToUseGet-7)
2. Take uriMediaType-9 finding to IETF and IANA.
3. Draft comments on RDF+HTML for namespace
documents.
Prioritization of issues list
See strawman proposal from Stuart (tag@w3.org).
[Ian]
DC: For me the priority is whatever goes first
in the arch doc. I find it hard to address these
issues without context.
SW: So, order by doc order, not urgency/sense of
importance.
DC: Doc order is not arbitrary; things earlier
should depend on fewer other things.
TB: Two thoughts:
1. Agree with DC about starting from points of
few dependencies outward.
2. Also order based on urgency relative to work
going on in w3c (e.g., GET in SOAP)
TB: I like SW's list; it seems to meet both
criteria (a) and (b) (with exception of *-13
first).
SW: Resolved: Handle issues in this order: 7,
15, 6, 14, 16, 8, 13
Draft Finding on Media-Types
See draft Finding on Media-Types. The TAG believes that
there is not consensus around the issue of dispatching
on namespace names.
[Ian]
DC: Note that resources don't have mime types,
response headers do.
TB: Right, you're not talking about resource
here, but message back from server.
NW: I propose removing contentious bit
(namespace-based dispatching) and moving to
"what does a namespace mean"?
TB, CL: Seconded.
[Chris]
ok, agreed
[Ian]
Resolved:
1. Publish this finding as accepted, without ns
dispatch section, and having fixed charset
sentence (s/resource/response).
2. Move the namespace dispatch question to issue
to mixedNamespaceMeaning-13.
Action IJ: Publish finding, move dispatching bit
to other issue.
Guidelines for the use of XML in IETF protocols
"Guidelines For The Use of XML in IETF Protocols": IETF
best practices draft requiring URNs for XML namespaces
in IETF documents. Chris Lilley sent notes on this
prior to the teleconference.
[Chris]
"In the case of namespaces in IETF
standards-track documents, it would be useful if
there were some permanent part of the IETF's own
web space that could be used for this purpose. "
Yes, great. Wish we could assign them an action
to go do that and say what the base URI is?
for HTTP, that is
[Ian]
TB: Has this draft changed recently?
[DanCon]
"W3C recommended practice" should cite "URIs for
W3C namespaces" http://www.w3.org/1999/10/nsuri
[Ian]
SW: I have 15 April on it.
TB: I would bet $100 that when I first read
this, pro URN slant was stronger. I may be
wrong, though. This version is hard to object to
as is.
SW: Is the IETF wrong to mandate URNs for
namespace names? (section 4.5).
DO: I've read through CL's summary. In general,
I would say that most of CL's comments are good
personal comments but not required to be TAG
comments. I think the TAG should highlight the
particular namespace issue.
TB: This has *clearly* been rewritten since I
see that some things have been fixed since I
first read it.
[Chris]
TB notes this has *clearly* been rewritten yet
still says 01.txt
[Ian]
TB: It would be nice if IETF kept around
previous versions.
CL: This isn't the primary source.
DC: They start with "00".
[Chris]
dc notes numbering stats at 00.txt
All: Aha!
[Ian]
Resolved: Postponed to allow TAG to reread.
Homework: Read version 01.
Action CL: Resort and prioritize comments for
next week.
When to use GET; relation to SOAP
Refer to email from DC on findings for issue
whenToUseGet-7. See SW proposal on when to use Post
[Ian]
DC: Demoralizing to get hundreds of comments
without a proposal for alternative. II didn't
hear disagreement about bad idea to subscribe
someone to mailing list as result of GET.
DO: I proposed s/should/may, or to use GET for
browser-centric applications.
NW: I am disappointed if we get down to
application level in an arch document.
CL: I agree that in general, we should go for
generality. But if we can't get agreement on
general points, let's consider important
specifics (e.g., browsers).
TB: I proposed a solution: ""I propose that for
those proportion of SOAP requests that consist
of a service name plus a sequence of
name-value-pair arguments, we devise a simple
url encoding." I made this proposal in good
faith, even if it had been suggested before.
DO: I find the suggestion interesting, but I
don't think it addresses most peoples' issues. I
think that people who want to use GET for safe
methods won't be satisfied. People who are
adamantly for POST won't be happy either.
[DanCon]
hmm... as to whether the case when SOAP stuff
can be url-encoded being a small number of
cases... seems to me it's the big part of the
80/20 bucket. e.g. the hello-world SOAP app,
getStockQuote, fits quite neatly
[Ian]
DC: URL-encoding hasn't picked up any steam. See
comments from Mark Nottingham. The WG not
excited by this before.
TB: But if the TAG is expressing interest in
this, that might help.
DO: There are a couple of people in XMLP WG who
are interested in this topic. Why is there such
a clean disconnect between these two polar
views? I don't think that just saying "you're
doing it wrong" addresses the gap in
understanding.
DC: I've talked to 5 people XMLP WG and all of
them said "Yes, GET would be the more
straightforward method for simple applications
like stock quotes." And I hear XMLP WG
participants saying "We're not interested in the
simple applications."
DO: But we hate the stock quote example. I'd
like to hear how use of POST is actively harmful
and how GET would be better.
DC: Paul Prescod (see comments), TB gave
reasons.
DO: Reasons for certain styles of applications
have been given. But there are other classes of
applications where it's not clear. I don't think
it comes up in practice.
RF: Paul is describing Web applications. The Web
Services community is not dealing with Web
applications.
DO: I liked RF's posting:
[DanCon]
"urls for everything"??? except information
available via SOAP services.
[Ian]
RF: Web Services doesn't use URLs for
everything. That's the problem. If something
uses a URL to identify something makes it a Web
application. Here's the exact principle
involved: "URIs should be used to identify all
important resources." Web services doesn't do
this. The reason you want to use GET is that it
requires URI for identification; that makes it
available to other applications on the Web.
DO: I lobbied that part of definition of a Web
Service was that it be addressable by URI.
That's been accepted as a draft definition. DC:
The price of the stock is not addressable.
TB: DO and I drawing 2 conclusions from same
facts.
[DanCon]
hmm... reviewing
http://www.w3.org/TR/2001/WD-soap12-part0-200112
17/ looking for what's now considered the
meat-and-potatoes applications of SOAP.
[Ian]
TB: I disagree that stock quotes as hello world
is a small subset of Web Services; I think it's
a more important class; I think should be
addressable by URL; I proposed a simple approach
for doing this; I'd like to hear a cogent reason
why not a good idea.
RF: If the same naming authority, that server
can define any URI for that service; better than
a service with no URIs into it.
TB: I agree that a large proportion of Web
Services transactions may be densely structured,
unsafe, etc. I don't see the benefit of going
after those. But for the subset of
request/response that are safe, let's use
URL-encoding.
DO: Did you see MN's response on URL length?
TB: I've been doing this for years; never seen
an application break due to URL length.
RF: The overall issue - if URLs tend to be long
in a service, then all of the technology between
them and the client improves over time. I think
it's been at least six years since 256 char
limits on URLs.
[Chris]
There is a class of application where POST is
superior to GET when sending a message body such
as a form result - unambiguous charset encoding
for the body. Known problem with
interoperability of forms in multilingual sites
that depend on "charset of origin page" when url
is bookmarked and there is no origin page
[Ian]
TB: Any anything you can't pack into a
reasonable URL length is probably not good
candidate for GET anyway.
[DanCon]
I considered writing up this "if it's long, it's
not addressable" and Larry has already given
counter-examples: "validation result for this
(appended) document?" or... "images like this
one?" (not counter-examples, exactly, but...
er... nevermind)
[Ian]
RF: There's no basis for "everything must use
GET" in Web architecture. There is for "use an
URI for everything that's important".
DO: I personally have gone to significant effort
to harmonize Web services with the Web (use of
URIs, use of XML, right use of HTTP). But to
find out my efforts have been in vain (still
doing the wrong thing) is disappointing.
DO: If we are using URIs wrong, a more
problematic area of misunderstanding.
TB: I assert that there are classes of Web
Services that are addressable by URI and
accessible by GET. Web services (SOAP) today
does not enable that. There is a low cost
solution to address this.
[DanCon]
hmm... after scanning the SOAP primer, I don't
see any discussion of mapping Java/Perl/python
method calls to SOAP calls. did 'object access'
go away somewhere?
[Ian]
DO: TB has said that to hit the 80/20 point, it
would be useful to have this particular feature.
I am not saying this is uninteresting. I just
don't think it's a principle of the Web.
TB: I would argue that first principle of Web is
that things have URIs and bet GETable.
Refer to TAG Finding: Mapping between URIs and
Internet Media Types:"All important resources
should be identifiable by URI."
DO: I think we are allowing Web Services to be
addressable by URI.
DC: The results are addressable in the case of
GET but not of POST.
[DC comments no SOAP features]
[DC comments on Primer]
PC: I don't think that the primer has ever used
the term "java" or described the scenario DC
described.
DC: The scenario is there in the larger
community [Scribe didn't get scenario, but about
querying to find out about safe methods]
PC to DC: You must distinguish the evolution of
the use of SOAP. In scenario where URI points to
an encapsulation of our favorite logic (and
service described in WSDL, which can be consumed
by SOAP-enabled software); this kickstarted SOAP
from existing services, but lots of people today
are writing their WSDL directly.
DO: I hear people saying coarse-grain
interactions more useful; avoid a multitude of
back-and-forth interactions.
PC: Most of these document-centered objects are
synchronous. Typically you want your web service
to be asynch.
DC: Summarizing - taking your API and hitting
the button to create a Web Service is apparently
no longer the right thing to do.
TB: As an XML editor, I am profoundly
uninterested in Web Service community's
predictions about how the tools they are
producing will be used.
[Norm]
"No one expects the Spanish Inquisition"
[Ian]
TB: My personal opinion is that a low-rent RPC
request/response based on SOAP wrappers will be
widely used.
[Dave]
norm, lol
[Ian]
TB: ...but whether widely used or not widely
used, why isn't a good thing to expose as a URI.
SW: Are we going to say anything about the use
of POST to do safe things?
DC: That seems in order.
Action DC: Write more on whenToUseGet.
DC: Look at it more as "make things addressable"
Status of architecture document
[Ian]
IJ: Not much progress due to ongoing work on
Process Doc and UAAG 1.0.
PC: What about status of this doc at AC meeting?
IJ: TBL's slides point more to categorization
than arch document.
PC: Should we get AC to read this before the
meeting?
RF: Seems unlikely.
IJ: AC agenda will be sent out soon.
PC: I think the agenda is too late.
SW: What about feedback on other pieces to go in
arch document?
PC: Will slides point to arch doc IJ has been
working on?
IJ: I don't think it's mature enough yet. I
intend to make progress on this this week.
[PC may not be at next week's meeting.]
PC: Will there be a monthly summary end of
April?
IJ: Yes, I intend to.
Received on Tuesday, 23 April 2002 10:31:59 UTC