W3C | TAG | Previous: 9 Jun teleconference | Next: 23 June 2003 teleconf

Minutes of 16 June 2003 TAG teleconference

Nearby: IRC log |Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll Call: All present - SW (Chair), TBL, TB, DO, DC, PC, RF, NW, CL, IJ (Scribe).
  2. Accepted minutes of 9 Jun teleconference
  3. Accepted this agenda
  4. Next meeting: 23 June
  5. Resolved face-to-face meeting scheduling details:
  6. Summer meeting planning; see request from Stuart

    SW: Please follow up on that thread.

  7. TAG partcipation in XML 2003? See email from Paul

    The TAG supports PC, CL, NW, TB and others participating on behalf of the TAG at the town hall.

1.1 AC feedback and TAG's last call plans

  1. Completed DO/PC: Send draft of AC announcement regarding TAG's last call expectations/thoughts to tag@w3.org.

The TAG received feedback from the W3C Advisory Committee in Budapest regarding advancing the Architecture Document to last call. DO and PC prepared a draft announcement for review by the TAG in response to that feedback.

Action PC: Propose a second draft to the TAG that has more "heads-up" information and less "last call" information.

The TAG envisions starting last call on the Architecture Document some time around the end of July or early August, through September.

2. Technical

2.1 Architecture document

The editor published the 16 June 2003 Editor's Draft of the Arch Doc (changes)

  1. Withdrawn action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design..
  2. Withdrawn action DO 2003/01/27: Please send writings regarding Web services to tag@w3.org. DO grants DC license to cut and paste and put into DC writing.
  3. Completed action DC 2003/03/17: : Write some text for interactions chapter of arch doc related to message passing, a dual of shared state. DC refers us to Conversations and State

    Action IJ: Attempt to incorporate relevant bits of "Conversations and State" into section to be produced by RF.

Actions from 2 June meeting:

  1. RF to rewrite section 5. Section 5 is expected to be short.
  2. TB to rewrite section 4 based on his proposal for rewriting section 4and suggestions from the TAG from 2 Jun teleconf. (Done)
  3. CL to make available a draft finding on content/presentation

    CL: Some progress..

  4. DO to update description of issue abstractComponentRefs-37

    DO: I got some feedback from RF; expect to have this by the end of the week.

    DC: Please include options for addressing the issue.

  5. SW: to continue work on and make available a draft finding related to the opacity of URIs.

    SW: No progress on second draft; I don't expect this week.

    The TAG noted the difference between (1) not making inferences by inspection of a generic URI and (2) well-defined semantics in specific cases (e.g., HTML form data that is part of a URI when the form is submitted).

  6. Completed action NW: Take a stab at proposed new 4.5, wherever it ends up (Done).
  7. DO: Write up a couple of paragraphs on extensibility for section 4.
  8. Completed action IJ: to start incorporating detailed suggestions on Arch Doc made by the TAG (see IRC log for details). See 16 June 2003 Editor's Draft of the Arch Doc.

