Summary of 2002-04-08 TAG meeting

Note: This is an edited version of the 8 April 2002 TAG IRC log.

Previous meeting: 1 April | Next meeting: 15 April | TAG home

Participants: Tim Berners-Lee (TBL, Chair), Dan Connolly (DC), Paul Cotton (PC), Roy Fielding (RF), Chris Lilley (CL), Stuart Williams (SW), Ian Jacobs (IJ, Scribe)

Regrets: Tim Bray, David Orchard, Norm Walsh

Agenda

See agenda announcement:

  1. Review of previous minutes (accepted), action items
  2. TAG presentations at W3C AC meeting and W3C track WWW 2002
  3. Findings on issue uriMediaType-9
  4. When to use GET (issue whenToUseGet-7)

Future agenda items:

  1. Running TAG meetings when TBL absent
  2. IETF mandating URNs for XML namespaces in IETF specs
  3. Should TAG be doing technical work beyond architectural decisions?
  4. Confirm decision to propose RDF+XHTML for namespace documents (CL)
  5. TAG mailing list policies.

Summary of technical Decisions

  1. Accept findings on issue uriMediaType-9 with the following language and other editorial changes:
    1. All important resources should be identifiable by URI.
    2. URI's for important resources should be dereferencable.
    3. 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.

Action items

Completed:

  1. TBL: Draft three points for TAG presentation to AC in May 2002. Done
  2. DC, SW: Revise findings on uriMediaType-9, incorporating 25 Mar discussion points.

    SW: I'm interested in getting more feedback on this.
    DC: The version of this dated $Date: 2002/04/09 16:05:45 $ is much better.

  3. TB: Extract issues for TAG from thread on boundaries for the Web. Done
  4. IJ: Add URIEquivalence-15 and HTTPSubstrate-16 to issues list
  5. RF: Start discussion on www-tag about criticism of RFC3205 (HTTPSubstrate-16). Done

    RF: Now, the action should be to write up the results of the discussion.
    RF: Not sure whether this is a finding or a discussion document?
    SW: Summary v. opinion piece.
    Action     RF: Write up the discussion on critique of RFC3205. Deadline 1 week.

Pending:

  1. TBL: Take question of HTTP Query to W3C/IETF liaison (issue whenToUseGet-7)

    DC: Next call is on the order of about 3 months from now.
    TBL: I'd like to leave this one as pending. Maybe shorter term IETF call required.

Open:

  1. DO: Write text about "Web as information space", to be integrated by IJ

    PC: DO has tried two cuts, not satisfied with either. I think it's still pending.
    TBL: No state change since DO not here.

  2. IJ: Integrate/combine one-page summaries into an architecture document

    IJ:Started.

    DC: Seems to be about 1/5th done.
    IJ: Is this to be the arch doc, or is there a second one where these ideas will be fleshed out?
    TBL: I would imagine this is is the arch doc and itself will be fleshed out.

  3. TBL: Write draft on when URI variants are considered equivalent (URIEquivalence-15)
  4. TBL/IJ: Find someone in W3C Team or RDF world to draft comments on RDF+HTML for namespace documents.

    CL: I have some comments on that - I'm concerned since we have two Recommendations (XHTML, XLink) and we're not recommending their use.
    TBL: RDF is also a Recommendation.
    CL: I have some comments on that - I'm concerned since we have two Recommendations (XHTML, XLink) and we're not recommending their use.
    TBL: To be added to agenda.

  5. SW: Draft suggestions for namespace documents

TAG presentations at W3C AC meeting and W3C track WWW 2002

See proposal from TBL, which contains three types of points: (1) less contentious technical issues, (2) more contentious technical issues, and (3) process issues.

