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:
- Review of previous minutes (accepted), action
items
- TAG presentations at W3C AC meeting and W3C track
WWW 2002
- Findings on issue uriMediaType-9
- IETF and URNs
- Grouping TAG findings
- When to use GET (issue whenToUseGet-7)
Future agenda items:
- Running TAG meetings when TBL absent
- IETF mandating URNs for XML namespaces in IETF specs
- Should TAG be doing technical work beyond architectural decisions?
- Confirm decision to propose RDF+XHTML for namespace documents (CL)
- TAG mailing list policies.
Summary of technical Decisions
- Accept findings on
issue uriMediaType-9 with the following language and other editorial
changes:
- All important resources should be identifiable by URI.
- URI's for important resources should be dereferencable.
- 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.
Completed:
- TBL: Draft three points for TAG presentation to AC in May 2002. Done
- 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.
- TB: Extract issues for TAG from thread on boundaries for the Web. Done
- IJ: Add URIEquivalence-15 and HTTPSubstrate-16 to issues list
- 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:
- 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:
- 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.
- 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.
- TBL: Write draft on when URI variants are considered equivalent
(URIEquivalence-15)
- 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.
- 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).
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:
- TBL (co-opting RF): Take this finding to the IETF.
- SW: Change document as amended in this meeting.
- 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.
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:
- Follow HTTP spec
- 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 $