- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 23 Jul 2002 18:23:07 -0400
- To: www-tag@w3.org
Hello,
The minutes of the 22 July 2002 TAG teleconf are
available at HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2002/07/22-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
==========================================================
W3C | TAG | Previous:15 Jul | Next: 29 July | IRC log
Minutes of 22 July 2002 TAG teleconference
Nearby: Teleconference details · issues list ·
www-tag archive
1. Administrative
1. Roll call: SW, DC, IJ, PC, NW, TB, RF. Regrets:
CL, TBL, DO (on IRC)
2. Accepted 15 July minutes
3. Next meeting: 29 July. Regrets: NW, SW. Possible
regrets: DO, PC
4. Confirmed status of completed actions
5. September meeting arrangements
Action TB: Send information about hotels to TAG.
1.2 Completed actions?
1. Action TB: 2002/07/15: Clarify sentence on what
an HTTP URI refers to. (Done)
1.3 New issues?
1. Accepted as issue contentTypeOverride-24:
Overriding HTTP content-type with a URI
reference.See email from TBL.
2. Accepted as issue deepLinking-25: "Deep linking
illegal" bad practice? See email from Tim Bray
and Links and Law
On deepLinking-25:
RF: I support that in general that there is
nothing to prevent deep linking on the net.
But the way copyright works, if you are using
someone's content in a way that denies them
business value, you're screwed anyway.
TB: Way to do this is to use an authentication
scheme, or use referrer field. They didn't do
any of this. If they had done that and the
"bad guys" had worked around this, then they
would have had grounds to take them to court.
RF: I agree with you in principle. But the
ruling in this case was about one news org
taking content from another.
Action PC: Ask Henrik Frystyk Nielsen to
provide us with a precis of the ruling.
PC: We should tell people that if they publish
a URI and don't want someone to get at it,
what they can do.
TB: There has been litigation about this
several times. I think this will keep coming
up.
RF: I agree with the principle in general. I
am worried about the actual facts of the case.
DC: Following the "if it jams, force it; if it
breaks, it needed replacing anyway" principle,
let's do make this an issue. i.e. better to
ask forgiveness than permission.
2. Technical
* 2.1 Architecture document
* 2.2 Update on other findings
* 2.3 httpRange-14
* 2.4 uriMediaType-9
* 2.5 RFC3023Charset-21
* 2.6 URIEquivalence-15
* 2.7 Postponed
2.1 Architecture Document
[DanC]
Ian: I was relieved of some AB admin duties.
(e.g. meeting summaries).
[Ian]
IJ: Steve Ziles picking up some of my duties.
When I get new draft of Process Doc to AB, I
will be able to focus more on arch doc.
[DaveO]
woohoo!
[Ian]
CLOSED TBL 2002/05/05: Negotiate more of IJ
time for arch doc
ClOSED RF 2002/06/24: Write a paragraph on
technical and political aspects of URIs and
URI References. (Done).
[Ian]
# Action DC 2002/07/08: Propose text for
section 1.1 (URI Schemes)
[DanC]
re my action, I'm about 2/3rds of the way
thru; see FAQ.
[Ian]
# Action DC: 2002/07/15: Generate tables of
URI scheme props from RDF. (Progress)
DC: I started working on the URI scheme table.
Idea was to take column headings. I couldn't
find any column headings that generalized to
whole URI schemes. Some progress.
TB: I have revised my comments. See edits from
SW as well. I think SW's and Chris Ferris's
points are good ones.
# Action DC 2002/07/08: Ask Michael Mealing
when IETF decided not to use HTTP URIs to name
protocols. Awaiting reply.
DC: I need to get more from MM. Harder to find
out "what's going on there". I am not willing
to do intelligence on the whole IETF.
TB: There is some perception that the IETF
will not be using http URIs for namespaces as
a matter of policy. We need to find out if
that's the case (and if so, we are likely to
disagree).
DC: No way to get a clear answer unless policy
part of an RFC.
RF: We can ask the IESG a question about what
drafts they are rejecting.
DC: Do they *owe* me an answer?
RF: I Don't know.
DC: I can try. But last time I put something
on their agenda, it took them 9 months to
answer.
Resolved: Change action from ask Michael
Mealing to ask the IESG. Change to "if and
when" IETF decided...
DC: As for action about the table of URI
schemes, I find not useful. I hope the table
is not in the arch doc. I find it to be
extremely misleading.
The "Relative URI" column is misleading. It's
supported syntactically for all schemes.
RF: URN scheme doesn't allow "/" for
hierarchy.
DC: But if there's a slash in there, then
there's hierarchy.
SW: Is there hierarchy to mailto?
RF: Find the useful bit and put into the
table.
DC: I tried and was unable.
DC: Maybe a way to rephrase the relative URI
column to be useful. For spelling equivalence,
if you want to be sure - spell the same way. I
couldn't make sense of functional equivalence
at all. For admin, I couldn't find pattern.
RF: I liked that because it pointed out that
there was no diff between DNS authority and
URN authority.
DC: That's a point worth making, but the table
doesn't make it. (The differences between URNs
and DNS are not interesting, but the table
doesn't convey that.)
RF: Can we play with the RDF?
DC: Yes.
TB: The purpose of the table was not to be
exhaustive, but to cover a few characteristics
of deployed schemes as active discouragement
to reinvent the wheel.
TB: Something modest and hand-prepared would
probably do the job.
[DanC]
From the FAQ: "each valid use of a URI
reference unambiguously identifies one
resource"
[Ian]
IJ: Sounds something like what Norm wrote: "A
URI identifies a resource that is amenable to
unambiguous interpretation by recursive
application of a finite set of specifications,
beginning with the specification that governs
the scheme of the URI."
[DanC]
It's not clear that we're saying the same
thing.
[Ian]
IJ: I think we should try to align there.
#CLOSED Action SW 2002/07/15: Draft text for
arch principle on absolute addressing
preferred over context-sensitive addressing.
(Done)
TB: I think SW's draft is solid. Some feedback
on www-tag.
SW: I will include the bang-style addressing
(email) in the rationale.
DC: "Does the Web use local or global naming?"
TB: I'm not sure that the anecdote adds much
to the discussion.
DC: Global naming scales better in certain
ways (generic principle). I think the
principle applies to absolute URI refs (but
not "../foo").
RF: NEWS URIs are context dependent.: You have
to phrase this in a way that says that it's ok
to refer to a context-dependent resource if
the resource is meant to be
context-dependent.: E.g., reference to a
newsgroup that is relative to your local
access point.: Whereas nntp: is a global
context.: The details get nasty.: You need to
identify what you mean by resource first, then
say whether the resource needs to be globally
consistent ("sameness" must be global). When
we insert this text in the arch doc, we need
to be concerned about the nasty details.: I
suggest not to say "resource or concept", just
"resource".
Remaining open action items:
1. Action CL 2002/07/08: Propose text for section 2
(Formats). Deadline 30 July.
2. Action IJ 2002/07/08: Produce WD of Arch Doc.
Deadline 30 August.
2.2 Update on other findings
See also: findings.
1. Internet media type registration, consistency of
use.
+ Action PC 2002/07/08: Propose alternative
wording for finding regarding IANA
registration. Refer to "How to Register a
Media Type with IANA (for the IETF tree) "
(Not done)
2. Qnames as identifiers:
+ Action NW 2002/07/15: Republish finding. Can
we close qnameAsId-18?
Resolved: This finding is approved.
Action IJ: Update status
3. Formatting properties:
+ What is status of issue
formattingProperties-19?
Resolved: This finding is approved.
Action IJ: Update status
2.3 httpRange-14
See issue httpRange-14 and thread started by Tim
Bray.
DC: There is a stalemate between positions of
TBL and RF. Two rational arguments.
RF: If TBL confirms NW's writings, then I have
a simple answer. My answer is that this
conflates the URI with the method. When you
perform a GET, you get back a document. But
you don't define the resource type using the
method. If we define URIs in terms of what
they are when you do a GET, then yes, HTTP
URIs refer to documents. But we don't define
URIs that way.
TB: I thought there was material talk on the
list about the workings of RDF. RDF should be
able to talk about resources and
representations of resources. If it can't,
it's broken.
DC: I can try to take TBL's place for a
minute. He wants to conclude that "http: =>
document" and wants to ensure that those are
disjoint from people and cars.
RF: If the definition is not consistent across
all methods, then the definition is wrong.
SW: When TBL talks of "docs" he's talking
about document resources (not
representations). And RF is referring to
representations.
RF: Yes, I know that TBL is using that as a
basis point. But it still doesn't work - there
are still HTTP resources on the Web that are
not remotely documents. The distinction TBL
wants to make falls over in practice.
DC: I'd like a term that means "bits + mime
type" (other than representation)....
RF: We chose "entity body" since we couldn't
come up with a better term...
DC: I refer to bits + mime type as a document.
And resources that act like documents, I call
"works"
TB: There does seem to be a meaningful
distinction between a think that's basically
its representation, and more abstract things
like a weather report.
SW: How to make progress on this?
DC: I'm willing to try to convince TBL.
TB: we need language for this (about what an
HTTP resource is...) I suggest procedurally
that we ask TimBL to react to proposed text
and www-tag comments and help us make progress
on this issue.
[tim-mtg]
It is possible to have a system in which the
publisher of a URI determines what it actually
identifies (car or Web page) but all the
systems like
Dublin Core which assume blithley that a Web
page is identified by its URI have to be put
on hold. Until they can check with the
publishers of the URI to find out whether in
fact the URI identifies something which is not
a web page.
[Ian]
Action SW: Persuade TimBL to write an
exposition of his position.
2.4 uriMediaType-9
1. uriMediaType-9: Status of negotiation with IETF?
See message from DanC.
+ Action TBL: Get a reply from the IETF on the
TAG finding.
DC: TimBL proposed this for June IETF/W3C meeting.
Didn't get far then.
DC: We are next meeting 12 November.
SW: I'm not sure what our best course of
action is here. Either a mid-November backstop
or a possible forum (W3C CG) before then.
SW: Do we need to be more active than that?
DC: I'm at a loss.
SW: Then I propose that we try to get on
agenda of CG first, or next IETF/W3C meeting
otherwise.
2.5 RFC3023Charset-21
1. Action CL: Send copy of information sent to tag
regarding RFC3023Charset-21 to www-tag. (Open)
2.6 URIEquivalence-15
1. Status of URIEquivalence-15. Relation to
Character Model of the Web (chapter 4)? See text
from TimBL on URI canonicalization and email from
Martin in particular.
TB: This is serious. Martin seems to be saying
"deal with it"
DC: Two reasons:
1. The only way you can be sure that a consumer
will notice that you mean the same thing is
that you've spelled it the same way. I think
that they're not wrong. Nothing wrong with
string compare.
2. In general, it's an art to gather that
something spelled differently means the same
thing.
TB: If we believe that, should there be a
recommendation that "when you do this, only
%-escape when you have to, and use lowercase
letters." Where should that be written?
DC: Shortest path to target is the I18N WG.
RFC 2396 applies equally to all URI schemes.
Generating absolute from relative URI is not
scheme-specific.
DO: There are absolutization scheme(s) and
things like scheme-specific rules (e.g.,
generating an absolute) and we should take
this into account when we talk about doing a
string compare.
RF: Different issues here. There is a syntax
mechanism to go from rel URI to abs URI. But
no scheme-specific semantics on that. There
are scheme-specific fields (e.g,. host name)
that have equivalence rules. It boils down to
this: the most efficient way to deal with
these cases is to require a canonical form and
compare by bytes.
[DanC]
There's stuff like http://www.w3.org:80/ and
http://www.w3.org/ , which are specified, in a
scheme-specific manner, to mean the same
thing.
[Ian]
DO: So, canonicalize according to scheme and
generic rules, then compare.
RF: The only entity that does the
canonicalization is the URI generator; not at
comparison time. Inefficient to canonicalize
at compare time.
[Ian]
RF: Making a URI absolute is
scheme-independent. That's required so we can
add schemes later on.
DC: There was a backlash in the XML community
about saying absolutize.
TB: That was a different issue.
DC: I don't understand the difference.
DO: Namespaces used as identifiers rather than
for dereferencing. Requiring absolute URIs was
meant to facilitate authoring.
TB: I hear people arguing that string
comparison necessary. I think there needs to
be a statement of principle to get good
results:
1. Don't use %-escape unless you have to.
2. Yse lowercase when doing so.
TB: Where do we take these suggestions?: (a)
We have a section on the arch doc on comparing
URIs or (b) ask I18N WG to deal with this.
RF: Or add a stronger suggestion to the URI
spec itself.
TB: That's a wonderful answer!
RF: I can add this to the issues list (section
on URI canonicalization). I can't promise that
it will be answered there.
DC: I don't think we should punt this
entirely. For URIs, it's fine to do string
compare. For URI references, it's fine to
absolutize and then do string compare. That
works for me.
SW: I agree with TB that we should have
something in arch doc. That should be in sync
with the emerging URI spec.
DO: How about as little as "there are good
rules for doing this; go see the URI spec and
the IRI specs for more info..."
[DanC]
"Can the same resource have different URIs?
Does http://WWW.EXAMPLE/ identify the same
resource as http://www.example/?"
-- FAQ on URIs
[Ian]
DC: Is it useful to do a finding in the mean
time?
IJ: I hope to harvest from Dan's FAQ.
TB: I think that if in arch doc, probably
don't need a finding.
Action IJ: Harvest from Dan's FAQ for arch
document.
Resolved: the Arch Doc should mention this issue.
2.7 Postponed
1. Status of discussions with WSA WG about
SOAP/WSDL/GET/Query strings?
+ ACTION DO 2002/06/24: Contact WSDL WG about
this issue (bindings, query strings and
schemas) to ensure that it's on their radar.
See discussions from 24 Jun TAG teleconf.
2. augmentedInfoset-22:
+ Request from Tim Bray to decide this issue
(disposition = closed). Pushback from Simon
St. Laurent.
+ ACTION DC 2002/06/17: Talk to XML Schema WG
about PSVI. Report to tag, who expects to
decide whether to add as an issue next week.
DanC has sent email; awaiting reply from XML
Scheme WG.
________________________________________________
Ian Jacobs, for TimBL
Last modified: $Date: 2002/07/23 22:20:09 $
Received on Tuesday, 23 July 2002 18:26:20 UTC