IRC log of tagmem on 2002-04-08

Timestamps are in UTC.

14:32:17 [TimBL]
Agenda+ Meetings when TimBL is trvelling
14:32:46 [ian_]
TBL: Absent 22, 29 April
14:33:08 [TimBL]
Zakim, who is here?
14:33:09 [Zakim]
I see TimBL, Ian, PCotton
14:33:31 [Chris]
Chris has joined #tagmem
14:33:42 [Chris]
be right therte ... dialing now ....
14:35:06 [DanC]
DanC has joined #tagmem
14:35:33 [PaulC]
Paul will likely be absent on Apr 29 as well.
14:35:47 [Zakim]
+??P12
14:35:57 [ian_]
zakim, ??P12 is Roy
14:35:58 [Zakim]
+Roy; got it
14:36:49 [Zakim]
+DanC
14:36:58 [TimBL]
Zakim, who is here?
14:36:59 [Zakim]
I see TimBL, Ian, PCotton, Roy, DanC
14:37:09 [Zakim]
+??P14
14:37:25 [Chris]
Zakim, ??P14 is chris
14:37:26 [ian_]
zakim, ??P14 is Chris
14:37:26 [Zakim]
+Chris; got it
14:37:27 [Zakim]
sorry, ian_, I do not recognize a party named '??P14'
14:37:42 [ian_]
;)
14:37:48 [ian_]
---------------
14:37:48 [Roy]
Roy has joined #tagmem
14:37:52 [ian_]
----------
14:37:56 [Stuart]
Stuart has joined #tagmem
14:38:00 [DanC]
1Apr http://www.w3.org/2002/04/01-tag-summary
14:38:05 [ian_]
TBL: No problems with previous minutes.
14:38:12 [Stuart]
Sorry... network problems
14:38:15 [ian_]
TBL: Any comments on agenda?
14:38:37 [ian_]
PC: General item - how much technical work should the TAG work be doing, rather than architecture?
14:38:41 [Roy]
Okay with minutes
14:39:12 [ian_]
PC: It's one thing to decide that there should be a namespace document; it's another matter to decide what it should look like. Should we be doing this design work?
14:39:38 [Zakim]
+??P1
14:39:46 [ian_]
TBL: Agenda - who to chair when I'm on the road?
14:39:53 [ian_]
zakim, +??P1 is Stuart
14:39:54 [Zakim]
sorry, ian_, I do not recognize a party named '+??P1'
14:40:00 [ian_]
zakim, ??P1 is Stuart
14:40:01 [Zakim]
+Stuart; got it
14:40:06 [ian_]
zakim, who is here?
14:40:07 [Zakim]
I see TimBL, Ian, PCotton, Roy, DanC, Chris, Stuart
14:40:39 [ian_]
TBL: A draft heading to current best practice (in IETF) is about to be published. The writer says that IETF URNs should be mandated for XML namespaces in IETF documents.
14:40:54 [ian_]
TBL: I'd like that on the agenda as well.
14:40:55 [ian_]
-----------------------
14:40:59 [ian_]
Action item review:
14:41:15 [ian_]
Agenda: http://www.w3.org/2002/04/08-tag.html
14:41:43 [ian_]
Action DO: Write text about "Web as information space", to be integrated by IJ.
14:41:54 [ian_]
PC: DO has tried two cuts, not satisfied with either. I think it's still pending.
14:42:05 [ian_]
TBL: No state change since DO not here.
14:42:15 [ian_]
Action IJ: Integrate/combine one-page summarie
14:42:40 [ian_]
Status - started: http://www.w3.org/2001/tag/2002/0330-intro
14:42:42 [DanC]
seems to be about 1/5th done
14:43:33 [ian_]
IJ: My understanding from DC discussion was that this was to be the arch document.
14:44:06 [ian_]
IJ: Is this to be the doc, or to be fleshed out?
14:44:19 [ian_]
TBL: I would imagine this is to be carried forward. Yes, this is the oen thing.
14:44:21 [ian_]
s/oen/one/
14:45:05 [ian_]
SW: Revise findings on uriMediaType-9, incorporating 25 Mar discussion points.
14:45:13 [ian_]
SW: I'm interested in getting more feedback on this.
14:45:15 [DanC]
much better: $Date: 2002/04/05 17:05:38 $ http://www.w3.org/2001/tag/2002/01-uriMediaType-9
14:46:06 [ian_]
TBL: Take question of HTTP Query to W3C/IETF liaison (issue whenToUseGet-7)
14:46:10 [ian_]
TBL: Still waiting for ack.
14:46:24 [ian_]
DC: Next call is on the order of about 3 months from now.
14:46:31 [ian_]
TBL: I'd like to leave this one as pending.
14:46:38 [ian_]
...maybe shorter term IETF call required.
14:47:02 [ian_]
TB: Extract issues for TAG from thread on boundaries for the Web (DONE)
14:47:11 [ian_]
IJ: Add URIEquivalence-15 and HTTPSubstrate-16 to issues list (DONE)
14:47:20 [ian_]
TBL: Write draft on when URI variants are considered equivalent (URIEquivalence-15)
14:47:29 [ian_]
TBL: Not done.
14:47:39 [ian_]
TBL/IJ: Find someone in W3C Team or RDF world to draft comments on RDF+HTML for namespace documents
14:48:05 [ian_]
CL: I have some comments on that - I'm concerned since we have two Recommendations (XHTML, XLink) and we're not recommending their use.
14:48:10 [ian_]
TBL: RDF is also a Recommendation.
14:48:47 [ian_]
agenda+ Recommending RDF+HTML for namespace docs
14:49:06 [ian_]
RF: Start discussion on www-tag about criticism of RFC3025 (HTTPSubstrate-16) (DONE)
14:49:47 [ian_]
RF: Now, the action should be to write up the results of the discussion.
14:49:59 [ian_]
RF: Not sure whether this is a finding or a discussion document?
14:50:14 [ian_]
SW: Summary v. opinion piece.
14:50:34 [ian_]
Action RF: Write up the discussion on critique of RFC3205
14:50:40 [DanC]
about when do you expect to have such a write-up, Roy?
14:50:47 [ian_]
RF: There will likely be discussion after I write first draft.
14:51:09 [ian_]
RF: I expect to have done in 1 week.
14:51:32 [ian_]
-------------------------------------
14:51:36 [ian_]
AC meeting three bullets
14:51:45 [TimBL]
http://lists.w3.org/Archives/Member/tag/2002Apr/0002.html
14:52:00 [ian_]
TBL: Less contentious technical things we have decided:
14:52:00 [ian_]
-a1 URIs should be used to identify things
14:52:00 [ian_]
-a2 The RFC____ is right - XML MIME types.
14:52:00 [ian_]
-a3 HTTP GET should be used when and only when no side-effects
14:52:00 [ian_]
(whenToUseGet-7)
14:52:12 [ian_]
TBL:
14:52:13 [ian_]
More contentious technical things we have decided/may decide:
14:52:13 [ian_]
-b1 URIs for namespaces (like URIs for most things) should be dereferencable
14:52:13 [ian_]
-b2 MIME types should be considered to be URIs supported in HTTP space by
14:52:13 [ian_]
the registration authority
14:52:14 [ian_]
-b3 IESG is wrong to play down HTTP role as common standard for web services
14:52:15 [ian_]
with recent BCP. We support XML-P groups and others in criticizing BCP____
14:52:30 [ian_]
TBL: For process questions, see Paul's:
14:52:40 [DanC]
where is our decision on "-a1 URIs should be used to identify things"?
14:53:09 [ian_]
DC: URIs are used to identify things. What's new hear?
14:53:16 [ian_]
s/hear/here
14:53:36 [ian_]
TBL: Rewrite as: "In new designs, use URIs rather than inventing your own identification system."
14:53:43 [ian_]
DC: Where is our decision on this?
14:54:00 [ian_]
TBL: Yes, I thought I'd get in trouble since we haven't published anything.
14:54:14 [ian_]
..I should probably say "less contentious issues"
14:54:32 [ian_]
DC: In the thing SW is working on, this type of text would have been handy. I didn't find any.
14:55:17 [ian_]
TBL: Does text of section one talk about using URIs for new designs?
14:55:25 [ian_]
http://www.w3.org/2001/tag/doc/identify
14:55:58 [ian_]
DC: Doesn't say in so many words to use URIs in new designs.
14:56:12 [ian_]
q+
14:56:41 [Chris]
q+
14:58:12 [ian_]
IJ: I would like to highlight best practices in these documents. I would like to tie these in to TAG issues.
14:58:26 [Chris]
ack ian
14:58:30 [ian_]
(e.g., best practices for spec designers, authors, web masters, tools)....
14:58:51 [ian_]
SW: Some of this is in my latest writings on issue 9.
14:58:58 [ian_]
TBL: Let's declare consensus where we can....
14:59:04 [ian_]
ack Chris
14:59:05 [TimBL]
q?
14:59:29 [ian_]
CL: What does it actually mean? People can invent element and attribute names. Does this mean that all attribute (or element) names should be q names?
14:59:46 [ian_]
RF: TBL wrote down something more general - identification of resources.
15:00:07 [ian_]
DC: Let's not make this so general as to not mean anything.....e.g., XML Schema components; these are not currently identified by URIs.
15:00:11 [ian_]
TBL: And that's a bug.
15:00:22 [ian_]
DC: Then let's decide something, and send them a report as they are collecting requirements.
15:00:55 [ian_]
PC: Is this a feature of XML Schema 1.0?
15:01:03 [ian_]
DC: I don't consider it a feature (nor know how well-known it is).
15:01:08 [ian_]
TBL: I have no defense of it as a feature.
15:01:15 [ian_]
PC: How do you give anonymous types URIs?
15:01:22 [ian_]
DC: It's not about them, it's about things that do have names.
15:01:41 [ian_]
[SW asks if common practice with concatenation.]
15:01:46 [ian_]
DC: No, there is not that practice.
15:02:47 [Chris]
It seems to me that 'the' URI of an element or attribute is that section of the spec that defines said element or attribute ....
15:02:49 [ian_]
[Return to AC agenda]
15:03:02 [ian_]
TBL: Please contact me if you have problems with my proposal for the AC meeting.
15:03:27 [ian_]
PC: Will you use the same high-level material on the W3C track?
15:04:39 [ian_]
...I think we want to kill two birds with one stone.
15:05:01 [ian_]
TBL: We do need to have some process stuff at w3c track as well (e.g., how to talk to public, managing www-tag)
15:07:05 [ian_]
IJ: I will help TBL get this done....
15:07:17 [ian_]
RF: Will this be presentations by Tim or a panel?
15:07:36 [ian_]
TBL: Presentation by me, plus TAG on stage to answer questions (at AC meeting and W3C track)
15:07:51 [ian_]
----------------------
15:07:54 [ian_]
Mailing list policies
15:08:09 [ian_]
Postponed until next week.
15:08:20 [ian_]
IJ: Was there a sense of which way www-tag said to go?
15:08:30 [ian_]
SW: (1) Sympathy (2) Find a moderator
15:08:43 [ian_]
---------------------------
15:08:49 [TimBL]
Great multiplicative power of reuse derives from the facts that all languages use URIs as identifiers: This allows things written in one language to refer to things defined in another language. The use of URIs allows a language leverage the many forms of persistence, identity and various forms of equivalence. Each language simply refers to the URI spec - this is a flexibility point allowing the properties of naming and addressing schemes to be defined separately.
15:08:55 [TimBL]
Great multiplicative power of reuse derives from the facts that all languages use URIs as identifiers: This allows things written in one language to refer to things defined in another language. The use of URIs allows a language leverage the many forms of persistence, identity and various forms of equivalence. Each language simply refers to the URI spec - this is a flexibility point allowing the properties of naming and addressing schemes to be defined separately.
15:08:56 [ian_]
Findings on uriMediaType-9
15:09:02 [TimBL]
http://www.w3.org/2001/tag/2002/01-uriMediaType-9
15:10:03 [ian_]
"All important resources should be identifiable by URI."
15:10:18 [ian_]
RF: This is different from saying that, whenever we use identifiers, we should use URIs.
15:11:02 [ian_]
RF: For example, things that are just not identified (e.g., requiring HTTP headers to be URIs is different).
15:11:18 [ian_]
RF: I prefer this wording (in uriMediaType-9) over "Use URIs for identifiers."
15:11:31 [DanC]
yes, 2nded "* All important resources should be identifiable by URI."
15:12:32 [ian_]
PC: What's "important"?
15:13:09 [ian_]
SW: This issue was primarily about mime types, which are themselves not URIs. The IETF have a draft for assigning URNs to "important" protocol parameters.
15:13:34 [ian_]
PC: So, these are principles, then applied later by saying, e.g., "my media types are important"
15:13:48 [ian_]
PC: I like this because the answer is compelling.
15:14:19 [ian_]
TBL: Resolved - accept "All important resources should be identifiable by URI."
15:14:30 [ian_]
2. "URI's for important resources should be dereferencable."
15:15:02 [DanC]
PROPOSED: "# URI's for important resources should be dereferencable."
15:15:11 [ian_]
[RF: is that how you spell dereferenceable?]
15:15:31 [ian_]
TBL: Resolved (accepted 2.)
15:15:39 [ian_]
3. Dereferencing URI's for important protocol parameters should return human and/or machine readable representations that describe the nature and purpose of those resources.
15:15:45 [DanC]
2nded.
15:16:04 [ian_]
SW: I didn't think this one had the same character as the other two.
15:16:33 [ian_]
SW: What about saying what we accept to get back when we dereference a URI/
15:16:34 [ian_]
?
15:16:54 [DanC]
yes, s/important protocol parameters/important resources/ in the 3rd bullet.
15:16:57 [ian_]
SW: First two talk about more generically important resources; the third is focused on parameters.
15:17:30 [DanC]
"... important concepts (e.g. protocol parameters) ..."
15:17:32 [ian_]
TBL: Maybe change to "important resources (such as protocol parameters"
15:17:41 [DanC]
works for me
15:17:42 [Chris]
yes, that is a better wording
15:17:55 [Chris]
perhaps add another example of 'important' as well?
15:17:59 [TimBL]
Dereferencing URI's for important abstract concepts (for example, Internet protocol parameters) should return human and/or machine readable representations that describe the nature and purpose of those resources
15:18:28 [TimBL]
RRSAgent, pointer?
15:18:28 [RRSAgent]
See http://www.w3.org/2002/04/08-tagmem-irc#T15-18-28
15:18:37 [ian_]
TBL: Resolved (accepted as written by TBL)
15:18:54 [Chris]
That means that not only do we need a URI for each media type, but als o (another) URI for each parameter that media type can take
15:18:57 [DanC]
editorial: in-your-face-URIs: # http://www.ietf.org/internet-drafts/draft-eastlake-cturi-03.txt
15:19:02 [ian_]
RF: A global point on the document - "s/MIME media types/Internet media types/"
15:19:18 [Chris]
what is the URI of the charset parameter?
15:20:04 [ian_]
TBL: From the point of view of style, I'd be inclined to make these direct statements: Just say "It is important ..."
15:20:10 [ian_]
TBL: The whole document is asserted by the TAG.
15:21:08 [ian_]
PC: Are we proposing who should fix the problem?
15:21:54 [ian_]
TBL: Make last sentence more direct: "The proposals of both ...." (not TAG has reservations...)
15:22:00 [ian_]
PC: But who is taking this to the IETF?
15:22:45 [ian_]
TBL: Does RF participate in IETF/W3C call?
15:22:48 [ian_]
RF: Not currently.
15:23:07 [ian_]
RF: I am willing to be on the calls.
15:23:18 [DanC]
they happen at the same frequency as IETF ftf meetings;
15:23:53 [ian_]
DC: I am satisfied with the document as modified.
15:24:09 [ian_]
SW: There is a tone in the IETF about trying to have a mechanism to resolve URNs.
15:24:59 [ian_]
TBL: Yes, those people who favor URNs in the IETF claim that they are building a mechanism to resolve URNs. We have a working resolution mechanism; building a second one is in general a bad idea.
15:25:09 [ian_]
DC: We've written what we think.
15:25:19 [ian_]
TBL: And with more authority than it's been written before.
15:26:49 [ian_]
DC: Names take on meaning through use.
15:27:02 [ian_]
CL: There are two URIs for RFCs already.
15:27:21 [ian_]
...if they both live indefinitely, we can't compare the URIs for equivalence.
15:27:30 [ian_]
DC: Comparing two URIs is much better than no URIs.
15:27:37 [ian_]
TBL: You can always say "start with this URI"
15:27:59 [ian_]
CL: My perception is that the IETF doesn't like this; they dislike saying "this is *the* URI, and it's mirrored in several places..."
15:28:35 [ian_]
TBL: The IETF is getting over some of its previous practice; now have a central registry where the URI looks good. I think that necessity among themselves (guess URI for an RFC); it's painful if they continue to change these URIs.
15:28:53 [ian_]
RESOLVED:
15:29:14 [ian_]
- Accept as TAG finding uriMediaType-0 (as amended).
15:29:30 [ian_]
Action TBL (co-opting RF): Take this finding to the IETF.
15:30:00 [ian_]
Action SW: Change document as amended in this meeting.
15:30:26 [ian_]
DC: The issue won't be closed until we've had return from IETF.
15:30:29 [ian_]
TBL: But it will be a finding.
15:30:47 [ian_]
..and probably in pending state for a while.
15:30:56 [ian_]
...special color in issues list.
15:31:14 [Stuart]
Ian, that was http://www.w3.org/2001/tag/2002/01-uriMediaType-9 not uriMediaType-0 ??
15:31:14 [ian_]
RF: Where do we put findings?
15:31:34 [ian_]
http://www.w3.org/2001/tag/2002/01-uriMediaType-9
15:31:46 [ian_]
RF: I'd like a director.
15:31:48 [ian_]
directory
15:31:50 [DanC]
ian_, I suggest a list of findings on the TAG home page
15:32:25 [ian_]
Action IJ: Add a zone to the home page for links to findings; link from issues list; link from arch toc
15:33:48 [ian_]
TBL: I suggest using /2001/tag/doc....
15:33:50 [ian_]
DC: It needs a new name?
15:34:14 [ian_]
TBL: I'm happy for this finding to stay here. But eventually, I'd like the findings to be put end-to-end in a single document.
15:34:41 [ian_]
DC: Distinct from the architecture document?
15:35:07 [ian_]
TBL: I think the arch doc will be made up of top down stuff (summaries), plus findings (bottom up), glued together.
15:35:17 [ian_]
DC: I would expect arch findings to be far from Eastlake's draft.
15:35:34 [ian_]
DC: This finding has been found; it's URI is perfectly good. That's it.
15:35:58 [ian_]
RF: I don't want to dig through a 100-page doc for the 25 findings.
15:36:35 [ian_]
RF: Just create a findings.html with links to the findings.
15:37:01 [ian_]
RF: I don't want the list on the tag home page.
15:37:13 [ian_]
Action IJ: Create a separate page for accepted TAG findings.
15:37:37 [ian_]
-----------------------
15:37:43 [ian_]
Is there consensus that GET should be used for form actions that do not have side effects, and POST for those that do?
15:37:43 [ian_]
Preparation: read Architecture from 50K feet
15:37:58 [ian_]
TBL: This is what the HTTP spec says; it's often abused.
15:38:11 [ian_]
TBL: I'd like the TAG on record as emphasizing this fact; there's been a security issue lately.
15:38:45 [ian_]
PC: Do you have a URI for the security whole assertion?
15:41:32 [ian_]
TBL: The initial tone of the Microsoft article (since withdrawn) was "don't use standards". The explanation was misleading.
15:42:05 [Chris]
q+
15:42:21 [ian_]
TBL: I'd like for the TAG to make a clear statement. From the point of MSDN, this event is history.
15:42:57 [ian_]
CL: Restating:
15:43:10 [ian_]
a) Are we saying that everything that has a side-effect must use POST, or must not use GET?
15:43:21 [ian_]
CL: I don't think we can say the former.
15:43:35 [Chris]
otherwise we can never use PUT for example
15:43:38 [ian_]
TBL: So restate with the amendment: "Everything that does not have side-effects must use GET."
15:43:50 [ian_]
TBL: "Everything that does have side-effects must not use GET."
15:43:56 [ian_]
CL: Define "side-effect".
15:44:14 [ian_]
TBL: There are admin side effects that are not part of the architecture.
15:44:21 [Chris]
session tracking components as side effects
15:44:25 [ian_]
CL: ....defining them is partly a privacy issue..
15:44:43 [Chris]
trying to clarify whjat is a side effect
15:44:58 [ian_]
SW: How about: "Something that doesn't change the state of the resource?"
15:45:12 [ian_]
DC: In the HTTP spec, it says "something that the user can be accountable for."
15:45:38 [ian_]
DC: I think the wording in the HTTP spec is quite good.
15:46:22 [ian_]
http://www.ietf.org/rfc/rfc2616.txt
15:46:23 [Chris]
incidentally, very many mailing list softwares send a confirm message on subscription request; one confirms by doing a GET
15:46:28 [ian_]
The important
15:46:28 [ian_]
distinction here is that the user did not request the side-effects,
15:46:28 [ian_]
so therefore cannot be held accountable for them.
15:47:00 [ian_]
IJ: Does distinction between safe and idempotent matter here?
15:47:52 [ian_]
CL: Widely used functionality: mailing lists mail confirmation when you've subscribed to a list.
15:48:01 [ian_]
DC: Right way to do this is a GET then a POST.
15:48:10 [Chris]
okay
15:48:47 [ian_]
TBL: WRong way - to unsubscribe, click on this link. And all you've done is read the web page.
15:48:58 [ian_]
RF: Why are we discussing this?
15:49:16 [Chris]
so, the widespread spam practice of html mail with external images to check you read the mail is bad?
15:49:21 [DanC]
relevant bit of the HTTP spec: [[ Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. ]] -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1
15:49:24 [ian_]
TBL: I'd like a motion on the table that HTTP GET should be used for actions that don't have side effects, and must not be used for actions that do have side effects.
15:49:34 [ian_]
RF: This is already part of the standard.
15:49:40 [ian_]
TBL: Then let's point this out as such.
15:50:08 [ian_]
RF: I would agree to a security advisory if we found an implementation that had this problem.
15:50:36 [ian_]
TBL: I want the the TAG to support the HTTP protocol.
15:50:48 [ian_]
DC: Are we making a mountain out of a molehill?
15:51:12 [ian_]
TBL: W3C Team could publicize the dangers of not doing this.
15:52:39 [ian_]
IJ: I recall two pieces:
15:52:42 [ian_]
- Follow HTTP spec
15:52:55 [Chris]
q+
15:53:04 [ian_]
IJ: - GET-like POST when long URIs?
15:53:27 [ian_]
DC: Mailing list subscription case is a perfectly good case to write up. Here's how to do right, some people have done it wrong.
15:53:50 [ian_]
RF: We can use other examples as well (even if no longer on the Web).
15:54:06 [ian_]
RF: I have no problem with issuing a finding on this. I don't think we should try to write it during this meeting.
15:55:09 [ian_]
IJ: I propose - one liner finding ("Follow rfc2616") plus examples of doing the right and wrong things..
15:55:24 [ian_]
CL: I just want to get clarification on what a side-effect is.
15:55:36 [ian_]
DC: "Side-effect' wording is not relevant.
15:55:44 [ian_]
RF: Right, about user accountability.
15:55:59 [TimBL]
where a side-effect is an action for which the client user can be held accountable.
15:56:59 [DanC]
q+
15:57:03 [ian_]
DC: I'm happy to second section 9.1.1 of HTTP spec.
15:57:03 [TimBL]
http://www.w3.org/DesignIssues/Axioms.html#state
15:57:05 [ian_]
ack Chris
15:57:07 [Chris]
ack chris
15:57:34 [ian_]
DC Proposal:
15:57:42 [ian_]
1) Cite 9.1.1 of RFC 2616
15:57:52 [ian_]
"Naturally, it is not possible to ensure that the server does not
15:57:52 [ian_]
generate side-effects as a result of performing a GET request; in
15:57:52 [ian_]
fact, some dynamic resources consider that a feature. The important
15:57:52 [ian_]
distinction here is that the user did not request the side-effects,
15:57:52 [ian_]
so therefore cannot be held accountable for them.
15:57:53 [ian_]
"
15:58:06 [TimBL]
In HTTP, GET must not have side effects.
15:58:10 [ian_]
DC: Maybe cite a little more.
15:58:10 [DanC]
"9.1.1 Safe Methods"
15:58:24 [ian_]
RF: Counters are side effects. The difference is whether anyone cares.
15:58:35 [TimBL]
In HTTP, GET must not have any action for which the user can be held accountable.
15:58:44 [ian_]
DC: In particular, if you went to court and they said "You looked at this web page" and you say "no I didn't."
15:58:49 [ian_]
IJ: Accessibility kicks in here.
15:59:34 [ian_]
...some users may not recognize effects as advertised to a user.
15:59:50 [TimBL]
In HTTP, GET *must* not have any action for which the user can be held accountable. GET should be used for any operation where there is no such action.
15:59:55 [ian_]
RF: It must be possible to build a system using GET that doesn't require the user to understand the context.
16:00:39 [ian_]
RF on TBL proposal: That sounds weird. I would say "GET must not have any side effects." The retrieval is an action for which the user is held accountable.
16:00:57 [ian_]
RF: If I run a spider on your site that does 1000000 requests per second, you will hold me accountable for that.
16:01:05 [ian_]
RF: You could say "any non-retrieval action"
16:01:20 [ian_]
TBL: Let's put this on front of agenda for next time.
16:01:33 [ian_]
CL: I think we are largely agreeing; this is about the edge cases.
16:02:30 [ian_]
Action DC: Write up a strawman proposal on when to use GET.
16:02:52 [ian_]
...at least a one-liner; examples on what do to right/wrong optional (and encouraged).
16:03:17 [ian_]
TBL: I want a one-liner for an upcoming slide.
16:03:18 [DanC]
ah... the bumper-sticker value. I suppose I can see that.
16:03:48 [ian_]
PC: Does this finding break anything in SOAP 1.0?
16:03:59 [ian_]
DC: There's no way to bind to GET with SOAP (as far as I know today).
16:04:19 [Zakim]
-Stuart
16:04:23 [Zakim]
-DanC
16:04:23 [Zakim]
-Roy
16:04:25 [Zakim]
-Chris
16:05:23 [Zakim]
-PCotton
16:05:25 [Zakim]
-Ian
16:05:30 [Zakim]
-TimBL
16:05:32 [ian_]
RRSAgent, stop logging