IRC log of tagmem on 2003-06-09

Timestamps are in UTC.

18:50:41 [RRSAgent]
RRSAgent has joined #tagmem
18:57:46 [Ian]
zakim, call Ian-BOS
18:57:47 [Zakim]
ok, Ian; the call is being made
18:57:48 [Zakim]
TAG_Weekly()2:30PM has now started
18:57:49 [Zakim]
18:58:03 [Ian]
zakim, who's here?
18:58:03 [Zakim]
On the phone I see Ian
18:58:04 [Zakim]
On IRC I see RRSAgent, Zakim, Roy, Stuart, ChrisDinnerHopefu, Ian
18:58:41 [Zakim]
18:58:49 [Ian]
zakim, ??P0 is Roy
18:58:49 [Zakim]
+Roy; got it
18:58:50 [Zakim]
19:00:44 [TBray]
TBray has joined #tagmem
19:01:17 [Zakim]
19:01:37 [Stuart]
Zakim, ??P2 is me
19:01:37 [Zakim]
+Stuart; got it
19:01:53 [Zakim]
19:03:14 [TBray]
interesting numbers from xml-dev:
19:03:32 [tim_mit]
tim_mit has joined #tagmem
19:03:47 [TBray]
Comparison (number of printed pages of the specification)
19:03:57 [Zakim]
19:04:00 [DanC]
DanC has joined #tagmem
19:04:02 [TBray]
xPath 1.0 xPath 2.0 increase
19:04:12 [TBray]
45 254 564%
19:04:14 [Ian]
zakim, who's here?
19:04:14 [Zakim]
On the phone I see Ian, Roy, Norm, Stuart, Tim_Bray, TimBL
19:04:15 [Zakim]
On IRC I see DanC, tim_mit, TBray, RRSAgent, Zakim, Roy, Stuart, ChrisDinnerHopefu, Ian
19:04:22 [Zakim]
19:04:50 [Zakim]
19:05:17 [Ian]
IJ will Scribe, SW will chair, NW will walk through arch doc?
19:05:30 [tim_mit]
Zakim, who is here?
19:05:30 [Zakim]
On the phone I see Ian, Roy, Norm, Stuart, Tim_Bray, TimBL, DanC (muted), David_Orchard
19:05:32 [Zakim]
On IRC I see DanC, tim_mit, TBray, RRSAgent, Zakim, Roy, Stuart, Chris, Ian
19:05:41 [Ian]
Roll call: SW, IJ, RF, NW, TB, TBL, DC, DO.
19:05:45 [Ian]
CL about to join
19:05:47 [Ian]
Missing: PC
19:06:02 [Ian]
Accept minutes of 12 May teleconf?
19:06:10 [Ian]
19:06:39 [Ian]
RF: Look ok to me
19:06:43 [Norm]
Norm has joined #tagmem
19:06:46 [tim_mit]
Meeting schedules for 2.5 hours
19:06:54 [Ian]
No objections to accepting 12 May 2003 minutes
19:07:00 [Ian]
Accept minutes of 2 June teleconf?
19:07:06 [Ian]
19:07:18 [Ian]
TB: Ok (since IJ added missing action items)
19:07:22 [Zakim]
19:07:31 [DanC]
2Jun record ok. $Date: 2003/06/09 12:48:02 $
19:07:31 [Ian]
PC joins the call
19:07:35 [Roy]
19:07:37 [Ian]
zakim, ??P6 is Paul
19:07:37 [Zakim]
+Paul; got it
19:07:38 [Chris]
zakim, dial chris-work
19:07:38 [Zakim]
ok, Chris; the call is being made
19:07:38 [Zakim]
19:07:44 [Ian]
[All present]
19:07:55 [Ian]
This agenda:
19:08:09 [Ian]
Arch doc starting approx at section 3.2 of Arch Doc:
19:08:15 [Ian]
19:09:20 [DanC]
ack danc
19:09:21 [Zakim]
DanC, you wanted to consider IETF/W3C prep agenda item
19:09:31 [Ian]
DC: IETF/W3C teleconf is 17 June.
19:09:41 [Ian]
DC: Might talk about mime types.
19:09:56 [Ian]
DC: Do you want anything on that agenda?
19:10:09 [Ian]
TB: We wanted them to provide web space and canonical URIs for mime types.
19:10:21 [Ian]
agenda+ IETF/W3C meeting
19:10:29 [Ian]
zakim, who's talking?
19:10:40 [Zakim]
Ian, listening for 10 seconds I heard sound from the following: Stuart (90%), Tim_Bray (27%), TimBL (19%), Paul (5%), DanC (24%), Chris (82%)
19:10:49 [Ian]
Next meeting: 16 June. Regrets PC.
19:11:23 [Chris]
19:11:35 [Ian]
zakim, mute Chris
19:11:35 [Zakim]
Chris should now be muted
19:11:51 [Chris]
zakim, drop chris
19:11:51 [Zakim]
Chris is being disconnected
19:11:52 [Zakim]
19:11:57 [Ian]
SW: Any desire to generally extend meeting to 2hours?
19:11:59 [Ian]
DC: No
19:12:04 [Ian]
TB, PC: Yes
19:12:06 [Chris]
19:12:12 [Ian]
IJ: No
19:12:32 [Ian]
TB: I'd rather add time if we have matter of great urgency.
19:12:35 [Zakim]
19:12:36 [Ian]
DC: DItto
19:12:41 [Ian]
NW: Ditto
19:13:09 [Ian]
DO: Ok with going to 2 hours.
19:13:16 [Ian]
CL: Ok to go to 2 hours
19:13:26 [Zakim]
19:13:43 [Zakim]
19:13:49 [Ian]
zakim, ??P5 is David
19:13:49 [Zakim]
+David; got it
19:14:08 [Ian]
19:14:11 [Ian]
zakim, take up agendum 1
19:14:11 [Zakim]
agendum 1. "IETF/W3C meeting" taken up [from Ian]
19:14:26 [Ian]
DC: IETF/W3C meet 17 June
19:14:45 [Chris]
q+ to ask abou IDNA and process stuff
19:14:51 [TBray]
where's that IANA/IETF mime-type directory?
19:15:14 [Ian]
DC: Maintaining "tidy uris" - promise to keep http URIs to mime types and to give 1 year notice if they will change.
19:15:16 [Chris]
q+ to also ask about URI mime registry and correct forum
19:15:26 [TBray]
q+ to say they had done that but not to our satisfaction
19:15:31 [Ian]
DC: Another issue is I18N URIs.
19:15:39 [Chris]
ack chris
19:15:39 [Zakim]
Chris, you wanted to ask abou IDNA and process stuff and to also ask about URI mime registry and correct forum
19:16:07 [Ian]
CL: Is talking to Ned Freed the correct forum for pushing for tidy URIs?
19:16:12 [Ian]
[CL has an action item]
19:16:40 [Ian]
DC: Norm in IETF is to address author. In general, ok to cc public w3c/ietf mailing list
19:16:52 [Ian]
CL clarifying: Is our action the same?
19:17:24 [Ian]
TB: As I recall, DC had sent us a place in IETF land where all the mime types were on one page. However, as I recall, it was only really halfway there.
19:18:03 [Ian]
19:18:11 [Ian]
TB: I think CL had accurately described the pbs
19:18:20 [Ian]
CL email:
19:18:35 [Ian]
CL will send to Ned Freed?
19:18:46 [Ian]
DC: Ned is editing the policy that says they have to do it right.
19:18:56 [Ian]
DC: Make it policy through NF.
19:19:08 [Ian]
CL email:
19:19:08 [Ian]
Message-ID: <>
19:19:08 [Ian]
19:19:08 [Ian]
19:19:23 [Ian]
CL: I'll forward to w3c/ietf liaison list.
19:19:36 [DanC]
19:19:38 [DanC]
19:20:11 [DanC]
if you mail me about IETF/W3C business, pls copy
19:20:20 [Ian]
DC: Please read NF's policy document.
19:20:26 [Ian]
CL: I have read that.
19:20:40 [Ian]
DC: I pinged him to make a new draft; hoping he'll have one by 17 June
19:20:57 [Ian]
CL: What about i18n domain names?
19:22:03 [Ian]
RF: I18N domain names are done: IDNA is done
19:23:04 [Ian]
19:23:11 [Ian]
Internationalizing Domain Names in Applications (IDNA)
19:23:16 [Ian]
RF: See also RFC 3491
19:23:30 [Ian]
Category: Standards Track
19:23:41 [Ian]
19:23:51 [Ian]
SW: What about talking about URLs/URNs at 17 June mtg?
19:23:59 [Ian]
DC: No urgency for 17 June meeting
19:24:02 [Ian]
19:24:31 [TBray]
URL = Universal Republic of Love
19:24:48 [Chris]
19:25:10 [Chris]
URN=not liked, URC=not implemented, thus URI== URL
19:25:13 [Chris]
19:25:16 [Ian]
IJ: We don't have an issues list issue.
19:25:23 [TBray]
neat trick since URL and URC don't exist...
19:25:44 [Chris]
oh, *minor* issue of detail ;-)
19:25:47 [DanC]
hmm... the interaction didn't bubble up into an issue? oops.
19:26:25 [Ian]
DC: I can tell the IETF that we have some activity going on around this topic (though no formal issue).
19:26:38 [Ian]
zakim, close this agendum
19:26:38 [Zakim]
agendum 1 closed
19:26:39 [Zakim]
I see nothing remaining on the agenda
19:26:42 [Ian]
19:26:45 [Ian]
19:26:48 [Ian]
Arch Doc walkthrough
19:26:58 [Ian]
19:27:26 [Ian]
19:27:33 [Ian]
[Section 3.2]
19:28:24 [Ian]
[Reviewing where we were in 3.1]
19:28:47 [Ian]
At end of meeting last week we were talking about references to 2396bis.
19:29:42 [Ian]
CL: I request that we ignore IRIEverywhere-27 for this teleconf.
19:29:54 [Ian]
CL: I expect to send in some clarifying material soon.
19:30:42 [Ian]
RF: Move the IRI bit (whatever it says) to a "Future directions" section for this leg of the tripod.
19:30:45 [Ian]
[Some agreement]
19:31:09 [Ian]
3.2 URI Schemes
19:31:36 [Ian]
RF: I rewrote this in 2396bis. Looks like first three paras of arch doc (but more accurate than arch doc)
19:31:55 [Ian]
RF: Text in rfc2396bis is more specific about role of schemes.
19:32:16 [TBray]
19:32:22 [Ian]
DC: I'm not thrilled about idea of cutting the text.
19:32:33 [Ian]
RF: I suggest reusing RFC2396bis text and including reference.
19:32:47 [Ian]
TB/PC: Why redundancy here valuable?
19:32:53 [Stuart]
19:33:28 [Roy]
19:33:38 [Roy]
19:33:49 [Roy]
ignore those URIs
19:34:08 [Ian]
1.1.1 Examples
19:34:16 [Ian]
19:34:47 [Stuart]
19:35:04 [Roy]
19:35:43 [Ian]
DC: The URI draft says "mailto scheme for email addresses" but says that "news is for usenet groups/articles". Please harmonize types in the list of examples
19:35:54 [Roy]
ach URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.
19:35:57 [Ian]
(e.g., mailboxes/files/newsgroups)
19:36:09 [Ian]
19:36:56 [Ian]
RF: More specific - "URIs ARE classified by scheme"
19:37:26 [Chris]
sounds like keyboard/mic too near desk issues
19:38:00 [Ian]
Action IJ: compare 3.2 text with RFC2396 version 3; compare and harmonize; leaving about the same amount of text.
19:38:40 [Ian]
TB: In section 3.2, important thing is "New URI schemes". SO make sure that: (1) reader understands what a scheme is (2) reader has correct reference to URI spec.
19:39:39 [Ian]
RF: I think TBL and perhaps DC would like to emphasize the para I copied in - in the sense that one specification leads to another....
19:39:44 [DanC]
er... "layering"?
19:40:19 [Ian]
TB: Problematic to use myscheme: blort since there's no place to go look for it.
19:40:23 [Roy]
yep, layered specifications
19:41:00 [Ian]
[Discussion about new URI schemes]
19:41:18 [Ian]
DC: They are extensible, locally.
19:41:24 [Ian]
(e.g., on my machine)
19:43:49 [Norm]
19:43:54 [Chris]
q+ about 'proprietary'
19:44:06 [TBray]
19:44:08 [Ian]
DC: We don't have a cogent argument in our doc against creation of new uri schemes. E.g., if you are Apple, deploying new URI schemes is easy.
19:44:14 [Ian]
(since Apple controls desktop)
19:44:37 [Ian]
q+ PC
19:44:41 [Ian]
ack PC
19:44:50 [Ian]
19:44:57 [Ian]
ack TBray
19:45:08 [Chris]
would writing an rfc saying 'this is http spelled different' make it non-proprietary
19:45:12 [Norm]
q- about
19:45:17 [Norm]
q- 'proprietyar'
19:45:21 [Norm]
q- 'proprietary'
19:45:53 [DanC]
yes, bray's got it right here... 'if it has an existing name, use that name' derivable from network-effects principle
19:46:14 [Ian]
TB: I think the apple thing is a test case. The reason it's the wrong thing do to is that the information is available by HTTP (music store responds to http requests). Despite that fact they identified with a new URI scheme. It's bad since I could have shared HTTP uri with more people.
19:46:19 [Chris]
okay. what if its a defined http subset, like a get-only
19:46:29 [Chris]
q+ to ask about subsets
19:46:43 [Ian]
DC: "If it has an existing name, use it." This derives from the network effect principle.
19:46:48 [Ian]
19:46:50 [Ian]
q+ PC
19:46:50 [Roy]
We should focus on the need to register new schemes and the built-in reluctance in the IETF to allow registrations of schemes that do not add value over existing set.
19:46:55 [Ian]
ack DanC
19:46:55 [Zakim]
DanC, you wanted to comment on examples and to and to riff on multi-party motivation
19:46:56 [Roy]
19:47:06 [TBray]
put PC on the Q
19:47:16 [Stuart]
q Paulc
19:47:16 [TBray]
oh, someone did
19:47:18 [Ian]
DC: Apple should have keyed off of mime type. But in the calendar case, they wanted people to put ics files on the Web.
19:47:29 [Ian]
19:47:41 [Ian]
DC: Think globally.
19:47:44 [Ian]
ack Chris
19:47:44 [Zakim]
Chris, you wanted to ask about subsets
19:48:03 [Ian]
CL: Perhaps one reason they did this was to subset HTTP. That would be an advantage to a new scheme.
19:48:20 [Roy]
Answer: no, they wanted webdav URI as well.
19:48:21 [Ian]
ack PC
19:48:38 [Ian]
PC: What special processing do these scheme resources get?
19:48:39 [tim_mit]
webcal: is of course similar
19:48:46 [Ian]
TB: I'm pretty convinced that there's no different.
19:48:50 [Ian]
19:49:07 [Ian]
TB: Most of the xml downloaded (Before encryption) had to do with presentation.
19:49:24 [DanC]
wierd! why is "only two tags, key and value" stupid, but RPV is better than RDF/XML syntax?!?!?!
19:49:46 [tim_mit]
19:49:52 [Chris]
q+ to point out that new schemes fits with rhe upcoming component extensions work
19:50:15 [Ian]
TB: They should have published standard HTTP URIs for these resources and registered a mime type for the weird xml.
19:50:27 [Ian]
PC: So we are saying - don't create URI scheme; register your mime type.
19:50:36 [Ian]
19:50:38 [Ian]
19:50:57 [Ian]
q+ to ask about comparative costs (is it less expensive to register mime types?)
19:51:03 [tim_mit]
19:51:04 [Ian]
ack Roy
19:51:15 [Ian]
RF: The registration process for URI schemes is being revised.
19:51:41 [tim_mit]
q+ to discuss why it is harder to do it with a new mime type, and therefore to suggest comments on the software architecture which follows.
19:51:43 [Ian]
RF: In any case, we should emphasize in this section that the URI schemes have to be registered. Part of the registration process for URI schemes is MORE STRICT than the one for mime types.
19:51:53 [DanC]
strict registration process for schemes won't make them more likely to get registered. :-{
19:51:53 [TBray]
19:51:58 [DanC]
ack chris
19:51:58 [Zakim]
Chris, you wanted to point out that new schemes fits with rhe upcoming component extensions work
19:52:06 [Ian]
RF: IETF rejects proposed schemes if deemed that they serve no useful purpose.
19:52:12 [Ian]
CL: Component extensions work at W3C.
19:52:18 [TBray]
Rumor is that they did this because Safari's mime-type dispatching is horribly inflexible
19:52:38 [Stuart]
19:52:42 [Ian]
19:52:45 [Roy]
yes, webdav: was rejected for that reason
19:52:45 [Ian]
ack tim_mit
19:52:45 [Zakim]
tim_mit, you wanted to discuss why it is harder to do it with a new mime type, and therefore to suggest comments on the software architecture which follows.
19:53:13 [DanC]
which scenario are you speaking to, timbl? webcal: or items:?
19:53:18 [Roy]
DAV: was not rejected
19:53:22 [Ian]
TBL: It comes down to your software architecture. A typical dispatcher either (1) munges internally or (2) downloads and figures out what software to run on it.
19:54:13 [Ian]
TBL: Apple registry may split "application" v. "extension" (like old days)
19:54:45 [DanC]
aha! of course! we need http-head:// vs. , right, Ian?
19:54:46 [Ian]
TBL: One problem is two links that refer to the same thing (e.g., webcal v. http URIs which mean different things (different verbs for different uri schemes))
19:54:49 [DanC]
19:55:27 [Roy]
How does this discussion result in text for webarch?
19:55:43 [DanC]
the subscribe vs. copy choice is much like the "new window" vs "new tab" vs same-window choice.
19:55:48 [Chris]
it relates to 'don't make new schemes unless you need to'
19:55:56 [Ian]
19:55:58 [Ian]
ack TBray
19:56:02 [Ian]
TB summarizing:
19:56:11 [Ian]
1) Gratuitous invention of URI schemes is not a good idea.
19:56:20 [Chris]
it still sounds like different schems, like get vs something else, to me
19:56:35 [Chris]
subscribe is clearly having a side effect and should not use get method
19:56:36 [Stuart]
19:56:36 [tim_mit]
2) Gratuitous invention of RDF is not a good idea.
19:56:40 [Ian]
TB: 2) State what the decision criteria are that would strengthen or weaken the attractiveness of a new URI scheme.
19:57:06 [tim_mit]
on these two laws hang all the law and the prophets. ;-)
19:57:10 [Ian]
TB: The interaction in apple case is HTTP; no functions required that can't be done in HTTP; and wider applicability a good thing => use HTTP uri scheme.
19:57:42 [Ian]
TB: If you want a URI and if scheme exists that meets your needs and
19:58:01 [Ian]
there is a requirement for usage across wide range of users/applications, then don't invent new one.
19:58:34 [DaveO]
DaveO has joined #tagmem
19:58:36 [Ian]
SW: Any value in enumerating what the costs are?
19:58:42 [Ian]
19:58:45 [Ian]
ack Stuart
19:59:33 [Ian]
ack Ian
19:59:33 [tim_mit]
q+ to suggest text for document along the lines that "Client-side flexibility in the dispatching of new MIME types should be suficiently powerful to allow new MIME types to introduce the necessary functionality"
19:59:59 [Ian]
TB: Even if URI being invented for private reasons, usually one finds public reasons.
20:00:10 [Ian]
IJ: Point to deep linking finding as well (basically "Keep your options open.")
20:00:31 [Ian]
IJ: Sell it as a benefit - this keeps your options open!
20:00:35 [Ian]
ack tim_mit
20:00:35 [Zakim]
tim_mit, you wanted to suggest text for document along the lines that "Client-side flexibility in the dispatching of new MIME types should be suficiently powerful to allow new
20:00:38 [Zakim]
... MIME types to introduce the necessary functionality"
20:01:26 [Ian]
[TBL: They could have introduced itunes as a sherlock plug-in]
20:02:20 [tim_mit]
ack tim
20:02:31 [Ian]
TBL say:
20:03:00 [Ian]
1) Dispatching on mime types is a useful thing
20:03:53 [Ian]
2) We should write up the webcal story or the itunes story in a finding.
20:04:02 [Ian]
Explain why you lose when you do it that way,
20:04:13 [tim_mit]
(ituines or webcal)
20:04:17 [DanC]
hear hear. stories to supplement principles
20:04:37 [Ian]
20:04:45 [Ian]
1) Identify different ways of achieving extensibility
20:04:53 [Ian]
2) relative costs
20:06:27 [Ian]
TBL: Can we have a finding on this?
20:06:45 [Ian]
TBL: Can TB provide this text as a finding?
20:06:49 [Ian]
TB: Sure, go ahead.
20:07:05 [TBray]
20:07:30 [Ian]
DC: Tell a story in the finding and seek a balance between finding an arch doc.
20:07:35 [TBray]
but no more XML (sob):
20:07:37 [Ian]
Action IJ: Turn TB apple story into a finding.
20:07:48 [Ian]
RF: On editor's note at end of 3.1?
20:08:08 [Ian]
RF: On editor's note at end of 3.2?
20:08:45 [Ian]
RF: I think we should talk about this, and that it should be in another section.
20:08:52 [Ian]
(this = authority component)
20:09:01 [Ian]
RF: Somewhere we should talk about how URIs are allocated.
20:09:12 [Ian]
RF: Some are allocated using their own mechanisms; most are via authority delegation.
20:09:57 [Ian]
RF: See 3.2 of RFC2396bis for info about authority info
20:10:20 [Ian]
20:10:33 [Ian]
RF: URI spec doesn't really talk about the social aspects of delegating name allocation.
20:10:49 [Ian]
RF: We should probably create a new toplevel section (3.x) on name allocation.
20:10:58 [Ian]
20:11:22 [TBray]
any chance of a 10min coffee break?
20:11:39 [Ian]
IJ: I'd like to make connection between meaning of resource and authority over that meaning.
20:12:41 [DanC]
coffee break... I'm losing steam too
20:12:46 [Ian]
RF: "Allocating URIs"
20:13:11 [Ian]
Action IJ: add a new 3.x section on allocating URIs; taking some text from rfc2396bis/3.2 and expanding slightly on social aspects.
20:13:29 [Ian]
[End of 3.2]
20:13:35 [Ian]
20:13:41 [Zakim]
20:13:42 [Zakim]
20:13:42 [Zakim]
20:13:43 [Zakim]
20:13:44 [Zakim]
20:13:45 [Zakim]
20:13:48 [DanC]
Zakim, remind us in 7 minutes to resume
20:13:48 [Zakim]
ok, DanC
20:16:26 [Ian]
zakim, drop Ian
20:16:26 [Zakim]
Ian is being disconnected
20:16:27 [Zakim]
20:17:32 [Ian]
zakim, dial Ian-BOS
20:17:32 [Zakim]
ok, Ian; the call is being made
20:17:33 [Zakim]
20:17:40 [Zakim]
20:19:10 [Norm]
zakim, who is on the phone?
20:19:10 [Zakim]
On the phone I see Norm, TimBL, Paul
20:20:04 [Zakim]
20:20:38 [Zakim]
20:20:48 [Zakim]
DanC, you asked to be reminded at this time to resume
20:20:49 [Stuart]
zakim, ??p2 is me
20:20:49 [Zakim]
+Stuart; got it
20:21:02 [Chris]
zaim, tbray was not talking to you ;-)
20:21:07 [Zakim]
20:21:18 [Ian]
zakim, dial Ian-BOS
20:21:18 [Zakim]
ok, Ian; the call is being made
20:21:19 [Zakim]
20:21:25 [Zakim]
20:21:31 [Ian]
zakim, dial Ian-BOS
20:21:31 [Zakim]
ok, Ian; the call is being made
20:21:32 [Zakim]
20:21:39 [Stuart]
zakim, who is on the phone
20:21:39 [Zakim]
I don't understand 'who is on the phone', Stuart
20:21:47 [Zakim]
20:21:51 [Zakim]
20:21:53 [Zakim]
20:22:11 [Roy]
zakim, ??P5 is Roy
20:22:11 [Zakim]
+Roy; got it
20:22:15 [Zakim]
20:22:37 [Norm]
zakim, who is on the phone?
20:22:37 [Zakim]
On the phone I see Ian, Norm, TimBL, DanC, Paul, ??P0, Stuart, Chris, Roy
20:22:42 [Chris]
zakim, who is here?
20:22:42 [Zakim]
On the phone I see Ian, Norm, TimBL, DanC, Paul, ??P0, Stuart, Chris, Roy
20:22:44 [Zakim]
On IRC I see DaveO, Norm, DanC, tim_mit, TBray, RRSAgent, Zakim, Roy, Stuart, Chris, Ian
20:23:23 [TBray]
Dave, you there?
20:23:59 [Ian]
3.3. Fragment identifiers
20:24:09 [tim_mit]
Stop the train? The RDF spec does not have to do anything other than say that the thing identified is that identified by a URI. The URI spec than says what you can say about what they identify.
20:24:30 [tim_mit]
20:24:31 [DanC]
(wrong channel?)
20:24:34 [Ian]
TB: There's lots of new stuff in rfc2396bis. Notion of a "Secondary Resource"
20:24:49 [Ian]
Section 3.5 in rfc2396bis
20:24:59 [Ian]
20:25:12 [Ian]
"The fragment identifier component allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information that is selective within that resource."
20:26:48 [Ian]
TBL: I don't like the piece in the arch doc about "part or view"
20:27:10 [Ian]
Action IJ: Integrate RF's 3.5 into arch doc section 3.3.
20:27:44 [Ian]
TB: For RF's 3.5, there are some issues related to RDF.
20:28:13 [Ian]
TB: I'll send some text; I think people will disagree with "frag id identifies something selective within a resource"
20:28:49 [Ian]
20:29:03 [Zakim]
20:30:00 [Ian]
IJ: Recall that I will be trying to keep one story throughout arch doc; I will probably do some combination of RF text + adding to the first scenario in the arch doc.
20:30:10 [DanC]
before leaving RFC2396bis, shall we acknowledge RoyF's 2 week 'last call' ish new-issue deadline, please, Norm/Stuart?
20:30:43 [Norm]
Yes, DanC
20:30:50 [Ian]
TBL (about RFC2396bis) : The secondary resource (identified by a thing with a #) is, like the primary resource, is determined by the naming authority.
20:31:51 [Ian]
TBL: There should be consistency between primary and secondary resources.
20:32:05 [Ian]
TBL: Just because you may not have a representation yet; the resource still exists.
20:32:22 [Ian]
RF to TBL: Please read 3.5 soon to let me know if you're happy.
20:32:56 [Ian]
RF about RFC2396bis: If draft hasn't changed in 2 weeks, then submitted to IESG for last call (for an internet-wide last call).
20:33:04 [Ian]
RF: I don't expect technical changes at this point.
20:33:23 [Ian]
RF: If there are minor wording changes, I'll produce a version 04 and then there will be an immediate draft to IESG.
20:33:34 [Ian]
RF: PLEASE make comments soon (within 2 weeks)
20:33:59 [Ian]
RF: 2-week period ends 23 June
20:34:55 [DanC]
RFs request was ackowledged by the chair.
20:35:23 [tim_mit]
TBL: There should be consistency between the idenity of primary and secondary according to the authority and any infromation returned in response to the dereferencing of the primary URI.
20:35:28 [Ian]
3.4. Dereferencing a URI
20:35:54 [Ian]
DC: Status of metadataInURI-31?
20:36:03 [Ian]
SW: I did a first draft of finding; haven't worked on it lately.
20:36:32 [Ian]
SW: There are various observers of URIs (e.g., origin server) and various parts of URIs that may be more or less opaque depending on the observer.
20:36:49 [Ian]
DC: Is your expectation of having finding done by end of June?
20:36:58 [Ian]
SW: I'd like to have finding in shape for our July mtg.
20:37:04 [Ian]
20:37:16 [Ian]
SW: I have comments to integrate before sending to www-tag.
20:37:35 [Ian]
ack Ian
20:37:36 [Norm]
20:38:37 [Ian]
IJ: Big things won't happen for arch doc before end of June.
20:38:48 [Ian]
IJ: I can have a good draft for ftf meeting.
20:40:15 [DanC]
yeah... it's a real bummer for us to have these marathon meetings only to have the editor say "hold that thought for 2 weeks"
20:40:16 [Ian]
20:40:47 [Ian]
NW: Push story in 3.4.1 to earlier in 3.4
20:41:26 [Ian]
NW: Move up "All important resources SHOULD be idnetified by a URI" since not about representations.
20:41:29 [Ian]
TB: Yes, move to the top.
20:41:59 [Ian]
IJ: Ok, I'll move that note higher up in the doc.
20:42:04 [Ian]
TB: Put it in 3. (before 3.1)
20:42:43 [Ian]
TB: Under 3.4.2, put in the example of the bank account.
20:43:54 [Ian]
TB: When you say "Yes, charge my credit card for the ticket to Oaxaca" to expand on scenario in section 1.
20:44:30 [Ian]
IJ: I can steal some text from finding to flesh out 3.4.2 a bit; it's barren as it stands.
20:45:41 [Ian]
TB: Leave 3.4.3 with reference to deep linking finding.
20:46:00 [Ian]
NW: Move 3.4.3 up (talk about identification without access before talking about access)
20:46:03 [Ian]
20:46:16 [Ian]
3.4.4 Servicing a URI
20:46:31 [Ian]
TB: Please include the word "persistence" in the title of 3.4.4
20:46:32 [Ian]
NW: Yes.
20:46:41 [Ian]
NW: I'd like a different title for 3.4.4
20:46:51 [TBray]
"predictability"? "consistency"?
20:48:37 [Ian]
Resource persistence and representation consistency
20:49:14 [Ian]
TB: Seems ok.
20:49:39 [Ian]
RF: Consistency
20:49:45 [Ian]
TB: Consistency
20:50:07 [Ian]
NW: I think should be moved to 3.5 instead of 3.4.x
20:50:31 [Ian]
TB: Another case is use of namespace name for different things over time.
20:51:32 [Ian]
TB: Leave moby dick example unless you can cover all the bases with expanded scenario.
20:51:40 [Ian]
[Some agreement to move 3.4.4 to 3.5]
20:51:58 [Ian]
RF: Add 3.6 - future directions.
20:52:05 [Ian]
* IRIs
20:52:22 [Ian]
* Things that are not administrative hierarchies
20:52:51 [Ian]
IJ: XPointer?
20:52:52 [DanC]
20:53:13 [Ian]
TB: What about the IETF work on making URNs dereferenceable?
20:53:31 [Ian]
DC: Yes - see mark baker/dan connolly draft which talks about this.
20:53:45 [DanC]
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
20:53:45 [DanC]
One: The Comprehensive DDDS", RFC 3401, October 2002.
20:53:50 [DanC]
20:54:54 [Ian]
TB: Anything in 3.4.4 (or three generally) that at the current time clashes with either TBL or RF view of what a resource is?
20:55:46 [Ian]
RF: This text mixes up resource metadata and representation of the resource.
20:56:07 [Ian]
RF: Odd to see consistency of representations mixed with consistency of metadata; perhaps create a subsection for each.
20:56:18 [Ian]
RF: Consistency of both is a good thing.
20:57:37 [Ian]
TBL: Fine by me to say that 2 URIs can identify the same resource.
20:57:51 [Ian]
20:58:03 [Chris]
how do you know - only by dereferencing and comparing the resources?
20:58:13 [Chris]
20:58:25 [Ian]
TB: If people are basically ok with section 4, we are within spitting distance of a coherent publishable document.
20:58:56 [Ian]
TB: How do we get to last call?
20:59:00 [Ian]
20:59:54 [Ian]
DO: Question of scope of arch doc: Whether to include more on sem web and web services or not.
21:00:22 [TBray]
what TimBL said
21:00:31 [Ian]
TBL: I think we should go ahead with last call if we are happy with what we have.
21:00:44 [Ian]
21:00:56 [Chris]
q+ to talk about loaded questions
21:01:05 [DanC]
I think there's an attainable WD target in the near term. maybe that's so obvious that it's boring.
21:01:20 [Chris]
but still worth stating
21:01:31 [Stuart]
21:01:47 [Ian]
TBL: We have got a subset. I think that DO is right that our scope includes Web Services, etc., but I don't think we save time by not publishing a last call.
21:01:56 [Ian]
21:02:13 [Ian]
TB: I think that we need to take this through last call to get people to read seriously and have a stake in the ground.
21:02:20 [DaveO]
21:02:37 [Ian]
TB: I can't imagine that it would be good to leave it in WD h.
21:02:38 [Ian]
ack Chris
21:02:38 [Zakim]
Chris, you wanted to talk about loaded questions
21:02:45 [Ian]
q+ PC
21:02:55 [Ian]
CL: I agree we should take it to first last call.
21:03:44 [TBray]
21:04:00 [Ian]
CL: Might take a subset of the doc to Rec and work on rest separately.
21:04:04 [Ian]
ack DaveO
21:04:13 [Ian]
DO: Why ask the AC what they want?
21:04:31 [Ian]
CL: Communication (what questions we face, tradeoffs we are considering making, awareness of our work)
21:04:32 [DaveO]
Ian, no. My question was "why did we ask the AC what they want".
21:05:03 [Ian]
DO: Some people brought up the issue of "last call". Have we closed all of our issues?
21:05:04 [Ian]
21:05:07 [Ian]
21:05:13 [tim_mit]
21:05:16 [Ian]
q+ to talk about nature of arch doc and relation to last call
21:05:21 [Ian]
ack PC
21:05:39 [Ian]
PC: I agree with DO; I think that there are a fair number of AC reps who want the arch doc to talk about web services and semantic web.
21:05:55 [Ian]
PC: If we decide that we have to put that info in the future directions sections, then I expect we'll get a bunch of comments.
21:06:57 [Ian]
PC: We'd need to indicate limits of doc in status section.
21:07:26 [Ian]
PC: Process Doc is a leading example of how to handle an evolving document (publish so often and cut off issues list)
21:07:27 [Ian]
21:07:39 [DanC]
I won't be party to any decision to go to "first last call". if "last call" is treated like crying wolf, it'll further lose value.
21:07:43 [Ian]
PC: the Adv. Board batches the effort.
21:08:22 [tim_mit]
q+ danc to say "I won't be party to any decision to go to "first last call". if "last call" is treated like crying wolf, it'll further lose value."
21:08:30 [Ian]
PC: I'd like to go forward with a first last call, but bring to the AC's attention that we haven't gotten as far as some AC reps might like.
21:08:33 [Ian]
ack DanC
21:08:33 [Zakim]
DanC, you wanted to noodle on last call before... what? before we ask the AC who said they're not interested in a document of this scope? and to say "I won't be party to any
21:08:36 [Zakim]
... decision to go to "first last call". if "last call" is treated like crying wolf, it'll further lose value."
21:08:42 [Ian]
DC: I think we have clearly conflicting advice.
21:09:11 [Ian]
DC: I'd like to declare victory at an early opportunity. If we go to last call, we should be ready to go to the next step.
21:09:48 [Ian]
DC: Not sure whether next step should be CR or PR.
21:09:57 [Roy]
q+, I was expecting to have: 5. Interaction -- 5.1 Hypertext -- 5.2 Web Services -- 5.3 Semantic Web
21:10:02 [Ian]
DC: We might be promising to "hold still" on the backward-looking part of the document.
21:10:06 [Chris]
first last call means we have no guarantee that we get to cr; clearly if all review is positive then we go to cr, but lots of review often means lots of feedback, often for the first time
21:10:09 [Roy]
21:10:26 [Ian]
DC: I would have hoped the AC would say -publish early publish often; but that's not the advice we got.
21:10:28 [Ian]
ack Roy
21:10:49 [Ian]
RF: The section of interactions will have (even in skeletal form), something on http, web services, and sem web.
21:11:05 [Ian]
RF: How those categories impact the notion of interaction.
21:11:19 [Ian]
RF: I am on hook to finish this section for next week.
21:11:26 [TBray]
21:11:30 [Ian]
TBL: I don't see how sem web part of interaction...
21:11:39 [Ian]
ack TBray
21:12:20 [Ian]
TB: Most of current arch doc result of 10 years experience.
21:12:43 [DanC]
21:12:45 [Ian]
TB: Not getting around the fact that as soon as we move to sem web and web services, our experience will be very different.
21:12:53 [Ian]
TB: Will be qualitatively different from what we have.
21:13:20 [DanC]
"quite" re semweb/web-svcs being newer
21:13:46 [Chris]
q+ to agree about the 'from experience' part but we don't have all that down yet
21:13:51 [Ian]
TB: We should get to a point where we think we've gotten to a point where we are happy with what we've written about how the thing works today; we owe that to the community.
21:13:55 [DanC]
where was tbray during the AC meeting? 1/2 ;-)
21:14:09 [Ian]
21:14:12 [Roy]
21:14:14 [Ian]
q+ PC
21:14:16 [Ian]
ack tim_mit
21:14:57 [Ian]
TBL: The Process Doc doesn't address this situation - half-completed document clashes with dfn of last call.
21:15:19 [Ian]
TBL: One possibility is to say, e.g., "last call on arch doc, part I"
21:15:47 [Ian]
TBL: We'll be working on parts I and II, but think last call on part I reasonable.
21:16:15 [Ian]
Part I: The Early Years
21:16:48 [Stuart]
ack Chris
21:16:48 [Zakim]
Chris, you wanted to agree about the 'from experience' part but we don't have all that down yet
21:16:51 [Ian]
Back when the web was broadcast out of a hamburg dance cave.
21:17:08 [tim_mit]
Part 1: The fellowship of the web
21:17:17 [Ian]
CL: Line through old / new stuff not that clear.
21:17:29 [Ian]
CL: People have been doing some aspects of web services for a long time
21:17:34 [tim_mit]
Part 2: The two layer cakes
21:17:58 [Ian]
CL: there is stuff that's not in the arch doc where we have experience but we haven't had time to work on it.
21:18:04 [Ian]
21:18:09 [Norm]
Part 2: The Web: Reloaded
21:18:28 [Ian]
ack Roy
21:18:35 [Ian]
ack PC
21:18:53 [DanC]
(btw... I'm hoping the I18N WG splits the charmod spec likewise; did we ask them to do that? have we gotten a reply?)
21:19:08 [Ian]
PC: Some TB text might be good rationale to take back to AC; why we are taking to last call now.
21:19:10 [Chris]
we did ask them and they did not reply
21:19:33 [Stuart]
21:19:34 [Chris]
actually I believe they said no unoffiially
21:19:36 [Ian]
PC: There are folks in Web Services area who want TAG's help in that area; would like to get us involved in that area sooner rather than later.
21:19:40 [tim_mit]
q+ to0 say that there is a lot of arch work already done in sw area which could be pointed to.
21:19:45 [Chris]
so we need to fget an official answer
21:19:51 [tim_mit]
q+ to say that there is a lot of arch work already done in sw area which could be pointed to.
21:20:17 [Ian]
PC: We need to respond to AC's signal
21:20:19 [Ian]
ack Stuart
21:20:35 [Ian]
SW: We have a WSARCH WG; I am not conscious of any issues that have been fed to us from that WG.
21:21:05 [Ian]
PC: We have had direct requests from other wgs in that activity (e.g., wsdl).
21:21:08 [Ian]
IJ: Issue 37
21:21:14 [DaveO]
21:21:26 [Ian]
IJ: Not to mention SOAP/GET
21:21:57 [Ian]
PC: If the TAG decides that it wants to go to LC, has a mandate to respond to the AC, set expectations about material we will cover and how.
21:22:03 [Ian]
ack tim_mit
21:22:03 [Zakim]
tim_mit, you wanted to say that there is a lot of arch work already done in sw area which could be pointed to.
21:22:51 [Ian]
TBL: Owl/RDF Core groups have done a bunch of architectural stuff.
21:22:56 [Ian]
21:23:00 [Ian]
ack DaveO
21:23:36 [Ian]
DO: I observe that we've had a couple of issues with web services groups; if we reacted quickly to questions from these groups we'd get even more questions.
21:24:07 [Ian]
DO mentions target resource attribute
21:24:46 [Ian]
DO: People that are in these communities aren't looking for TAG help on current issues in this area; we haven't expressed too much interest of being in those areas.
21:25:03 [Ian]
ack Ian
21:25:37 [Ian]
IJ to TBL: Send me data on arch info related to sem web if you'd like included in references section.
21:25:40 [Ian]
21:25:49 [Ian]
[Returning to schedule issue]
21:27:19 [Ian]
TB: I think that going to LC/CR/PR is good on a document. If we don't do that sometime, then we won't benefit.
21:27:32 [Ian]
21:27:59 [DanC]
ack danc
21:28:00 [Ian]
TB: If we have consensus that we would lke to get to LC sooner rather than later, then we should tell the AC and see if they are ok with that.
21:28:00 [Zakim]
DanC, you wanted to suggest a strawpoll on web arch part I in July timeframe
21:28:20 [Ian]
[straw poll]
21:28:32 [Ian]
July last call on arch doc part I?
21:28:39 [TBray]
21:28:41 [DanC]
21:28:42 [Norm]
21:28:44 [Chris]
21:28:45 [Ian]
21:28:46 [tim_mit]
21:28:51 [Ian]
(end of July!!)
21:28:58 [Stuart]
21:29:00 [Ian]
PC: Yes
21:29:05 [Roy]
I will be travelling almost all of June 19-July 24
21:29:19 [Ian]
21:29:31 [Norm]
21:29:37 [Roy]
21:29:45 [Ian]
DC: Anyone want to take an action to reset expections within the AC?
21:29:51 [DaveO]
I'll concur. I think we wasted time asking the AC.
21:30:19 [DaveO]
21:30:47 [Ian]
DO: If we really wanted to go to last call end of July, we should have told the AC that.
21:30:59 [Ian]
DO: We should have set clearer expectations at the AC meeting; explained to them the down sides.
21:32:08 [Ian]
DO: I think the question we asked them missed the mark; we didn't get back information that we found useful.
21:32:26 [Ian]
TB: That may be true, but until we went through the call today, I don't think we knew.
21:33:24 [DanC]
yes, I think that's life... hindsight is 20-20.
21:33:51 [Ian]
21:34:04 [Ian]
SW: Folks, please make progress on your action items before our next teleconf.
21:34:35 [Ian]
Action DO/PC: Send draft of AC announcement to
21:34:47 [Ian]
SW: Progress on actions place.
21:34:49 [Ian]
21:34:50 [Zakim]
21:34:52 [Ian]
21:34:55 [Zakim]
21:34:56 [Zakim]
21:34:57 [Zakim]
21:34:57 [Zakim]
21:34:58 [Zakim]
21:34:59 [Zakim]
21:35:00 [Zakim]
21:35:13 [Ian]
zakim, drop Ian-BOS
21:35:13 [Zakim]
sorry, Ian, I do not see a party named 'Ian-BOS'
21:35:28 [Ian]
RRSAgent, stop