Summary of 2002-04-22 TAG meeting


A summary [1] of the 22 April TAG teleconf is
available and quoted below as text.

  - Ian

Ian 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
    Next meeting: 29 April. See TAG home for more meeting

    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

   * 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

   * 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

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

    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

    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

    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

    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

    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

    hmm... reviewing
    17/ 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

    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

    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

    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

    IJ: Yes, I intend to.

Received on Tuesday, 23 April 2002 10:31:59 UTC