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 meeting]
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, Scribe)

Regrets: Tim Berners-Lee, Paul Cotton

Agenda

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

Closed:

Open:

Making progress on architecture document

[Ian]
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 languish.
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 projects.
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?"

[Ian]
NW: With respect to: "What does a document mean?": My efforts petered out since I haven't heard consensus of opinion on some pieces.
[DanCon]
I'm quite happy with folks writing their own opinion and asking if other folks agree, Norm.
[Ian]
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.
[DanCon]
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 (Member-only).

[Ian]
RF: Covers character requirements for every protocol. It's architectural in that it touches everyone.
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.
[DanCon]
I don't agree with the summary that Chris just gave.
[Ian]
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 practice.
It will be very good that all this is gathered into one place. Normalization stuff is contentious but has benefits.
[DanCon]
I sure wish they'd split the document. Hmm... I wonder if I asked them for that in so many words.
[Ian]
CL: I with they'd split it up, too. I recommend that the TAG review this document.
[DanCon]
I 2nd the request to review
[Ian]
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 reviews.
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.
[Chris]
Last Call period begins 30 April 2002 and ends 31 May 2002.
[DanCon]
hmm... TAG to finish its charmod review by 31 May? I doubt it.

New issue: Qnames as IDs

Refer to question from Joseph Reagle

[Ian]
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 another.
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?
[DanCon]
I gather Tim Bray's argument can now be summarized as 'I told you so.'
[Ian]
TB: A qname is a prefix plus a string of characters.
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.
[DanCon]
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.
[Ian]
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 qnames.
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.
[Ian]
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.
[DanCon]
ooh, TimBray, I'm interested in clues on choosing which mozilla to use on a mac
[Ian]
DC: I move we accept this draft.
RF: I agree with SW comments (on [email protected])
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 (s/resource/response).
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 offline.
Homework: review this finding for next meeting.

TAG ftf meeting agenda

[Ian]
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 whenToUseGet-7.
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).
[DanCon]
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.
[Ian]
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 agenda.

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

[Ian]
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.
[DanCon]
(already a REC *and* widely read and understood; unfortunately we can't publish directly into developer's minds)
[Norm]
What Chris said, +100 :-)
[Ian]
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 two.
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 ready.

Status of finding on When to use Get?

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

[Ian]
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 rules.
RF: It isn't necessary to be limited to content location.
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 discussing?
CL: No, since this is telling people to use something that's broken.
[DanCon]
I don't think anything's broken.
[Ian]
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.
[DanCon]
servers define the meaning of all URIs, not just ones with non-ascii form responses.
[Ian]
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 brackets...
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".
[Chris]
yeah, okay
[Ian]
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 SOAP."
TB: At our ftf meeting, we can discuss how to build findings and how to work with people to incorporate.
DC: The example used recently - Google API - you can use with GET or SOAP. See article by Paul Prescod at xml.com.
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 versions.
[DanCon]
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
[Ian]
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 adequately.
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 lost.
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.
[DanCon]
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 1.1.
[Ian]
TB: HTTP/1.1 has been slow to catch on.
[DanCon]
RF/CL disagree with TB about speed of HTTP/1.1
[Ian]
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 solution.
DC: It's good.
[DanCon]
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.
[Ian]
TB: Paul Prescod wrote an xml.com 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..
Adjourned