Summary of 29 Apr 2002 TAG teleconference


The 29 Apr 2002 TAG teleconference summary is
available as HTML [1] and is quoted below as text.

  - Ian


             Summary of 2002-04-29 TAG teleconference

    Note: This is an edited version of the 29 Apr 2002 TAG
    IRC log.

    Previous meeting: 22 Apr 2002 [Minutes approved at this
    Next meeting: 5 May ftf meeting. See TAG home for more
    meeting information.

    Participants: Tim Bray (TB), Dan Connolly (DC), Roy
    Fielding (RF), Chris Lilley (CL), David Orchard (DO),
    Norm Walsh (NW), Stuart Williams (SW), Ian Jacobs (IJ,

    Regrets: Tim Berners-Lee, Paul Cotton


    See initial agenda:
     1. Review of action items
     2. Making progress on architecture document
     3. New issue: Review of "Character Model for the Web"
     4. New issue: Qnames as IDs
     5. Status of finding on Internet Media Type
        registration, consistency of us
     6. TAG ftf meeting agenda
     7. What action to take on "Guidelines for the use of
        XML in IETF protocols"?
     8. Status of finding on When to use GET?

   Summary of resolutions:

     1. Accept as issue charmodReview-17 the "Character
        Model" review request.
     2. Accept qnameAsId-18 as issue.

Action items

  * IJ: Publish draft finding on Media-Types (after
    edits). But see (tag-only) comments from SW.
  * CL: Prioritize comments on Guidelines for the use of
    XML in IETF protocols. [Gone over during this

  * DO: Write text about "Web as information space", to
    be integrated by IJ
  * IJ: Integrate one-page summaries
  * TBL: Take question of HTTP Query to W3C/IETF liaison
    (issue whenToUseGet-7)
  * TBL: Draft comments on RDF+HTML for namespace
  * TBL: Take uriMediaType-9 finding to IETF and IANA.
  * RF: Write up discussion of RFC3205 based on www-tag

Making progress on architecture document

   SW: General question about TAG agenda; driven
   from proactive to reactive. Do others feel they'd
   like the balance to be more active than reactive?
   RF: I'd rather be working on the document.
   TB: It's important to not let the arch doc
   CL: Agreed.
   TB: Let's put this question on the ftf agenda:
   How to make progress on the arch document.
   IJ: I acknowledge the problem of my
   inavailability these days due to concurrent
   TB: IJ is not de facto available; what should we
   do? Should we do some of the editing ourselves?
   CL: It would give IJ less work if we polish our
   own sections.

Digression into section "What does a document mean?"

   NW: With respect to: "What does a document
   mean?": My efforts petered out since I haven't
   heard consensus of opinion on some pieces.

   I'm quite happy with folks writing their own
   opinion and asking if other folks agree, Norm.

   CL: Not clear whether this section is addressing
   just "document-like" resources or all resources.
   NW: Trying to address all resources. Not sure
   that document v. data is useful architecturally.
   IJ: XAG 1.0 finds interesting to distinguish
   data-centric and user-centric content; but no
   formal distinction.
   SW: What about RF's writing on application state?
   RF: TBL, IJ, RF talked about this section. The
   ball is in IJ's court to write down the ideas.

   Action NW: take another pass over "what does a
   document mean" before the face-to-face meeting.

New issue: Review of "Character Model for the Web"

Refer to preliminary review request from Misha Wolf

   RF: Covers character requirements for every
   protocol. It's architectural in that it touches
   CL: Charmod introduces ability to put
   unicode-encoded URI ref in a document. Makes it a
   req that protocols say when it happens. Stuff you
   send over the wire is percent-encoded. But you
   can put company names in URIs (e.g., on the side
   of a bus). Conversion to percent (hex) encoding
   doesn't change what goes over the wire.

   I don't agree with the summary that Chris just

   RF: I don't think that IRI will exist for long;
   not integrated in the URI draft. I was opposed to
   IRI four years ago because they wanted to
   integrate it before having implementing it.
   CL: This doc has several sections. Section 3 is
   on characters. With the exception of sorting, the
   entire section is a description of current
   It will be very good that all this is gathered
   into one place. Normalization stuff is
   contentious but has benefits.

   I sure wish they'd split the document. Hmm... I
   wonder if I asked them for that in so many words.

   CL: I with they'd split it up, too. I recommend
   that the TAG review this document.

   I 2nd the request to review

   IJ: What makes this document different from
   xforms (see issue xformsReview-4), its
   significant impact on other work?
   CL: Yes.
   NW: I've committed to review for XML Core. I will
   send my comments to both core wg and tag.
   DC: Please tune your head differently for two
   CL: I volunteer to review and act as a liaison
   and coordinate comments.
   Resolved: Accept as issue charmodReview-17 the
   "Character Model" review request; CL will
   coordinate the TAG's review comments.
   Action CL: Respond affirmative to Misha Wolf's
   request to review entire document.
   Action IJ: Add charmodReview-17 to issues list.

   Last Call period begins 30 April 2002 and ends 31
   May 2002.

   hmm... TAG to finish its charmod review by 31
   May? I doubt it.

New issue: Qnames as IDs

Refer to question from Joseph Reagle

   CL: I'm seeing increasing use of qnames as ids.
   CL gives some scenario that scribe missed:
   essentially, "Qname is a URI/name pair"
   SW: Is there a new issue here?
   DC: I think there is an issue. I think it's a
   myth that one can rewrite prefixes when one
   copies part of an xml doc from one section to
   TB: For the record - I argued intensely when
   James Clark wrought this on the world that this
   was the wrong thing to do. I lost that argument.
   Now that the genie is out of the bottle, I'm not
   sure what we can say useful about it. There seems
   to be consensus that at the end of the day a
   qname is a URI/local name pair. What else needs
   to be said?

   I gather Tim Bray's argument can now be
   summarized as 'I told you so.'

   TB: A qname is a prefix plus a string of
   CL: What issues bit us?
   TB: This bit us in the case of the DOM.
   NW: I agree with TB - shouldn't have done this in
   the first place. But now we need to move on.

   Well, as to what we can do about it, I think we
   can say 'this sucks; sorry; deal; don't expect
   things to work nicely.

   SW: I'm hearing CL suggesting to make this an
   issue and issuing a finding?
   DC: There's a lot of experience. We can condense
   it. Not everyone knows the plusses and minuses of
   CL: Yes, I think a finding would be useful.
   SW: Volunteers?
   Resolved: Accept qnameAsId-18 as issue.
   Action NW: Draft a finding explaining advantages
   and disadvantages.
   Action IJ: Add this to the issues list.
   CL: Keep it neutral - legal but pros and cons.
   DO: So it's not really an arch recommendation.

   Norm, I recommend including examples, good and
   bad usage, etc.

Status of finding on Internet Media Type registration,
consistency of use

Refer to still draft finding on Internet Media Type
registration, consistency of use

   Last modified: $Date: 2002/04/29 21:35:01 $
   RF notes that IE Mac crashes on this document.

   ooh, TimBray, I'm interested in clues on choosing
   which mozilla to use on a mac

   DC: I move we accept this draft.
   RF: I agree with SW comments (on
   SW summary of comments: s/resource/response.
   Found this a bit jarring.
   CL: I agree with this.
   DC: But at the the last meeting said "resolved
   s/resource/response" resolved: Publish this
   finding as accepted, without ns dispatch section,
   and having fixed charset sentence
   TB: The point was that we were talking about the
   bits received.
   DC: What IJ wrote is what I would have expected
   based on our meeting of last week.
   RF: This is wrong. The finding says that
   representations only exist in responses. We're
   talking about media types.
   CL: Don't imply that some things only are found
   in responses.
   TB: I request that we take more time to review
   Homework: review this finding for next meeting.

TAG ftf meeting agenda

   DC: TimBL on holiday this week.
   SW: Agenda suggestions?
   TB: Two things I'd like to accomplish:

  1. Meta-work on arch document. Style, structure.
     I'm not satisfied with progress thus far.
  2. I'd like to drive a stake through

   TB: Soap 1.2 is going to go to last call soon. I
   suspect that at least TBL, RF, and I will have
   some issues about what's in there. I'd like to be
   proactive, read SOAP 1.2, and identify
   architectural issues, come up with an action plan
   (who does what when).

   if there's a suggestion to read "soap 1.2",
   please include dates and URIs of the specs; I
   gather the published /TR/ for SOAP isn't the
   thing to read.

   NW: I'd like progress on arch doc. Let's use ftf
   time to make progress on that and slow issues.
   DO, RF, CL: Agree with above requests.

   DC: Mixed namespaces, if only to show ourselves
   that we won't make progress.
   Action SW and IJ: Work on face-to-face meeting

What action to take on "Guidelines for the use of XML in IETF

   CL: Some comments on guidelines from editors
   suggest some fixes will take place (but wouldn't
   have occurred if charmod already a Rec). Also,
   they say "should be well-formed". No! Must be
   well-formed XML.

   (already a REC *and* widely read and understood;
   unfortunately we can't publish directly into
   developer's minds)

   What Chris said, +100 :-)

   CL: I don't want a protocol coming out of IETF
   saying "Should be well-formed...."
   TB: Absolutely.
   SW: They expect to "roll a new one" in a week or
   TB: Larry Masinter has asked us to postpone
   discussion; see request from LM.
   LM: New draft expected "in a couple of weeks"
   SW: We will postpone discussion until that draft

Status of finding on When to use Get?

See DC's edits to findings on whenToUseGet-7.

   DC: See "fodder section" at bottom of document.
   See email from LM; I like his comments.
   TB: I think LM's version is close to DC's
   version. Were you thinking of redrafting your
   language using LM language?
   DC: The original findings didn't explain what you
   lose when you don't use GET. So I would like to
   add examples. Also, I don't agree with the
   "browsers v. clients" distinction, so I'd like to
   make that case, too.
   CL: There are cases when I want to bookmark the
   results of submitting a form and upon return
   re-POST, and other cases where I do not want to
   re-POST (I just want a URL to track info).
   TB: When you buy a book, for the safety
   criterion, this has to be done with a POST
   anyhow. I think we are mixing the issues here.
   DC: LM pointed out that POST response can give a
   content location.
   TB: That's a safe way that's playing by the
   RF: It isn't necessary to be limited to content
   CL: I'd like to have the option of bookmarking a
   POST (in safe case).
   DC: If safe, shouldn't have been a POST.
   CL: Where do you put the message body?
   TB: If too complex, existing GET machinery
   probably not enough. Use Post.
   CL: Bad to crunch message bodies into percents.
   DC, TB: Why?
   CL: No meaning of bytes in URI space (an
   internationalization issue).
   RF: In practice, the only problem is when the
   char encoding is transcoded at some point. The
   body no longer corresponds to the same octets the
   server had.
   CL: I disagree with that.
   TB summarizing: CL is objecting to the utility in
   the general case of doing GETs on URIs that have
   complex args due to I18N issue. Is that
   orthogonal to the main arch issue we are
   CL: No, since this is telling people to use
   something that's broken.

   I don't think anything's broken.

   TB: Two sides to this - if you push web to post
   space, you lose a lot of benefits (e.g.,
   application of crawlers, bookmarks, ...). Isn't a
   better solution to fix the I18N solution?
   CL: Yes.

   servers define the meaning of all URIs, not just
   ones with non-ascii form responses.

   CL: I still think kind of broken to
   percent-encode a document and stuff into a URI...
   DC: I can make same argument against pointy
   CL: My point is that if we do recommend something
   (such as using GET and putting message body in a
   URI), then we need to indicate corresponding
   drawbacks to the approach.
   DC: Do you agree with principle to use get for
   safe operations?
   CL: Yes, unless strong reasons to the contrary.
   TB: That's why it's "should".

   yeah, okay

   TB: I think DC's original document was sound, and
   that DC should incorporate suggested improvements
   from www-tag.
   RF: I'd like to refocus on the issue of "All
   important resources should have URIs."
   DO: Before getting closure here, how is this
   finding to be used? What is Web services to do
   with this?
   TB: Yes, I agree - some of our findings will be
   have a real impact on ongoing work. I think we
   need to be explicit about intended consequences
   when we publish findings.
   DC: I'd like SOAP primer to say "At this time we
   don't have GET, so for safe operations don't use
   TB: At our ftf meeting, we can discuss how to
   build findings and how to work with people to
   DC: The example used recently - Google API - you
   can use with GET or SOAP. See article by Paul
   Prescod at
   DC: I would like (SOAP) specs to be clear that
   SOAP is not expected to be used for GET-like
   operations (e.g., get the weather).
   CL: The document primarily talks about HTTP. And
   talks about GET (but not safe methods). It seems
   to me that one thing missing from finding -
   protocols should indicate their safe methods.
   DC: SOAP is not a w3c-defined vocab of methods.
   "Make your own"
   DC: There are bindings to transport protocols.
   CL: If you see a new protocol you haven't met
   before, you should have a mechanism for querying
   whether a method is safe.
   RF: E.g., include a label in envelope?
   CL: Yes, for example.
   CL: In short: move away from the word "GET" and
   use "safe" instead.
   DO: I put a proposal out that one of the ways to
   handle this for the TAG to issue a finding that
   hiding everything behind POST isn't sufficient,
   and the TAG would like something more Web-friend
   (URIs and GET) and we'd like the WSA WG to deal
   with this issue. The WSA WG has responsibility
   for glossary, examples, charters, etc. This is
   not part of charter for SOAP 1.2. We could ask
   WSA to make this a high priority for later

   Sounds mostly good, but the "merry path" should
   include some "NOTE: this is an issue SOAP 1.2
   doesn't address; stay tuned" stuff in the SOAP
   1.2 spec

   TB: I think that this is the best way forward in
   terms of process. However, I'm left with a grave
   concern for timing. What worries me is that huge
   amounts of info disappear behind POST. Damage
   will be done if SOAP 1.2 goes to Rec creating an
   all-POST environment for Web services.
   SW: People asking how to integrate GET. Responses
   have been "You could do that, but that wouldn't
   be very useful." The WG is working on the
   document. There is a small window of opportunity.
   CL: Problem is if SOAP 1.3 is produced with safe
   methods but SOAP 1.2 meets everyone's needs
   DO: Things the WSA WG will be interesting to the
   Web services community (e.g., reliable methods).
   Therefore, I think a next version of SOAP with
   cool features including safe methods will not get
   RF: In the IETF, the IESG can add a note at the
   beginning of the spec to say that additional work
   is going on to take care of issues a/b/c.

   Hmm... I don't think delaying SOAP 1.2 for this
   is the best idea, but the idea that stuff after
   SOAP 1.2 will get noticed... I wonder... there's
   a LOT of stuff being built now that cites SOAP

   TB: HTTP/1.1 has been slow to catch on.

   RF/CL disagree with TB about speed of HTTP/1.1

   DO: What does the TAG think the XMLP WG should do
   with SOAP 1.2. I'm strongly arguing that the WG
   should be able to make progress (as is).
   IJ: I think that TAG should provide comprehensive
   explanation of issue. Let larger community reach
   consensus as part of regular W3C process.
   TB: I think this is a problem that is not hard to
   solve technologically. Do some people think it's
   much harder than what I've described elsewhere
   (see comments on www-tag). This wouldn't cover
   all of SOAP (e.g., not N-space conversations).
   DO: How do RF and DC feel about this type of
   DC: It's good.

   As to the idea that this issue is coming in late,
   I notified the XMLP WG of this issue, via Yves,
   when they were drafting their requirements: See
   scenario R612.

   TB: Paul Prescod wrote an article about
   google - they published an API where there used
   to be a URI. The google result space vanishes
   from URI space as a result. Paul argues why the
   URI version was better for a lot of reasons.
   DO: I thought the article was well-written.
   DC: It would help me if DO said which way Google
   should have done it - it was done with GET and
   they switched. If there isn't agreement here that
   it was better done with GET, I don't know how to
   write the finding.
   DO: I think that GET could be used for some of
   the SOAP calls. I don't like raising the bar for
   using POST in general. But in the case of google,
   I think it's a fine usage of GET..


Ian Jacobs (
Tel:                     +1 718 260-9447

Received on Monday, 29 April 2002 17:42:34 UTC