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
- Roll call: SW, DC, IJ, PC, NW, TB, RF. Regrets: CL, TBL, DO (on
IRC)
- Accepted 15 July minutes
- Next meeting: 29 July. Regrets: NW, SW. Possible regrets: DO, PC
- Confirmed status of completed
actions
- September meeting arrangements
Action TB: Send information about hotels
to TAG.
- Action TB: 2002/07/15: Clarify sentence on what an HTTP URI refers to.
(Done)
1.3 New issues?
- Accepted as issue contentTypeOverride-24: Overriding HTTP content-type
with a URI reference.See
email from TBL.
- 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
[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.
- [Ian]
- # 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:
- Action CL 2002/07/08: Propose text for section 2 (Formats). Deadline 30
July.
- Action IJ 2002/07/08: Produce WD of Arch Doc. Deadline 30 August.
See also: findings.
- Internet media type registration, consistency of use.
- Qnames as identifiers:
- Formatting properties:
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.
- 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.
- Action CL: Send copy of information sent to tag regarding RFC3023Charset-21
to www-tag. (Open)
- 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:
- 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.
- 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:
- Don't use %-escape unless you have to.
- 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.
- Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
- 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 $