Actions from 9 June meeting:

  1. Completed action IJ (see 16 June 2003 Editor's Draft of the Arch Doc)
    1. compare 3.2 text with RFC2396 version 3; compare and harmonize; leaving about the same amount of text.
    2. add a new 3.x section on allocating URIs; taking some text from rfc2396bis/3.2 and expanding slightly on social aspects.
    3. integrate RF's 3.5 into from RFC2396bis into arch doc section 3.3.
    4. See additional notes in minutes of 9 Jun teleconference

The Editor expects to publish another Editor's Draft on or around 20 June, including text from RF, CL, and NW. The TAG will review that draft to determine whether it should be the basis for the next "TR page" draft of the Arch Doc, probably the end of the week of 23 June.

2.2 Findings

See also: findings.

2.2.1 Client handling of MIME headers

[Ian]

On interactions with the Voice Browser WG

SW: We haven't heard back from Voice WG on this issue.

Action SW: Ping Voice WG.
DC: I'm not aware of additional discussions about the Voice spec within the Team.

On adding to the finding text saying server shouldn't guess information (e.g., charset).

CL: What about text saying "server shouldn't guess (e.g., charset) since the server could get it wrong."
DC: For protocol, you can't distinguish server from content creator.
CL: My point can still be made upstream.
Action IJ: Add this scenario to finding...(content knows what charset is; server shouldn't make it up)

On (1) authority of client headers sent to server and (2) connection between PUT and subsequent GET

TB: I think the draft is fine; questions are about missing pieces. I think the finding hits an 80/20 point.
IJ: What do we say (if anything) about authority of client headers sent to server? Is the principle symmetric?
DC: I think the principle doesn't apply in the direction client-to-server. When you post content, I think you are at the whim of the server.
RF: It's not that server is disregarding the client's instructions; it's just that it's using someone else's instructions (the server manager).
DC: In this case, the author has write access to the relevant directory (e.g., doing HTTP PUT). The author could thereby change the configuration of that directory.
TB: Somebody claimed that mod dav ignored media type when you put some content. That seems wrong to me.
RF: Mod dav doesn't ignore. The process that responds to GET and the one that responds to PUT are different; both are subject to editing.
CL: Sounds like the representation that you put and the one that you get are different.
DC: It would be nice if the PUT handler looked at the mime handler and copied to the right place so the get handler would see it.
[Chris]
like jigsaw webdav does, for example?
[Ian]
RF: The idea of keeping the content type on the server between requests is not a principle. The principle should be that the server should recognize and properly interpret the content type.
[Chris]
apache webdav treats put same as ftp
[Ian]
TB summarizing: It sounds like default mod dav behavior is to ignore content type information that's being sent. But that doesn't sound like it's violating an architectural principle.
RF: The two requests (PUT and GET) are independent.
TB: But it seems like ignoring content type by default is a bad idea.
RF: Yes.
RF, DC: This is a quality of implementation issue, not an arch issue.
DC: There's a different rationale for saying that the PUT/GET agree (principle of least surprise)
TB: Seems like something questionable about media type being discarded without being looked at.
TBL: PUT makes same assurance that publisher would make; that distinguishes PUT from POST.
[timbl]
In PUT, the putter is telling the server that the given tghing is a valid representation of the resource.
[Ian]
TB: I agree with TBL, but I think that PUT with a particular mime type does not imply that next GET will be of that mime type.
[DanC]
In particular, the W3C server mangles the $Id: 16-tag-summary.html,v 1.2 2003/06/17 19:27:14 ijacobs Exp $ keywords and such between PUT and GET
[Zakim]
Chris, you wanted to re-argue about resources
[Ian]
CL: Suppose I put something and there are server side includes, etc. What I GET back could be quite different.
SW: If I were to put a picture (TIF) on the server and the server generated JPEG/PNG from it....
[DanC]
I'd expect to PUT to doc.html-source rather than doc.html
[Ian]
IJ: I am hearing 2 distinct comments (1) ignoring client's mime type v. (2) disjoint PUTs and GETs
RF: Problem boils down to minimizing the amount of magic on the server.
[DanC]
(I note that we had, and still have, the opportunity to observe that there's a large degree of consensus around the 5May draft and decide that we've reached the point of diminishing returns and put a fork in it.)
[Chris]
not ignoring, but it the resource changes between put and get, then the media type is not the same
[Ian]
RF: Generally in an HTTP interaction, we'd prefer that there be different URIs between what is put and what is gotten. Put to most specific URI. Difficulty with this issue in modern times is that apps that send PUT requests don't send mime type or don't send proper mime type.
[Chris]
put on most specific uri and get from coneg uri which might be different
[Ian]
TB: Clearly it's hard to get mad at someone for self-defense in the face of broken clients. But documents that look like html might be served as application/xhtml+xml very legitimately. The whole notion of the default behavior of getting the media type from the extension is becoming less and less useful. I think it's architecturally broken if a server throws my headers on the ground.
TBL: In principle, if you're editing files on an Apache server, and you've got different variations (e.g., PNGs, SVGs) it's reasonable to edit specific ones. However, if you are browsing the Web, you will encounter the generic URIs. When people want to edit (based on generic URI) and save it back, the system uses the etag and other sophistication to be able to distinguish generic thing that is read, and the specific thing originally gotten. The goal is that the specific one viewed can be overwritten. The client shouldn't have to model what's going on inside the server.
[DanC]
(the question of whether and edit to foo should be PUT to foo or to foo.html is one of the longest-running team internal threads among the W3C team, I note, without permission)
[Ian]
RF: Then you are putting the metadata that was part of the request part of the URI for putting.
[DanC]
(I note that we had, and still have, the opportunity to observe that there's a large degree of consensus around the 5May draft and decide that we've reached the point of diminishing returns and put a fork in it.)
[Zakim]
DanC, you wanted to suggest we say "good question; but it's a different question; do you mind if we queue that one on the issue list while we finish this one?"
[Ian]
DC: My preference is to add this to the issues list.
TB: I agree with DC - note the PUT issue and move forward without it in the draft finding.
[timbl]
makes sense to me
[DanC]
putMediaType or some such
[Ian]
Resolved: New issue putMediaType
1) PUT relation to GET is general issue
2) Specific issue is how client header is authoritative

Action IJ: Add new issue to issues list.

3. Not discussed

Action IJ 2003/06/09: Turn TB apple story into a finding.
IJ: No progress.

3.1 New issues?

Summary from Stuart

3.2 Issues that have associated action items

4. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/06/17 19:27:14 $