W3C home > Mailing lists > Public > www-tag@w3.org > April 2002

Summary of 8 April 2002 TAG teleconference

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 09 Apr 2002 11:20:18 -0400
Message-ID: <3CB306B2.1000105@w3.org>
To: www-tag@w3.org

A summary of the 8 Apr 2002 TAG teleconf is
online [1] and quoted below as text. See also
the IRC log [2].

  - Ian

[1] http://www.w3.org/2002/04/08-tag-summary
[2] http://www.w3.org/2002/04/08-tagmem-irc

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

                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


  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
	+ IETF and URNs
	+ Grouping TAG findings
   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
   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
        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

   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
    15:07:20 $ 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
      RFC3025 (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.

   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
    TBL: I'd like to leave this one as pending. Maybe
    shorter term IETF call required.

   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

    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.

   where is our decision on "-a1 URIs should be
   used to identify things"?

   DC: URIs are used to identify things. What's new
   TBL: Rewrite as: "In new designs, use URIs
   rather than inventing your own identification
   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
   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.

   It seems to me that 'the' URI of an element or
   attribute is that section of the spec that
   defines said element or attribute ....

   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
   TBL: Presentation by me, plus TAG on stage to
   answer questions (at both AC meeting and W3C

Findings on issue uriMediaType-9

Refer to revised findings on issue uriMediaType-9.

   RF: Saying "All important resources should be
   identifiable by URI." is different from saying
   that, whenever we use identifiers, we should use
   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."

   yes, 2nded "* All important resources should be
   identifiable by URI."

   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
   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
   TBL: Resolved: Accept this language, "All
   important resources should be identifiable by
   TBL: Next proposal: "URI's for important
   resources should be dereferencable."

   PROPOSED: "# URI's for important resources
   should be dereferencable."

   [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


   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

   yes, s/important protocol parameters/important
   resources/ in the 3rd bullet.

   SW: First two talk about more generically
   important resources; the third is focused on

   "... important concepts (e.g. protocol
   parameters) ..."

   TBL: Maybe change to "important resources (such
   as protocol parameters)"

   works for me

   Yes, that is a better wording. Perhaps add
   another example of 'important' as well?

   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."

   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.

   editorial: in-your-face-URIs: #

   RF: A global point on the document - "s/MIME
   media types/Internet media types/"

   What is the URI of the charset parameter?

   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
   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.

   These calls happen at the same frequency as IETF
   ftf meetings;

   DC: I am satisfied with the document (findings
   on uriMediaType-9) as modified.

   + Accept TAG finding uriMediaType-9 (as


   + TBL (co-opting RF): Take this finding to the
   + SW: Change document as amended in this

   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

   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
   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

   RF: Where do we put findings? I'd like a

   ian_, I suggest a list of findings on the TAG
   home page

   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.


   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
   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.

   otherwise we can never use PUT for example

   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.

   Session tracking components as side effects

   CL: ....defining them is partly a privacy

   trying to clarify what is a side effect

   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.

   Incidentally, lots of mailing list software
   sends a confirm message on subscription request;
   one confirms by doing a GET.

   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
   DC: Right way to do this is a GET then a POST.


   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?

   So, the widespread spam practice of html mail
   with external images to check you read the mail
   is bad?

   The relevant bit of the HTTP spec is section

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.

   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
   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.

   where a side-effect is an action for which the
   client user can be held accountable.

   DC: I'm happy to second section 9.1.1 of HTTP

   See also Design Issues axioms on Identity,
   State, and GET

   DC Proposal: Cite 9.1.1 of RFC2616, "Safe
   Methods". Maybe cite a little more for context.

   In HTTP, GET must not have side effects.

   RF: Counters are side effects. The difference is
   whether anyone cares.

   In HTTP, GET must not have any action for which
   the user can be held accountable.

   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.

   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."

   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
   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
   TBL: I want a one-liner for an upcoming slide.

   ah... the bumper-sticker value. I suppose I can
   see that.

   PC: Does this finding break anything in SOAP
   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 15:07:20 $ by
$Author: ijacobs $
Received on Tuesday, 9 April 2002 11:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:51 UTC