IRC log of tagmem on 2003-06-16

Timestamps are in UTC.

18:01:30 [RRSAgent]
RRSAgent has joined #tagmem
18:13:51 [timbl]
timbl has joined #tagmem
18:52:19 [Norm]
Norm has joined #tagmem
18:54:24 [Stuart]
Stuart has joined #tagmem
18:54:47 [Stuart]
Stuart has changed the topic to: http://www.w3.org/2003/06/16-tag
18:58:36 [timbl]
Good evening, Stuart
18:59:01 [Chris]
Chris has joined #tagmem
18:59:04 [Stuart]
Hello... and good aftrenoon Tim.
18:59:16 [DanC]
DanC has joined #tagmem
18:59:59 [timbl]
zakim, this is tag
18:59:59 [Zakim]
ok, timbl
19:00:11 [timbl]
Zakim, who is here?
19:00:11 [Zakim]
On the phone I see ??P0, TimBL, Norm
19:00:12 [Zakim]
On IRC I see DanC, Chris, Stuart, Norm, timbl, RRSAgent, Zakim, Ian
19:00:15 [Ian]
zakim, call Ian-BOS
19:00:16 [Zakim]
ok, Ian; the call is being made
19:00:17 [Zakim]
+Ian
19:00:39 [Zakim]
+ +1.334.933.aaaa
19:00:55 [timbl]
Zakim, +1.334.933.aaaa is Chris
19:00:55 [Zakim]
+Chris; got it
19:01:19 [TBray]
TBray has joined #tagmem
19:01:26 [timbl]
Zakim, where is area code +1 334?
19:01:26 [Zakim]
I don't understand your question, timbl.
19:01:29 [Zakim]
+??P4
19:01:36 [Chris]
can people hear me okay?
19:01:39 [Ian]
Roll call: TBL, IJ, Chris, Norm, Paul, Stuart
19:01:40 [Stuart]
zakim, ??p4 is me
19:01:40 [Zakim]
+Stuart; got it
19:01:44 [timbl]
Zakim, ??P4 is Stuart
19:01:44 [Zakim]
sorry, timbl, I do not recognize a party named '??P4'
19:02:07 [Zakim]
+Tim_Bray
19:02:14 [Stuart]
zakim, who is here?
19:02:14 [Zakim]
On the phone I see ??P0, TimBL, Norm, Ian, Chris, Stuart, Tim_Bray
19:02:15 [Zakim]
On IRC I see TBray, DanC, Chris, Stuart, Norm, timbl, RRSAgent, Zakim, Ian
19:02:26 [Ian]
zakim, ??P0 is Paul
19:02:26 [Zakim]
+Paul; got it
19:02:40 [Zakim]
+??P6
19:02:51 [Ian]
zakim, ??P6 is Roy
19:02:51 [Zakim]
+Roy; got it
19:03:03 [Stuart]
zakim, who is here?
19:03:03 [Zakim]
On the phone I see Paul, TimBL, Norm, Ian, Chris, Stuart, Tim_Bray, Roy
19:03:05 [Zakim]
On IRC I see TBray, DanC, Chris, Stuart, Norm, timbl, RRSAgent, Zakim, Ian
19:03:36 [Ian]
# Accept minutes of 9 Jun teleconference?
19:03:44 [Ian]
http://www.w3.org/2003/06/09-tag-summary.html
19:04:03 [Ian]
RF: Look fine
19:04:11 [Ian]
Resolved: Accepted 9 Jun minutes.
19:04:19 [Ian]
# Accept this agenda?
19:04:26 [Ian]
http://www.w3.org/2003/06/16-tag.html
19:04:54 [Zakim]
+DanC
19:05:23 [Ian]
[No additions to agenda]
19:05:31 [Ian]
Next meeting: 23 June
19:05:56 [Ian]
Regrets: RF, TBL, likely PC
19:05:57 [timbl]
I will be out of town
19:06:23 [Ian]
# Face-to-face meeting scheduling details
19:06:33 [Zakim]
+David_Orchard
19:06:50 [Ian]
Meeting page: http://www.w3.org/2003/07/21-tag-agenda
19:07:29 [Ian]
Proposed to start at 1pm on 21 July, with a proposal to have lunch before at 12pm
19:07:49 [Chris]
propose meeting outside schemasoft at 12 noon for lunch
19:08:00 [TBray]
I will send lunch invite with location near meeting
19:08:19 [Chris]
thanks
19:08:19 [DanC]
3p ok
19:08:25 [Ian]
Proposal to end 23 July at 15h
19:08:30 [Chris]
3pm is fine for me too
19:08:31 [Ian]
3p ok by me
19:09:39 [Ian]
Seems like substantial agreement to end at 3pm at the latest
19:09:46 [Ian]
--
19:09:52 [Ian]
# Summer meeting planning; see request from Stuart
19:09:59 [Ian]
http://lists.w3.org/Archives/Member/tag/2003Jun/0048.html
19:10:41 [TBray]
If I'm at work as opposed to vacation TAG is refreshing break
19:13:13 [Ian]
----
19:13:21 [Ian]
7. TAG partcipation in XML 2003? See email from Paul
19:13:33 [Ian]
http://lists.w3.org/Archives/Member/tag/2003Jun/0027.html
19:13:47 [Ian]
CL: I'm likely to be at XML 2003
19:13:54 [Ian]
PC: NW and PC will be there, too
19:14:05 [Ian]
[Proposal for TAG presence at town hall]
19:14:08 [TBray]
I'll be there and have (tee-hee) no speaking engagements; delighted to pitch in
19:14:11 [DanC]
Connolly is likely to be in Montreal for ExML
19:14:55 [Ian]
Resolved: TAG supports PC org of TAG presence at XML 2003 town hall
19:14:58 [Stuart]
http://www.w3.org/2003/06/16-tag
19:15:54 [Ian]
http://lists.w3.org/Archives/Member/tag/2003Jun/0062.html
19:16:00 [Stuart]
q?
19:16:05 [Stuart]
q+ PC
19:16:13 [Ian]
DO: I based draft on existing last calls.
19:16:48 [TBray]
pointer to DO's note?
19:16:55 [Stuart]
http://www.w3.org/2003/06/16-tag
19:16:56 [Chris]
q+
19:16:56 [TBray]
oh there it is
19:17:04 [Ian]
http://lists.w3.org/Archives/Member/tag/2003Jun/0062.html
19:18:07 [DanC]
ack danc
19:18:08 [Zakim]
DanC, you wanted to say I thought the idea was to contact the AC before last call
19:18:35 [Ian]
DC: I thought we were just going to contact the AC in advance of a last call. I was surprised that DO/PC action take the form of a last call.
19:18:52 [Ian]
DC: I prefer that we just write to them and say "We thought about advice, think we should do something else" before doing it.
19:18:57 [Stuart]
ack PC
19:19:32 [Ian]
PC: I think we need some kind of doc that we can send to AC forum that is early warning on last call.
19:19:52 [TBray]
q+
19:19:55 [Stuart]
q+
19:20:24 [Ian]
[PC additional comments on what would constitute a last call announcement]
19:20:35 [Zakim]
+DOrchard
19:20:36 [Zakim]
-David_Orchard
19:20:40 [Ian]
PC: I think I agree with DC to modify proposed text and make it advance notice to AC.
19:20:45 [Stuart]
ack Chris
19:21:09 [Ian]
CL: I agree with PC for the most part. I like the way that DO has phrased this in terms "We believe we have not precluded..."
19:22:28 [Stuart]
ack TBray
19:22:28 [timbl]
q+ to mention people that *have* reviewed it
19:23:07 [Ian]
TB: one specific suggestion in penultimate para re: sem web/web services. I think we should say "The TAG believes that it is possible to publish version 1.0 of the Web
19:23:07 [Ian]
Architecture document...without precluding future work..."
19:23:10 [Chris]
normally LC review targets specific wg for review; by its nature this will need wider review
19:23:38 [Ian]
SW: Question of securing review commitments.
19:23:39 [Chris]
verion 1 is better than part 1' implies changesand additions still possible on existing stuff
19:23:51 [Ian]
PC: Look in our charter. Our charter mentions other horz arch groups.
19:24:01 [Ian]
PC: Also look at issues list from various groups.
19:24:13 [DaveO]
DaveO has joined #tagmem
19:24:19 [Ian]
PC: WSDL, XMLP, WSA, I18N, ...
19:24:33 [DaveO]
q?
19:24:35 [DaveO]
q+
19:24:46 [Stuart]
ack Stuart
19:24:48 [TBray]
slackers
19:25:01 [Chris]
last call also typically involves negotiation of how long the last call lasts, with specific WG chairs
19:25:30 [Ian]
TBL: Is it worth saying that for each issue we've dealt with, we've had review from specific groups?
19:25:39 [Chris]
review, yes
19:25:46 [Ian]
TBL: Not sure we can claim that we've had lots of review from other groups prior to last call.
19:25:53 [Ian]
TBL: Can we say that we've satisfied people we've talked to?
19:25:55 [Ian]
DC: I think so.
19:26:17 [DaveO]
xml core..
19:26:21 [Ian]
DC: We may not have done a full round trip. But for the issues we've addressed, we think we've been responsive to them.
19:26:31 [DaveO]
q?
19:27:06 [Ian]
q?
19:27:17 [Chris]
propose we slightly rewrite to be a 'heads up for last call' announcement
19:27:27 [Chris]
and send to chairs and ac
19:27:30 [Stuart]
ack timbl
19:27:30 [Zakim]
timbl, you wanted to mention people that *have* reviewed it
19:27:38 [Ian]
Action PC: Based on DO's draft, write a proposal for a heads-up to the AC.
19:27:42 [Ian]
ack DaveO
19:28:14 [Ian]
DO: I thought AC (and their delegates) would be primary audience for this review.
19:29:10 [DaveO]
q+
19:29:11 [Ian]
TB: I agree, it will be tough to find particular WGs.
19:29:14 [Ian]
DC: I disagree.
19:29:27 [Ian]
DC: We have specific enough issues to talk to specific groups.
19:29:40 [Ian]
DC: I think that asking the AC would be like asking "anyone".
19:29:47 [Ian]
DC: I wouldn't expect much of a result.
19:30:10 [Ian]
DC: I would think that we could ask groups that raised/are affected by issues.
19:30:14 [TBray]
Seems like a lot of work
19:30:45 [DanC]
well, if we find 3 to 5 specific reviewers, that should be sufficient.
19:30:50 [Ian]
PC: Time frame?
19:31:16 [DanC]
July 43rd
19:31:34 [Ian]
Estimate: End of July, into September.
19:32:34 [Ian]
Estimate: Early August (depending on how many changes at ftf meeting)
19:32:36 [DaveO]
q+
19:32:41 [DanC]
timeframe: ftf ~22-23 July. Then last call small number of weeks later. last call ~July 43rd. then reviews due end of Sep
19:32:41 [Zakim]
-Paul
19:33:01 [DanC]
ack daveo
19:33:02 [Ian]
ack DaveO
19:33:32 [Ian]
DO: This timing means that we should use ftf to close what's necessary before last call.
19:34:11 [DaveO]
Paul and DaveO own the action item to draft the message to the AC.
19:34:21 [Ian]
------------------
19:34:31 [Ian]
New editor's draft:
19:34:39 [Ian]
http://www.w3.org/2001/tag/2003/webarch-20030616
19:35:19 [Ian]
Editor's Draft 16 June 2003
19:37:39 [DanC]
http://www.w3.org/2001/tag/webarch/changes is what I was looking for, thx
19:38:15 [Ian]
Action item review:
19:38:22 [Ian]
1. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design. DC requests to withdraw this one.
19:38:59 [Ian]
Action withdrawn. DC feels that a lot is already said in get7 finding.
19:39:09 [Ian]
# 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.
19:39:58 [Zakim]
+??P0
19:40:10 [Zakim]
-Roy
19:40:16 [Ian]
DO: Please withdraw. I still expect to do this at some point.
19:40:39 [Ian]
DC: DO has a chance to set expectations that we can deal with this story in this last call draft...
19:41:09 [Ian]
DO: Would discussion of rest v. non-rest slow us down?
19:41:30 [Ian]
DC: Perhaps. It would be responsive to people and also would be challenging to get it in before last call.
19:41:44 [Ian]
DO: I think issue 37 is higher priority than this.
19:41:58 [Ian]
SW: I will ask DO from time-to-time about this.
19:41:59 [Roy]
Roy has joined #tagmem
19:42:05 [Ian]
Action withdrawn.
19:42:19 [Ian]
1.
19:42:19 [Ian]
3. 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
19:42:33 [Ian]
http://www.w3.org/DesignIssues/Conversations
19:42:40 [Ian]
SW: Is this subsumed by RF's action?
19:43:09 [Ian]
RF: I don't think I would talk about this topic in first draft of section on interactions.
19:43:58 [Ian]
DC: If IJ can integrate "Conversations and State" to RF's text, that'd be great.
19:44:03 [Ian]
Action item closed for DC.
19:44:33 [Ian]
Action IJ: Integrate "Conversations and State" to RF's new text on interactions
19:44:56 [Ian]
1. RF to rewrite section 4 (interactions). Section 4 is expected to be short.
19:45:02 [Ian]
RF: I hope to have some text by Weds evening.
19:45:57 [Ian]
Action CL: Make available a draft finding on content/presentation.
19:46:00 [Ian]
CL: Some progress...
19:47:59 [DanC]
+1 to what bray's saying
19:48:00 [Ian]
TB: I'd encourage CL to publish draft finding sooner rather than later.
19:48:10 [Chris]
okay
19:48:15 [Ian]
Action DO: Update description of issue abstractComponentRefs-37
19:48:37 [Ian]
DO: Got some feedback from RF; I hope to have done by end of this week.
19:48:51 [Ian]
DC: Will it include proposals for addressing?
19:49:26 [Ian]
DO: There should be enough info to help us choose.
19:49:42 [DanC]
it'll help me if the minutes say something about "including options for addressing the issue" in DO's action
19:49:56 [Ian]
Action SW: Continue work on and make available a draft finding related to the opacity of URIs.
19:50:11 [Ian]
SW: I haven't made progress on second draft yet; I don't expect to this week.
19:50:25 [Ian]
DO: Note relation between SW's finding and issue 37
19:50:53 [Ian]
CL: I think these questions are different: (1) in general, given a random URI, can one deduce metadata v. (2) for specific purposes, can this be done?
19:51:24 [DanC]
it can be very challenging/subtle to not get confused. [Chris makes a good point]
19:51:45 [Ian]
[CL's point is that SW's finding addresses a slightly different question.]
19:52:20 [Ian]
CL: It's not a good idea to infer metadata from a URI. It's fine for specification X to say "We use URIs here in the following way..."
19:52:47 [Ian]
DC: This is about not taking choices away from people.
19:53:09 [Ian]
DC: People who conclude that ".html" on URI means that representation will be in HTML, those people have taken away a choice from the server manager.
19:53:15 [timbl]
q+ to point out that the HTML form protocol, for example, involves defining the semantics of a URI, and in a useful way.
19:53:36 [Ian]
SW: The finding points out 2 perspectives - person who assigns URI v. person who uses URI
19:54:10 [Ian]
DO: There is an explicit dependency between 32 and 37 as 32 is currently worded.
19:54:51 [Ian]
q?
19:54:57 [Ian]
ack timbl
19:54:57 [Zakim]
timbl, you wanted to point out that the HTML form protocol, for example, involves defining the semantics of a URI, and in a useful way.
19:55:48 [Ian]
TBL: HTML 4 form protocol is another case where semantics of URI is defined.
19:55:55 [Ian]
# NW: Take a stab at proposed new 4.5, wherever it ends up.
19:56:09 [Ian]
Done http://lists.w3.org/Archives/Public/www-tag/2003Jun/0042.html
19:56:24 [Ian]
Action DO: Write up a couple of paragraphs on extensibility for section 3
19:56:34 [Ian]
[Pending]
19:56:43 [Ian]
8. IJ: to start incorporating detailed suggestions on Arch Doc made by the TAG (see IRC log for details)
19:56:51 [Norm]
Norm's action item is completed at http://lists.w3.org/Archives/Public/www-tag/2003Jun/0042.html
19:57:04 [Ian]
Done: http://www.w3.org/2001/tag/2003/webarch-20030616
19:57:22 [Ian]
IJ did remaining actions from 9 June meeting
19:57:28 [Ian]
2. DO/PC: Send draft of AC announcement regarding TAG's last call expectations/thoughts to tag@w3.org.
19:57:30 [Ian]
[Done]
19:58:04 [Ian]
DC: IJ spun 16 June draft. Has lots of stuff from previous 2 meetings.
19:58:31 [Ian]
DC: But doesn't have pieces from CL, DO, NW (done)
19:59:07 [Ian]
IJ: I can try to have a draft this friday with text from NW and RF.
19:59:17 [Ian]
DO: I think I can make a deadline of this Friday.
20:00:14 [Ian]
IJ: I am happy to request publication of WD next week after 23 June teleconf
20:01:03 [Ian]
Action IJ: Send email to SW asking for review of specific pieces of section 2
20:01:07 [Ian]
----
20:01:08 [DanC]
hmm... I wonder if roy's text won't have impact throughout
20:01:12 [Ian]
Findings
20:01:23 [Ian]
Next steps on:
20:01:36 [Ian]
1) * Client handling of MIME headers; see summary of comments.
20:01:43 [Ian]
http://www.w3.org/2001/tag/doc/mime-respect.html
20:01:49 [Ian]
http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
20:02:28 [DanC]
(I can't remember the status as of the 5May draft...)
20:02:29 [Ian]
SW: Also, we haven't heard back from Voice WG.
20:02:42 [Ian]
Action SW: Ping Voice WG.
20:03:07 [Ian]
DC: I'm not aware of additional discussions.
20:06:24 [Ian]
CL: What about text saying "server shouldn't guess (e.g., charset) since the server could get it wrong."
20:06:34 [Ian]
DC: For protocol, you can't distinguish server from content creator.
20:06:59 [Ian]
CL: My point can still be made upstream.
20:07:33 [Ian]
Action IJ: Add this scenario to finding...(content knows what charset is; server shouldn't make it up)
20:07:43 [Ian]
TB: I think the draft is fine; questions are about missing pieces.
20:07:59 [Ian]
TB: I think the finding hits an 80/20 point.
20:09:40 [Ian]
Does the principle apply to those headers from client to server?
20:09:55 [Ian]
IJ: What do we say about authority of headers in that direction?
20:10:23 [Ian]
DC: I think the principle doesn't apply in the direction client-to-server.
20:10:31 [Ian]
DC: When you post content, I think you are at the whim of the server.
20:10:57 [Ian]
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).
20:11:37 [Chris]
no, my point is not in the 1..7 list
20:11:52 [Ian]
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.
20:12:08 [Ian]
TB: Somebody claimed that mod dav ignored media type when you put some content.
20:12:11 [Ian]
TB: That seems wrong to me.
20:12:37 [Ian]
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.
20:12:56 [Ian]
CL: Sounds like the representation that you put and the one that you get are different.
20:13:12 [Ian]
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.
20:13:28 [Chris]
like jigsaw webdav does, for example?
20:13:55 [Ian]
RF: The idea of keeping the content type on the server between requests is not a principle.
20:14:08 [Ian]
RF: The principle should be that the server shoudl recognize and properly interpret the content type.
20:14:42 [Chris]
apache webdav treats put same as ftp
20:14:56 [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.
20:15:08 [Ian]
RF: The two requests (PUT and GET) are independent.
20:15:14 [Chris]
q+ to re-argue about resources
20:15:25 [Ian]
TB: But it seems like ignoring content type by default is a bad idea.
20:15:28 [Ian]
RF: Yes.
20:15:37 [Ian]
RF, DC: This is a quality of implementation issue, not an arch issue.
20:16:15 [Ian]
DC: There's a different rationale for saying that the PUT/GET agree (principle of least surprise)
20:16:34 [Ian]
TB: Seems like something questionable about media type being discarded without being looked at.
20:17:17 [Stuart]
q+
20:17:41 [Ian]
TBL: PUT makes same assurance that publisher would make; that distinguishes PUT from POST.
20:17:55 [timbl]
In PUT, the putter is telling the server that the given tghing is a valid representation of the resource.
20:18:08 [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.
20:18:10 [DanC]
in particular, the W3C server magles the $Id$ keywords and such between PUT and GET
20:18:19 [Ian]
ack Chris
20:18:19 [Zakim]
Chris, you wanted to re-argue about resources
20:18:28 [Ian]
CL: Suppose I put something and there are server side includes, etc.
20:18:36 [Ian]
CL: What I GET back could be quite different.
20:18:41 [Roy]
q+
20:18:49 [Ian]
ack Stuart
20:19:12 [Ian]
SW: If I were to put a picture (TIF) on the server and the server generated JPEG/PNG from it....
20:19:19 [DanC]
I'd expect to PUT to doc.html-source rather than doc.html
20:19:20 [TBray]
q+
20:19:59 [Ian]
I am hearing 2 distinct comments (1) ignoring client's mime type v. (2) disjoint PUTs and GETs
20:20:01 [Ian]
ack Roy
20:20:17 [Ian]
RF: Problem boils down to minimizing the amount of magic on the server.
20:20:35 [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.)
20:20:35 [Chris]
not ignoring, but it the resource changes between put and get, then the media type is not the same
20:20:45 [Ian]
RF: Generally in an HTTP interaction, we'd prefer that there be different URIs between what is put and what is gotten.
20:20:55 [Ian]
RF: Put to most specific URI.
20:21:14 [timbl]
q+
20:21:15 [Ian]
RF: 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.
20:21:17 [Chris]
put on most specific uri and get from coneg uri which might be different
20:21:28 [Ian]
ack TBray
20:21:42 [Ian]
TB: Clearly it's hard to get mad at someone for self-defense in the face of broken clients.
20:22:03 [Ian]
TB: But documents that look like html might be served as application/xhtml+xml very legitimately.
20:22:32 [Ian]
TB: The whole notion of the default behavior of getting the media type from the extension is becoming less and less useful.
20:23:17 [Ian]
TB: I think it's architecturally broken if a server throws my headers on the ground.
20:23:18 [Stuart]
q?
20:23:21 [Ian]
ack timbl
20:23:48 [Ian]
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.
20:25:07 [Ian]
TBL: 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.
20:25:31 [Ian]
TBL: 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.
20:25:42 [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)
20:25:53 [Ian]
RF: Then you are putting the metadata that was part of the request part of the URI for putting.
20:26:16 [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.)
20:28:14 [Ian]
ack DanC
20:28:14 [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?"
20:28:18 [Zakim]
+TimBL.a
20:28:25 [Ian]
DC: My preference is to add this to the issues list.
20:28:25 [Zakim]
-TimBL
20:28:39 [TBray]
Hi Stuart
20:30:00 [Ian]
TB: I agree with DC - note the PUT issue and move forward without it in the draft finding.
20:30:08 [timbl]
makes sense to me
20:30:31 [DanC]
putMediaType or some such
20:30:53 [Ian]
Resolved: New issue putMediaType
20:31:49 [Ian]
1) PUT relation to GET is general issue
20:31:59 [Ian]
2) Specific issue is how client header is authoritative
20:32:13 [Ian]
Action IJ: Add new issue to issues list.
20:32:58 [Ian]
ADJOURNED
20:33:00 [Zakim]
-Tim_Bray
20:33:05 [Roy]
Roy has left #tagmem
20:33:05 [Zakim]
-Norm
20:33:06 [Zakim]
-DanC
20:33:07 [Zakim]
-DOrchard
20:33:08 [Ian]
RRSAgent, stop