- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 09 Apr 2002 11:20:18 -0400
- To: www-tag@w3.org
Hello,
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
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
+ 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
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
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.
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-eastla
ke-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:
+ Accept TAG finding uriMediaType-9 (as
amended).
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.
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 15:07:20 $ by
$Author: ijacobs $
Received on Tuesday, 9 April 2002 11:20:41 UTC