IRC log of tagmem on 2003-03-31

Timestamps are in UTC.

19:59:54 [Ian]
zakim, this is TAG
19:59:54 [Zakim]
ok, Ian
19:59:58 [Chris]
Stuart, dod 'blessed text' get onto the agenda?
20:00:13 [Zakim]
20:00:26 [Zakim]
20:00:29 [Roy]
Roy has joined #tagmem
20:00:45 [Ian]
Ian has changed the topic to: Agenda:
20:00:47 [Zakim]
20:00:57 [Ian]
zakim, P3 is Stuart
20:00:57 [Zakim]
sorry, Ian, I do not recognize a party named 'P3'
20:01:02 [Ian]
zakim, ??P3 is Stuart
20:01:02 [Zakim]
+Stuart; got it
20:01:20 [Zakim]
20:01:29 [TBray]
TBray has joined #tagmem
20:01:48 [Zakim]
20:01:55 [Ian]
zakim, ??P5 is Paul
20:01:55 [Zakim]
+Paul; got it
20:02:01 [Ian]
zakim, who's here?
20:02:01 [Zakim]
On the phone I see ??P0, Ian, Tim_Bray, Norm, Stuart, Chris, Paul
20:02:02 [Zakim]
On IRC I see TBray, Roy, Norm, Stuart, Chris, Zakim, RRSAgent, Ian
20:02:09 [Ian]
zakim, ??P0 is Roy
20:02:09 [Zakim]
+Roy; got it
20:02:23 [DanC]
DanC has joined #tagmem
20:02:42 [timbl]
timbl has joined #tagmem
20:03:08 [Zakim]
20:03:24 [Ian]
zakim, ??P4 is David
20:03:24 [Zakim]
+David; got it
20:03:36 [timbl]
weird... can't be good
20:03:57 [Zakim]
20:04:07 [Ian]
zakim, who's here?
20:04:07 [Zakim]
On the phone I see Roy, Ian, Tim_Bray, Norm, Stuart, Chris, Paul, David, TimBL
20:04:09 [Zakim]
On IRC I see timbl, DanC, TBray, Roy, Norm, Stuart, Chris, Zakim, RRSAgent, Ian
20:04:33 [Ian]
Chair: SW, Scribe: IJ
20:04:45 [Ian]
Roll call: Everyone (expecting DC who's not here yet)
20:04:51 [Ian]
Accept 24 Feb telecon minutes?
20:04:55 [Ian]
20:04:55 [Zakim]
20:05:01 [Ian]
Resolved: Accept 24 Feb minutes.
20:05:13 [Ian]
RF: 24 Feb minutes look ok to me.
20:05:22 [Ian]
# Accept this agenda?
20:05:28 [Ian]
20:06:12 [Ian]
[No agenda suggestions]
20:06:30 [Zakim]
20:06:37 [Zakim]
20:06:39 [Ian]
Next meeting: 7 April.
20:06:44 [Ian]
SW: Regrets.
20:06:51 [Ian]
zakim, drop Dan
20:06:51 [Zakim]
DanC is being disconnected
20:06:52 [Zakim]
20:06:55 [DanC]
I'm at risk due to travel for 7Apr
20:07:08 [Ian]
NW: My attendance is at risk as well.
20:07:54 [Ian]
NW: If you can arrange to have me called, I will chair.
20:08:06 [Ian]
Action IJ: Arrange for call with NW.
20:08:08 [Ian]
20:08:14 [Ian]
Virtual meeting in May
20:08:35 [Zakim]
20:08:46 [Ian]
zakim, drop DanC
20:08:46 [Zakim]
DanC is being disconnected
20:08:47 [Zakim]
20:08:51 [TBray]
Dan's voicemail again
20:08:52 [Ian]
Dan, we got your voice mail again
20:08:58 [Ian]
zakim, drop DanC
20:08:58 [Zakim]
sorry, Ian, I do not see a party named 'DanC'
20:09:01 [TBray]
Very lovely voice I must say
20:09:13 [Zakim]
20:09:18 [Chris]
if mildly robotic and over solicitous
20:09:48 [Zakim]
20:09:54 [Ian]
zakim, ??P4 is David
20:09:54 [Zakim]
+David; got it
20:10:27 [Zakim]
20:11:33 [DanC]
timbl sent his schedule, no?
20:12:29 [timbl]
I will send a much more complicated monger list of dates throughout last week of May through last week of June.
20:12:48 [timbl]
20:12:48 [Ian]
Action TBL: Send in alternative dates for May virtual meeting.
20:12:55 [Ian]
20:13:04 [timbl]
There are many tentaive things for me at thismoment.
20:13:14 [Ian]
Architecture Document
20:13:19 [Ian]
26 March 2003 Draft
20:13:24 [Ian]
20:13:58 [Ian]
Progress check on action items.
20:14:08 [Ian]
1. Action DC 2003/02/06: Attempt a redrafting of 1st para under 2.2.4 of 6 Feb 2003 draft
20:14:11 [Ian]
# Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design
20:14:34 [Ian]
DC: On first action, no progress.
20:14:44 [Ian]
DC: On second action, some progress two weeks ago (co-author0
20:14:50 [Ian]
20:14:50 [Ian]
6. Action DC 2003/03/17: : Write some text for interactions chapter of arch doc related to message passing, a dual of shared state.
20:15:21 [Ian]
DC: I think I have some progress on latest one; will drop pointers here shortly.
20:15:26 [Ian]
# Action DO 2003/01/27: Please send writings regarding Web services to DO grants DC license to cut and paste and put into DC writing.
20:15:50 [DanC]
this is my scribbling on issue 8 and nearby...
20:16:00 [Ian]
DO: I am in meetings now on this topic. No indication of when this will be done.
20:16:29 [Ian]
# Action CL 2003/0127: Draft language for arch doc that takes language from internet media type registration, propose for arch doc, include sentiment of TB's second sentence from CP10.
20:17:08 [Ian]
CL: This is about charset headers, and not generating them when they might be wrong.
20:17:24 [Ian]
CL: I hope to have something by next week.
20:17:28 [DanC]
scribbling on message passing as a dual of shared state:
20:17:38 [Chris]
so i don't have to chase it up again:
20:17:39 [Chris]
CP10. Agents which receive a resource representation accompanied by an
20:17:39 [Chris]
Internet Media Type MUST interpret the representation according to the
20:17:39 [Chris]
semantics of that Media Type and other header information. Servers
20:17:39 [Chris]
which generate representations MUST not generate Media Types and other
20:17:39 [Chris]
header information (for example charsets) unless there is certainty that
20:17:42 [Chris]
the headers are correct.
20:18:28 [Ian]
[Discussion of how to move forward with arch doc]
20:18:33 [Chris]
so its basically, *disagree* with the media type registration ...
20:19:11 [Ian]
TB: Usual progress not happening here (incorporation of draft text after issue resolution).
20:19:34 [Ian]
TB: Although lots of people are queued up to write pieces, that's not happening. IJ could write an end-to-end draft and we could work from that.
20:19:41 [Ian]
DC: That one doesn't appeal to me.
20:20:23 [Chris]
20:20:30 [Ian]
DC: I'd be happy to say TBL "go".
20:20:54 [Ian]
DO: But one reason we are gathered around this table is lack of TBL time.
20:21:24 [Ian]
DC: I observe that TBL does the writing and that people don't react to it.
20:21:53 [timbl]
q+ to discuss Ian's head
20:22:02 [Ian]
CL: I agree with TB on how docs progress: someone just writes stuff.
20:22:04 [Stuart]
ack Chris
20:22:14 [Ian]
CL: Someone puts a stake in the ground and then you have something to push against.
20:22:23 [Ian]
DC: That happens when the editor is really the author.
20:22:55 [Ian]
TBL: The way the Process Doc works is that IJ puts it in his head. Not the same with the arch doc (for IJ).
20:22:55 [Stuart]
ack timbl
20:22:55 [Zakim]
timbl, you wanted to discuss Ian's head
20:23:14 [Ian]
TBL: What are the reasons for the TAG document?
20:23:28 [Ian]
IJ: Time is no longer the primary issue.
20:24:27 [Stuart]
20:24:47 [Ian]
IJ: Primary issue is that I am not getting the sense of agreement that would allow me to run with small pieces and create text.
20:27:48 [Ian]
IJ: One way to advance - small groups of editors to come up with more concrete TOCs for various sections.
20:28:04 [Ian]
CL: I think real text is important; people need something to complain about.
20:28:16 [Ian]
DC: To me the bottleneck is not writing up the decisions; it's making them.
20:28:24 [TBray]
20:28:27 [Chris]
would quite like the paired-off 'buddy' system
20:28:34 [Roy]
Section 5 should be just "Interaction" -- including UI to server actions
20:28:41 [Stuart]
ack DanC
20:28:41 [Zakim]
DanC, you wanted to suggest that the arch doc actually does reflect the consensus of the group; there just isn't that much of it
20:28:52 [Ian]
IJ: I disagree slightly on section on protocols; we've not had many discussions. Hard to say we don't agree.
20:29:22 [Ian]
TB: On issues where we can hammer out consensus, writing them down will produce a meaty and useful arch doc. I think there are problems, but we have enough areas of consensus to publish something.
20:29:35 [Ian]
TB: E.g., look at our findings.
20:30:10 [Ian]
TB: On "5. Machine-to-machine interaction"
20:30:15 [Ian]
20:30:32 [Ian]
TB: I think we have consensus on device-independence, lessons of REST, but that material not really there yet.
20:30:46 [Ian]
TBL: Where is Web Services supposed to be?
20:30:48 [Ian]
IJ: I think section 5.
20:31:11 [Chris]
20:31:15 [Ian]
TBL: There's a fundamental difference between Web Services like things and ordinary Web things.
20:31:18 [Ian]
ack Chris
20:31:46 [TBray]
q+ to say that the list under 4.5 has lots of useful consensus material that needs writing up
20:32:11 [DanC]
hm... perhaps, TBray; but it's not clear to me where Ian should go to get the material
20:32:35 [Ian]
20:32:51 [Ian]
DO: I got the impression that TBL thought about Web Services interactions as different from Web interactions...
20:33:06 [Roy]
20:33:20 [Ian]
TBL: Some Web Service interactions are very Web-like. But the architecture of Web Services is fundamentally messages that are part of larger protocols.
20:33:32 [Stuart]
20:33:32 [Ian]
TBL: They are not part of transferring the state of global information space.
20:33:41 [Ian]
TBL: Some Web Services are retrieval operations, and some are not.
20:33:57 [Chris]
q+ to ask how this is different from semantic web interactions
20:34:01 [Ian]
DO: Roy asked a question a few months ago - are we writing the arch of the current or future Web.
20:34:33 [Ian]
DO: I thought the answer at the time was more about "what has been". I'd love it if we worked on a more encompassing arch doc, but I wasn't aware that that was our mandate.
20:34:41 [timbl]
20:34:47 [Ian]
TBL: I agree that the arch doc should encompass what we are doing within W3C.
20:34:51 [DanC]
ack tbray
20:34:51 [Zakim]
TBray, you wanted to say that the list under 4.5 has lots of useful consensus material that needs writing up
20:35:04 [Ian]
(TB: The list under 4.5 has lots of useful consensus material that needs writing up)
20:35:08 [Ian]
ack Roy
20:35:31 [Ian]
RF: It would be easier for me if we talked about the future Web within this arch doc. It's easier for me to lay out the sections in my mind.
20:35:41 [Ian]
RF: E.g., I consider everything that TBL described to be under "Interactions"
20:35:45 [Ian]
ack Stuart
20:35:55 [Ian]
SW: How do we relate to WSA WG?
20:36:01 [Ian]
ack Chris
20:36:01 [Zakim]
Chris, you wanted to ask how this is different from semantic web interactions
20:36:25 [Ian]
CL to TBL: How is what you are saying about Web Services different from @@scribe missed@@
20:36:46 [Chris]
semantic web
20:37:04 [Ian]
TBL: Whether you send in a msg or a Web service, the Sem Web is for talking about real things in a logical way.
20:37:22 [Ian]
TBL: You can send messages or create documents. The distinctions are orthogonal.
20:37:25 [Chris]
not finished yet btw
20:37:49 [Ian]
CL: So, e.g., the Sem Web is that "this nut is compatible with this bolt if they have the same thread size; as defined over here at this URI"
20:37:52 [timbl]
Chris how is Sw different from WS?
20:38:08 [Ian]
CL: Whereas Web Services is "I want to buy 10k nuts if they fit on this bolt over here."
20:38:21 [Ian]
TBL: When you say "I want to buy them", that's part of the Web Services architecture.
20:38:32 [Ian]
CL: But that's the real world -- it costs you money.
20:38:58 [Ian]
CL: I'm not seeing a real difference here; this is still about machine-to-machine communication.
20:39:18 [TBray]
q+ to note that the only real industrial SW tech applications I've seen have been in WS apps
20:39:21 [Chris]
so, sw and ws seem like very closely related things, in summary
20:39:31 [Ian]
DO: I would like to talk about diff between Sem Web and Web Services in the arch doc. My personal opinion is that the focus of Web Services is "how do you send messages back and forth; and how do you describe the messages in the exchange."
20:39:52 [Ian]
DO: I see the Sem Web as how you make assertions about things and then make queries (in a reduced world) with constraints.
20:40:08 [Ian]
DO: Yes you can put queries in messages...these two worlds intersect.
20:40:19 [Ian]
ack TB:
20:40:22 [Ian]
ack TB
20:40:22 [Zakim]
TBray, you wanted to note that the only real industrial SW tech applications I've seen have been in WS apps
20:41:01 [Ian]
TBL: To me it's obvious that the overlap is very substantial. I've seen people doing Web Services deployment realize that they need vocabularies.
20:41:04 [Ian]
20:41:12 [timbl]
q+ to say that the overlap in application area is very large, but the overlap in concept (which befits the arch doc) is smaller
20:41:29 [Ian]
TB: I think that they are inextricably in bed with one another.
20:41:58 [Ian]
TBL: I think that you find that when you use one you often use the other. But conceptually, they are very different parts of the architecture.
20:42:21 [Ian]
TBL: You often use TCP and HTTP together. But they provide different services.
20:42:46 [Ian]
TBL: Sem Web moves information space from bits to statements about real-world things.
20:43:04 [Ian]
TBL: Combining Web Services and Sem Web is powerful. But there will be apps that use one without the other.
20:43:15 [Ian]
TBL: We are not writing an article for Business Week; we are writing up architecture principles.
20:43:30 [Ian]
TBL: So, e.g., model real-world things in your app, not documents.
20:43:31 [Zakim]
timbl, you wanted to say that the overlap in application area is very large, but the overlap in concept (which befits the arch doc) is smaller
20:43:47 [Ian]
TBL: I can demonstrate cases where you use one without the other.
20:44:09 [TBray]
I don't think Web Services can really get to first base without shared semantics a la SW. And all the SW golden-future stories I read have observable effects that sound a lot like WS.
20:44:28 [Ian]
DO: I agree we are writing an arch doc. The WSA WG is also writing an architecture document. In the latest version of the WSA Arch Doc, I proposed some text about Web Services using language of Roy's thesis.
20:44:47 [Ian]
20:44:51 [Ian]
Web Services Architecture
20:44:51 [Ian]
W3C Working Draft 14 November 2002
20:45:02 [Ian]
3 Basic and Extended Architecture
20:45:04 [timbl]
Inextricably intermingled? test cases: Library ctalog = sem web without WS; document validation sWS = WS without SW maybe? Ordering machine parts could be a SWS case.
20:45:13 [Ian] 3 Basic and Extended Architecture
20:45:33 [Ian]
DO: Maybe we can document differences and similarities.
20:45:37 [DanC]
I think the library folks would disagree with the "without WS", timbl. They're webizing Z39.50 using SOAP all over the place.
20:46:06 [TBray]
20:46:10 [Ian]
DO: We need to decide whether we're documenting one architecture or N.
20:46:12 [Ian]
DC: It is?
20:46:43 [Ian]
DO: I think the understanding we've had so far is that we are writing the Web architecture w.r.t. REST, excluding things like Web Services and Semantic Web.
20:46:48 [DanC]
(I consider our issues list as the authoritative list of decisions we owe)
20:47:12 [Ian]
ack TBray
20:47:14 [timbl]
WS without WS - foaf?
20:47:26 [DanC]
(and perhaps a decision that says 'this document is consistent with our decisions on all these issues')
20:47:31 [Ian]
TB: I think the arch doc will exhibit progress when one or more people take ownership of one or more sections and write them.
20:47:42 [Ian]
TB: I don't think we can divorce content from TOC.
20:48:28 [Ian]
TB: I am convinced we have consensus around enough points that we can produce a useful document.
20:48:37 [Ian]
20:49:23 [Ian]
TB: I'm not arguing that the current TOC is wrong; I'm arguing that we need text from start to finish, and we need to roll up sleeves and write it.
20:49:32 [Ian]
20:49:52 [Ian]
20:50:00 [Ian]
* IRIEverywhere-27
20:50:00 [Ian]
o Action CL/IJ 2003/03/17: Send edited piece that CL/MD/IJ wrote to www-tag. CL expects this by 31 Mar.
20:50:13 [Ian]
SW: See email from Larry Masinter as well
20:50:15 [Chris]
20:50:22 [Stuart]
20:50:28 [Ian]
(Email from LM)
20:50:42 [Ian]
Text of needs to change.
20:51:01 [DanC]
$Date: 2003/01/27 22:58:44 $
20:51:53 [DanC]
to me, what chris just said is the heart of the issue.
20:52:03 [Ian]
CL: No longer true: " 1. RFC2396 should be modified so that hex digits (HEXDIG) are case-insensitive. "
20:52:20 [Ian]
DC: Please include the Kanji example in this document.
20:52:44 [Ian]
CL: TB's how to compare distinguishes case where you dereference and where you do not.
20:52:58 [Stuart]
20:53:08 [Ian]
CL: I am proposing that the cases where you don't dereference are treated by simple Unicode string matching.
20:53:48 [Ian]
CL: However the next level up works on all schemas and you are dereferencing; upper lower case hex should be same; same with Kanji example; I think that this should be scheme-independent.
20:54:11 [Ian]
RF: Why do IRIs affect RFC2396 bis?
20:54:52 [Ian]
CL: Would be weird if Kanji lowercase hex isn't the same as Kanji uppercase hex. Does not depend on URI scheme.
20:55:10 [Ian]
RF: Need to convert from IRIs to URIs for comparison, though.
20:55:35 [Ian]
CL: Aha! No need to do this comparison any more if you are not dereferencing the IRIs.
20:56:01 [timbl]
(RF said they compared the same because you convert to URI before comparison)
20:56:02 [Ian]
RF: If you are going to use an IRI as a namespace id, you're going to want to convert to URI first, otherwise, you'll have differences in the use of that identifier.
20:56:13 [Ian]
RF: You create a lot of unnecessary duplicates if you don't convert first.
20:56:40 [Ian]
CL: Encoding has nothing to do with this.
20:56:51 [Ian]
CL: These are Unicode character codes.
20:57:00 [Ian]
CL: Assume it's in IRI form. Why would you convert to URI?
20:57:09 [timbl]
q+ to agree with Roy and re explain it if chris hasn't got it
20:57:34 [DanC]
"most common is URIs"... not in XML implementations
20:57:43 [Ian]
RF: Most common use of identifiers is as URIs; you'll have IRIs sometimes and URIs sometimes. If you don't convert to URIs first, you won't have uniformity.
20:58:39 [Ian]
CL: When you are not dereferencing, case matters. The available evidence from people who do namespace stuff is that they do string comparison. It's pushing too much water uphill for namespace case.
20:58:41 [timbl]
q+ to say that while the URI spec licences the conversion between 8bit and hexified froms, then they will be equivalent.
20:58:59 [Ian]
RF: So you are relying on "If you want uniformity, use things uniformly."
20:59:17 [Ian]
CL: I can't get my preferred position, so my new position is closer to what the world will accept.
20:59:32 [Ian]
RF: There are situations where URIs are not as useful due to lack of deployment.
20:59:34 [Ian]
ack Stuart
20:59:44 [DanC]
s/URIs are not as/IRIS are not as/
20:59:50 [Roy]
21:00:23 [timbl]
w+ to say that we were asked to fix a problem; if we documented the current situation, we would document a mess. We could suggest an alternative. Eg. We could recommend that string comparison be limited to URIs only, and people not use IRIs until then can do IRI-URI mapping.
21:00:33 [Ian]
SW: Larry, I think, is advising us to be patient and wait until there's an RFC.
21:00:38 [Chris]
21:00:45 [timbl]
q+ to say that we were asked to fix a problem; if we documented the current situation, we would document a mess. We could suggest an alternative. Eg. We could recommend that string comparison be limited to URIs only, and people not use IRIs until then can do IRI-URI mapping.
21:01:07 [Ian]
ack DanC
21:01:07 [Zakim]
DanC, you wanted to say why it maybe should depend on the scheme and to observe that the genie is out of the bottle here
21:01:18 [TBray]
q+ to agree with TimBL
21:01:43 [Ian]
DC: There's text in XML namespace spec that says you can't have two attribs with the same name after they are namespace qualified.
21:02:07 [Chris]
good test case there
21:02:09 [Ian]
DC: You can tell (for Kanji case) whether your namespace implementation was happy.
21:02:25 [Ian]
DC: When I coded this up, I converted IRI to URI before comparison. It worked; that's a coherent position.
21:02:51 [Ian]
DC: I looked up in the world and I saw that there's an enormous tide of people doing it the other way: All XPath, XML Query, XML Schema implementations.
21:03:08 [Chris]
I aggree its a coherent position. i t was my first choice. But its not the majority position
21:03:11 [Ian]
DC: HTML implementations use heuristics to maximize @@missed@@
21:03:22 [Chris]
everyone does unicode character by character comparison
21:03:57 [Ian]
DC: The way you get shared understanding of a name is to repeat verbatim in lots of contexts. The more mangling we have, the higher the risk of confusion.
21:04:06 [Stuart]
21:04:18 [Chris]
mixing up the hexified and non-hexified forms is a problem
21:04:23 [Chris]
they do no collide
21:04:39 [Chris]
the kanji form is te correct canonical form, written correctly
21:04:53 [Ian]
DC: I think that the right answer is: (1) In the specific case of namespace names - no they do not collide unless they match unicode-char by unicode-char (2) this is rationalized in the real world since a person wanted to write their name the way that person usually does.
21:04:54 [Ian]
ack TBL
21:04:54 [DanC]
ack timbl
21:04:55 [Zakim]
timbl, you wanted to agree with Roy and re explain it if chris hasn't got it and to say that while the URI spec licences the conversion between 8bit and hexified froms, then they
21:04:56 [Chris]
ack timbl
21:04:59 [Zakim]
... will be equivalent. and to say that we were asked to fix a problem; if we documented the current situation, we would document a mess. We could suggest an alternative. Eg. We
21:05:03 [Zakim]
... could recommend that string comparison be limited to URIs only, and people not use IRIs until then can do IRI-URI mapping.
21:05:32 [Ian]
TBL: If we documented the current situation, we would document a mess.
21:06:06 [timbl]
possible solutions -- insist on hexifying for comparison, or forbid hexifying by clients. (iri proposal suggest the former; danc proposal leads to the latter)
21:06:29 [Chris]
we *could* insisst on hexifying always but this would not work
21:06:41 [Ian]
TBL: String comparison is fine BUT, you're not allowed to use IRIs until you've got your IRI-to-URI conversion working.
21:07:19 [Ian]
TBL: One way is that URIs rule and that IRIs are one way of talking about URIs. I would argue that this is not pushing too much water uphill.
21:07:21 [Ian]
TBL: Plan B:
21:07:32 [Chris]
plan b is 'hexifying does not work'
21:07:53 [Ian]
TBL: Hexifying - no! %xx are just characters. Client can't change. When you send across medium, these are Unicode strings - each protocol has to say how to handle them.
21:08:11 [Chris]
hexifying isa last-ditch, late conversion to get an IRI through a non 8 bit clean protocol
21:08:28 [Chris]
which is basically what I understand to be the IRI position
21:08:34 [Ian]
TBL: Plan B says that namespace can do char-by-char Unicode and everyone else has to deal with it.
21:08:58 [Ian]
RF: Does this mean IRI comparison should convert URI to IRI first?
21:09:04 [Ian]
CL: No. All URIs are already IRIs.
21:09:34 [Ian]
DC: There is a plan C in RF's question - the two spaces are isomorphic.
21:09:51 [Ian]
DC: You peek inside hex encoding.
21:10:02 [Ian]
CL: It's better to say - once you've done hexing you've got a different thing.
21:10:11 [Ian]
CL: It's still an IRI, but doesn't use other chars than ASCII
21:10:17 [DanC]
yes, plan C conflicts with the "if you mean the same thing, say it the same way" principle
21:10:48 [Ian]
RF: An IRI that uses chars outside ASCII char set will be less "interoperable" than one that contains only ASCII chars.
21:11:00 [timbl]
The isomophism creates some equivalences which break plan C
21:11:03 [TBray]
21:11:10 [Ian]
DC: This is like a health warning: don't use "l" and "1" to avoid confusion.
21:11:31 [Ian]
RF: Problems include email, RFCs munging text, ...
21:11:48 [timbl]
q+ to propose that there is lots more water to be pushed uphill in plan A
21:12:28 [Ian]
RF: I anticipate times when IRI will be used as namespace and people will want to use it in its URI state.
21:13:03 [Ian]
CL: For the data entry problem, you can already type things in in ASCII.
21:13:08 [Norm]
q+ to say that there is simply existing software that insists on ASCIII
21:13:09 [Ian]
CL: That aspect is already dealt with for XML.
21:13:12 [Ian]
ack TBray
21:13:12 [Zakim]
TBray, you wanted to agree with TimBL
21:13:49 [Ian]
TB: I think that DC's experience with pushing water uphill is correct. If you are staying in the URI universe, then the approach taken so far (strcmp) is important - people should use the same name for the same thing.
21:14:01 [Ian]
TB: In a URI world, that's ok. (and bots can be more aggressive)
21:14:11 [Ian]
TB: For IRIs, I think we have to push some water uphill.
21:14:15 [Chris]
because bots do dereferencing type things
21:14:35 [Chris]
timbray asks if 'all uris are iris' are cast in stone
21:14:41 [Chris]
believe so, yes
21:14:50 [Ian]
TB on the whether a URI is already an IRI: I think that the rules about hexification non-deterministic.
21:15:11 [Chris]
hexification always when needed, never when not needed
21:15:16 [Ian]
TB: If we could require that hexification always when needed and never when not needed, then we'd have more leverage to attack the IRI problem.
21:15:28 [Ian]
ack timbl
21:15:28 [Zakim]
timbl, you wanted to propose that there is lots more water to be pushed uphill in plan A
21:15:34 [timbl]
21:15:44 [Ian]
TBL: There is lots more water to be pushed uphill in plan A.
21:15:52 [Ian]
TBL: I don't see Plan C working.
21:15:56 [Chris]
2.3 IRI Equivalence and Normalization
21:15:58 [TBray]
I propose we say a URI is *not* an IRI if it's got unnecessary hexification
21:16:04 [Chris]
"It follows from the above that IRIs SHOULD NOT be modified when being transported. "
21:16:28 [Chris]
"In some scenarios a definite answer to the question of IRI equivalence is needed that is independent of the scheme used and always can be calculated quickly and without accessing a network. An example of such a case might be XML Namespaces ([XMLNamespace]). "
21:16:35 [Ian]
TBL: I feel that when you compare pushing water uphill to number of places where URIs are communicated over 7 bits....that world is much more diverse.
21:16:50 [Ian]
TBL: That is MUCH MORE water to push uphill.
21:17:01 [Ian]
TBL: You'd have to divide the Web in two.
21:17:14 [Chris]
disagree that it slits the web in two
21:17:34 [Chris]
*not* doing IRI would certainly split the Web into n parts, though
21:17:47 [Ian]
TBL: If we try to move to the world where URIs are replaced by IRIs, I think it's easier to get namespace-aware software to change (convert then compare).
21:17:54 [Ian]
TBL: That's a more numerable set of applications.
21:18:00 [Chris]
21:18:12 [DanC]
ack danc
21:18:13 [Zakim]
DanC, you wanted to discuss world-wide charset and to agree that the rules around hexifying are frightening; cf XML query spec and to observe that we are in web phase 2
21:18:51 [Ian]
DC: Regarding interoperability of IRIs/URIs, my experience is that if you want to use a URI that will really work everywhere, you should use [2-9] and that's it.
21:19:52 [Ian]
DC: I agree that the hex rules are frightening; the XML Query folks ran across problems recently.
21:20:08 [Ian]
DC: To me, hexifying is something the URI owner gets to do and nobody else gets to look into.
21:20:15 [Chris]
'no peeking inside' - IRI spec agreres about that
21:20:22 [Chris]
3.2 Converting URIs to IRIs
21:20:31 [Chris]
In some situations, it may be desirable to try to convert a URI into an equivalent IRI. This section gives a procedure to do such a conversion. The conversion described in this section will always result in an IRI which maps back to the URI that was used as an input for the conversion (except for potential case differences in escape sequences). However, the IRI resulting from this conversion may not be exactly the same as the original IRI (if there ever was one).
21:21:12 [Ian]
DC: As to TBL's comment on water in 7-bit URI world: Maybe. But water not all flowing in the same direction. I remain convinced that using strings of Unicode chars for resource names is the correct option.
21:21:13 [Ian]
21:22:29 [DanC]
yes, or no, paulc: do we discuss issue 8 today?
21:22:38 [DanC]
21:22:38 [Chris]
would prefer to try and get this issue with some agreement so i can edit this document
21:22:40 [DanC]
21:22:48 [Ian]
[TAG agrees to address issue 8 next week]
21:22:52 [Ian]
21:23:06 [TBray]
I think we have agreement that (a) IRIs are a good thing, and
21:23:18 [Chris]
yes, clearly on a)
21:23:22 [TBray]
(b) and that URIs are not going away so the URI->IRI conversion is a necessity, and
21:23:23 [Ian]
NW: I agree with RF's comment - I think it will remain the case for some time that URIs work where IRIs don't.
21:23:25 [Chris]
for months now
21:23:27 [Roy]
q+ to say that I agree with Larry's comment: the only finding is that IRI does not yet exist
21:23:31 [Ian]
ack Norm
21:23:31 [Zakim]
Norm, you wanted to say that there is simply existing software that insists on ASCIII
21:23:49 [DanC]
yeah, well, solving world hunger is a good thing. but I'm not going to 2nd a proposal to solve it, setting expectations that we're not going to meet.
21:23:53 [TBray]
(c) we need real clarity on URI<->interconversion rules & when to do
21:23:55 [Ian]
TBL: I suggest that CL write down Plans A and B.
21:23:59 [Chris]
document both options and discuss them
21:24:01 [Stuart]
ack timbl
21:24:05 [TBray]
er URI<->IRI interconversion
21:24:15 [DanC]
roy, you're wrong. IRI does exist. It's the norm in practice.
21:24:16 [DanC]
21:24:22 [Ian]
CL: Yes, I agree that it's a good idea to write down both options.
21:24:23 [Chris]
ack chris
21:24:37 [Ian]
RF: If the issue is that IRIs should be everywhere, then we need to be clear on what IRIs are.
21:24:56 [Ian]
RF: IRI docs are still undergoing big changes.
21:25:09 [Ian]
RF: I am happy to reconsider this issue when IRI and URI specs stabilize.
21:25:15 [Ian]
ack Roy
21:25:15 [Zakim]
Roy, you wanted to say that I agree with Larry's comment: the only finding is that IRI does not yet exist
21:25:19 [Ian]
ack DanC
21:26:11 [Chris]
the implementations have consensus and have done for a long time
21:26:23 [Ian]
DC: I observe more consensus in the implementations than in the spec. The fact that the users are happy to invest in this technology early suggests to me that we owe the community a spec for what they're doing.
21:26:23 [Chris]
because the rest of the world wants to use its own characters
21:26:36 [Ian]
DC: I'm talking about XML* specs, not just IRI specs.
21:26:39 [Roy]
Solution: the attribute is CDATA, not an IRI or URI
21:26:45 [timbl]
q+ to say we need to define equivalence more widely than one WG
21:26:46 [Chris]
TAG should request that draft-duerst04 moves to an RFC asap
21:26:47 [Ian]
DC: The status quo is that people cut/paste IRI text directly into their specs.
21:26:53 [Ian]
ack TimBL
21:26:53 [Zakim]
timbl, you wanted to say we need to define equivalence more widely than one WG
21:27:17 [Ian]
TBL: We've been asked to say when URIs/IRIs are equivalent. I think it would be a shame to leave it as "Pick your favorite of 7 levels"
21:28:03 [Chris]
it has been pointed out before that equivalence does indeed depend - it depends on the equivalence operator that you are using
21:28:11 [Chris]
and there are only two levels, in fact
21:28:19 [Ian]
TBL: Plan A says IRI(1) and IRI(2) equiv when same string of Unicode chars. Plan B says IRI(1) and IRI(2) are equiv when hexified and string compared.
21:29:14 [Chris]
well, not strcmp but wide-strcmp
21:29:25 [Ian]
DC: The only guy who gets to hexify is the guy who makes up the URI in the first place.
21:30:02 [Ian]
[Discussion of Internet Explorer behavior - been doing Plan B]
21:30:07 [DanC]
(except that I didn't really mean that. yes, I did say that.)
21:30:22 [Chris]
doing plan b when they dereference
21:30:32 [TBray]
I really have to go...
21:30:34 [Chris]
doing plan a when they compare without dereference
21:30:45 [Ian]
RF: Like LM, I think we need to wait for the next IRI draft.
21:30:47 [Ian]
21:30:48 [Ian]
21:31:03 [Chris]
roy says that international domain names now ratified so martin will update the spec to reflect this
21:31:08 [Zakim]
21:31:08 [TBray]
sorry bye
21:31:11 [Ian]
DC: So Martin writes some text. But we need to get agreement with lots of people (including W3C groups and outside W3C).
21:31:29 [Ian]
DC: So TAG should actively coordinate among these groups. E.g., provide tests.
21:31:52 [Zakim]
21:32:12 [Ian]
SW: Another thing in LM's message - creation of an IRI mailing list.
21:32:19 [Ian]
SW: Is the IETF the venue for this meeting?
21:32:23 [Ian]
DC: An IETF WG could be.
21:32:36 [Ian]
RF: Discussion of draft is taking place on a W3C mailing list for the purpose of advancing spec within the IETF.
21:32:41 [Stuart]
21:32:52 [Chris]
The mailing list for public discussion of IRIs is, with a public archive. To subscribe, send mail to with subscribe as the subject.
21:33:02 [Stuart]
21:33:03 [Ian]
RF: It would be ideal to endorse this as the home and get people to talk there.
21:33:43 [Ian]
[Some discussion that CL and DC would be uncomfortable with providing text to groups with a guarantee that it would pass muster at doc transition.]
21:33:47 [Zakim]
21:33:51 [Zakim]
21:33:52 [Zakim]
21:33:55 [Ian]
CL: I will revise the IRI position draft for next week.
21:33:56 [Ian]
21:33:59 [Zakim]
21:34:00 [Zakim]
21:34:01 [Ian]
RRSAgent, stop