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