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.


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



Prioritization of issues list

See strawman proposal from Stuart (

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.

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.
ok, agreed
  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.

"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
TB: Has this draft changed recently?
"W3C recommended practice" should cite "URIs for W3C namespaces"
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.
TB notes this has *clearly* been rewritten yet still says 01.txt
TB: It would be nice if IETF kept around previous versions.
CL: This isn't the primary source.
DC: They start with "00".
dc notes numbering stats at 00.txt
All: Aha!
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

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.
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
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:
"urls for everything"??? except information available via SOAP services.
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.
hmm... reviewing looking for what's now considered the meat-and-potatoes applications of SOAP.
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.
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
TB: Any anything you can't pack into a reasonable URL length is probably not good candidate for GET anyway.
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)
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.
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?
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.
"No one expects the Spanish Inquisition"
TB: My personal opinion is that a low-rent RPC request/response based on SOAP wrappers will be widely used.
norm, lol
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

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.