[DanC]
where is our decision on "-a1 URIs should be used to identify things"?
[ian_]
DC: URIs are used to identify things. What's new here?
TBL: Rewrite as: "In new designs, use URIs rather than inventing your own identification system."
DC: Where is our decision on this?
TBL: Yes, I thought I'd get in trouble since we haven't published anything. I should probably say "less contentious issues" rather than issues where we have resolutions.
DC: In the thing SW is working on, this type of text would have been handy. I didn't find any.
TBL: Does text of section one talk about using URIs for new designs?
DC: It doesn't say in so many words to use URIs in new designs.
IJ: I would like to highlight best practices in these documents. I would like to tie these in to the TAG issues list as well.
(e.g., best practices for spec designers, authors, web masters, tools)....
SW: Some of this is in my latest writings on issue 9.
TBL: Let's declare consensus where we can....
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?
RF: TBL wrote down something more general - identification of resources.
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.
TBL: And that's a bug.
DC: Then let's decide something, and send them a report as they are collecting requirements.
PC: Is this a well-known feature of XML Schema 1.0?
DC: I don't consider it a feature (nor know how well-known it is).
TBL: I have no defense of it as a feature.
PC: How do you give anonymous types URIs?
DC: The problem is not with anonymous types, it's about things that do have names.
[SW asks if common practice with concatenation.]
DC: No, there is not that practice.
[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 ....
[ian_]
Returning to topic of AC agenda
TBL: Please contact me if you have problems with my proposal for the AC meeting.
PC: Will you use the same high-level material on the W3C track? I think we want to kill two birds with one stone.
TBL: We do need to have some process stuff at w3c track as well (e.g., how to talk to public, managing www-tag)
IJ: I will help TBL get this done.
RF: Will this be presentations by Tim or a panel?
TBL: Presentation by me, plus TAG on stage to answer questions (at both AC meeting and W3C track).

Findings on issue uriMediaType-9

Refer to revised findings on issue uriMediaType-9.

[ian_]
RF: Saying "All important resources should be identifiable by URI." is different from saying that, whenever we use identifiers, we should use URIs.
RF: For example, things that are just not identified (e.g., requiring HTTP headers to be URIs is different).
RF: I prefer this wording (in uriMediaType-9) over "Use URIs for identifiers."
[DanC]
yes, 2nded "* All important resources should be identifiable by URI."
[ian_]
PC: What's "important"?
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.
PC: So, these are principles, then applied later by saying, e.g., "my media types are important"
PC: I like this because the answer is compelling.
TBL: Resolved: Accept this language, "All important resources should be identifiable by URI."
TBL: Next proposal: "URI's for important resources should be dereferencable."
[DanC]
PROPOSED: "# URI's for important resources should be dereferencable."
[ian_]
[RF: is that how you spell dereferenceable?]
TBL: Resolved: Accept language, "URI's for important resources should be dereferencable."
TBL: Next proposal: "Dereferencing URI's for important protocol parameters should return human and/or machine readable representations that describe the nature and purpose of those resources."
[DanC]
2nded.
[ian_]
SW: I didn't think this one had the same character as the other two. What about saying what we accept to get back when we dereference a URI?
[DanC]
yes, s/important protocol parameters/important resources/ in the 3rd bullet.
[ian_]
SW: First two talk about more generically important resources; the third is focused on parameters.
[DanC]
"... important concepts (e.g. protocol parameters) ..."
[ian_]
TBL: Maybe change to "important resources (such as protocol parameters)"
[DanC]
works for me
[Chris]
Yes, that is a better wording. Perhaps add another example of 'important' as well?
[TimBL]
Resolved: Accept this language, "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."
[Chris]
That means that not only do we need a URI for each media type, but also (another) URI for each parameter that media type can take.
[DanC]
editorial: in-your-face-URIs: # http://www.ietf.org/internet-drafts/draft-eastlake-cturi-03.txt
[ian_]
RF: A global point on the document - "s/MIME media types/Internet media types/"
[Chris]
What is the URI of the charset parameter?
[ian_]
TBL: From the point of view of style, I'd be inclined to make these direct statements: Just say "It is important ..." The whole document is asserted by the TAG.
PC: Are we proposing who should fix the problem?
TBL: Make last sentence more direct: "The proposals of both ...." (not TAG has reservations...)
PC: But who is taking this to the IETF?
TBL: Does RF participate in IETF/W3C call?
RF: Not currently. I am willing to participate on those calls.
[DanC]
These calls happen at the same frequency as IETF ftf meetings;
[ian_]
DC: I am satisfied with the document (findings on uriMediaType-9) as modified.
Resolved:

Action:

DC: The issue won't be closed until we've had return from IETF.
TBL: But it will be a finding. Leave in "pending" state (with, e.g., a special color in the issues list).

On IETF promotion of URNs

[ian_]
SW: There is a tone in the IETF about trying to have a mechanism to resolve URNs.
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.
DC: We've written what we think.
TBL: And with more authority than it's been written before.
DC: Names take on meaning through use.
CL: There are two URIs for RFCs already. If they both live indefinitely, we can't compare the URIs for equivalence.
DC: Comparing two URIs is much better than no URIs.
TBL: You can always say "start with this URI"
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..."
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.

On grouping TAG findings

[ian_]
RF: Where do we put findings? I'd like a directory.
[DanC]
ian_, I suggest a list of findings on the TAG home page
[ian_]
TBL: I suggest using /2001/tag/doc/ for the revised findings document.
DC: It needs a new name?
TBL: I'm happy for this finding to stay where it is. But eventually, I'd like the findings to be put end-to-end in a single document.
DC: Distinct from the architecture document?
TBL: I think the arch doc will be made up of top down stuff (summaries), plus findings (bottom up), glued together.
DC: I would expect arch findings to be far from Eastlake's draft.
DC: This finding has been found; it's URI is perfectly good. That's it.
RF: I don't want to dig through a 100-page doc for the 25 findings.
RF: Just create a findings.html with links to the findings.
RF: I don't want the list on the tag home page.

TBL: Resolved to create a distinct page for accepted TAG findings.

Action IJ: Create a separate page for accepted TAG findings.

IJ: Also, link from issues list and arch toc.

When to use GET (issue whenToUseGet-7)

Refer to issue whenToUseGet-7.

[ian_]

TBL: Is there consensus that GET should be used for form actions that do not have side effects, and POST for those that do? This is what the HTTP spec says; it's often abused. I'd like the TAG on record as emphasizing this fact; there's been a security issue lately.
PC: Do you have a URI for the security whole assertion?
TBL: The initial tone of the Microsoft article (since withdrawn) was "don't use standards". The explanation was misleading. I'd like for the TAG to make a clear statement. From the point of MSDN, this event is history.
CL: Are we saying that everything that has a side-effect must use POST, or must not use GET? I don't think we can say the former.
[Chris]
otherwise we can never use PUT for example
[ian_]
TBL: So restate with the amendment: "Everything that does not have side-effects must use GET. Everything that does have side-effects must not use GET."
CL: Define "side-effect".
TBL: There are administrative side effects that are not part of the architecture.
[Chris]
Session tracking components as side effects
[ian_]
CL: ....defining them is partly a privacy issue..
[Chris]
trying to clarify what is a side effect
[ian_]
SW: How about: "Something that doesn't change the state of the resource?"
DC: In the HTTP spec, it says "something that the user can be accountable for." I think the wording in the HTTP spec is quite good.
[Chris]
Incidentally, lots of mailing list software sends a confirm message on subscription request; one confirms by doing a GET.
[ian_]
DC: The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
IJ: Does distinction between safe and idempotent matter here?
CL: Widely used functionality: mailing lists mail confirmation when you've subscribed to a list.
DC: Right way to do this is a GET then a POST.
[Chris]
okay
[ian_]
TBL: Wrong way - to unsubscribe, click on this link. And all you've done is read the web page.
RF: Why are we discussing this?
[Chris]
So, the widespread spam practice of html mail with external images to check you read the mail is bad?
[DanC]
The relevant bit of the HTTP spec is section 9.1.1:

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.

[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.
RF: This is already part of the standard.
TBL: Then let's point this out as such.
RF: I would agree to a security advisory if we found an implementation that had this problem.
TBL: I want the the TAG to support the HTTP protocol.
DC: Are we making a mountain out of a molehill?
TBL: W3C Team could publicize the dangers of not doing this.
IJ: Summarizing what I hear as two pieces of the whenToUseGet-7 issue:
  1. Follow HTTP spec
  2. Do we need another method for GET-like POSTS (to avoid hairy URIs)?
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.
RF: We can use other examples as well (even if no longer on the Web).
RF: I have no problem with issuing a finding on this. I don't think we should try to write it during this meeting.
IJ: I propose - one liner finding ("Follow rfc2616") plus examples of doing the right and wrong things..
CL: I just want to get clarification on what a side-effect is.
DC: "Side-effect' wording is not relevant.
RF: Right, about user accountability.
[TimBL]
where a side-effect is an action for which the client user can be held accountable.
[ian_]
DC: I'm happy to second section 9.1.1 of HTTP spec.
[TimBL]
See also Design Issues axioms on Identity, State, and GET
[ian_]
DC Proposal: Cite 9.1.1 of RFC2616, "Safe Methods". Maybe cite a little more for context.
[TimBL]
In HTTP, GET must not have side effects.
[ian_]
RF: Counters are side effects. The difference is whether anyone cares.
[TimBL]
In HTTP, GET must not have any action for which the user can be held accountable.
[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."
IJ: Accessibility kicks in here. Some users may not recognize effects as advertised to a user.
[TimBL]
Proposal: "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."
[ian_]
RF: It must be possible to build a system using GET that doesn't require the user to understand the context.
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. If I run a spider on your site that does 1000000 requests per second, you will hold me accountable for that. You could say "any non-retrieval action"
TBL: Let's put this on front of agenda for next time.
CL: I think we are largely agreeing; this is about the edge cases.
Action DC: Write up a strawman proposal on when to use GET. At least a one-liner; examples on what do to right/wrong optional (and encouraged).
TBL: I want a one-liner for an upcoming slide.
[DanC]
ah... the bumper-sticker value. I suppose I can see that.
[ian_]
PC: Does this finding break anything in SOAP 1.0?
DC: There's no way to bind to GET with SOAP (as far as I know today)..

Ian Jacobs, for Tim Berners-Lee

Last modified: $Date: 2002/04/09 16:05:45 $ by $Author: ijacobs $