IRC log of tagmem on 2002-03-18

Timestamps are in UTC.

14:34:48 [RRSAgent]
RRSAgent has joined #tagmem
14:35:11 [Ian]
Ian has changed the topic to: TAG teleconference
14:49:56 [TimBL]
TimBL has joined #tagmem
14:52:36 [TimBL]
RRSAgent, help\
14:52:51 [TimBL]
RRSAgent, stop
15:36:11 [TimBL]
Zakim, who is here?
15:36:12 [Zakim]
I see TimBL, Norm, Stuart?, Paulc, Ian, DanC, TBray
15:36:26 [DanC]
others: Roy, PaulC, ??
15:36:34 [DanC]
others: Roy, DaveO, ??
15:36:35 [Zakim]
15:36:46 [TimBL]
Missing Roy, DOrchard
15:36:51 [TimBL]
Meeting starts
15:37:08 [ChrisL]
ChrisL has joined #tagmem
15:37:19 [Ian]
TBL: Problems with previous minutes? Additions?
15:37:38 [Ian]
TBL: DanC suggested that we do action items by email in advance, or that I summarize.
15:37:44 [Ian]
Actions for one page summaries: Closed.
15:38:00 [Ian]
Action DC: check with workshop chair, make the XML PM ws minutes available to the public, per CFP
15:38:12 [Ian]
DC: To my satisfaction, it's public.
15:38:26 [Ian]
...I tested from external machine.
15:38:43 [Ian]
Please test:
15:39:02 [Ian]
15:39:12 [Ian]
PC: I'll publicize once it's public.
15:39:14 [Norm]
That url is public
15:39:24 [Ian]
TB: I strongly feel that it's public.
15:39:42 [TimBray]
I checked it
15:39:54 [Ian]
Action IJ: Integrate issues & findings into TAG arch doc toc
15:40:00 [Ian]
IJ: I will try to do that this week.
15:40:07 [Ian]
15:40:18 [Ian]
TAG presentation at AC meeting in Hawaii.
15:40:28 [Ian]
TimBL: Top three questions we'd ilke to ask AC?
15:40:44 [Ian]
TimBL: What should we put out before the AC meeting?
15:41:27 [Ian]
IJ: I suggest that I try to integrate one-piece documents and that that be available before AC meeting.
15:41:33 [Norm]
Color me ignorant as well. It's a pale shade of chartreuse, I think.
15:41:35 [Ian]
TimBL summarizes AC meeting
15:41:47 [Ian]
- Twice a year, summary of w3c activities to Membership
15:41:50 [ChrisL]
Given the time period for this, we can't really 'ask the AC' something like our three hardest issues and expect to get anything done in 45 minutes or whatever
15:42:10 [Ian]
Chris, I don't expect us to ask the AC technical questions. More about, say, direction of TAG.
15:42:24 [ChrisL]
15:42:43 [Ian]
TimBL: AC likes to be asked, not told.
15:43:12 [Ian]
TiMBL: The TAG should basically listen to the AC.
15:43:15 [ChrisL]
So brandishing the collection of one page summaries and saying 'what do you think so far' is the sort of question
15:43:16 [Ian]
PC: We have a mandate to report.
15:43:23 [Ian]
CL, yes, I think so.
15:43:36 [Ian]
15:43:53 [Zakim]
15:45:38 [TimBL]
Ian describes AC agenda
15:45:43 [Ian]
IJ: Currently, TAG allotted 30 minutes for presentation, 30 for discussion.
15:45:53 [Ian]
IJ: Director usually gives a report. Is this separate?
15:46:17 [ChrisL]
TAG report is clearly separate from Director report
15:46:19 [Ian]
PC: There's also a free-for-all slot at the end of the day.
15:46:45 [Ian]
TimBL: The question for us to think about:
15:47:02 [ChrisL]
Recently, a move from 'presentation' to 'top questions/issues' to involve AC more, not give them bland reports
15:47:08 [Ian]
- We are going to ask the AC for help in solving TAG problems. How can we use the AC to help us?
15:47:22 [Ian]
Homework: Think about this this week. For discussion next week.
15:47:50 [Ian]
If you won't be there, please indicate on IRC.
15:48:03 [Ian]
TimBL: We can create a panel, give an overview of where we fit in, what we've done.
15:48:08 [Ian]
...and then ask 3 questions.
15:48:47 [TimBL]
15:48:51 [Ian]
PC: Here's a provocative one: TAG session wasn't technical enough at tech plenary. Does that feedback influence us about having a more technical discussion in front of AC? Or what that feedback specific to the tech plenary?
15:49:07 [Ian]
DC: I don't mind little blood on the floor in Cannes.
15:49:27 [Ian]
DC: If we present a technical issue, I'd like to present by way of analogies. Allow us to illustrate the issue for a large audience.
15:49:28 [ChrisL]
We are going for useful feedback and clarity on how to contribute, not 'blood on floor'
15:50:06 [ChrisL]
AC is a little different to the chairs/WG menmber audience
15:50:20 [Ian]
TimBL to PC: I think the AC does not expect technical discussion. More likely things like "what happens if a WG flagrantly violates the architecture. What can the TAG really do?" How do we deal with overload, etc.
15:51:04 [Ian]
DC: Please don't get into penalty phase (until problems actually arise).
15:51:16 [Ian]
IJ: Note that AB will talk about penalties for process violations at AC meeting.
15:51:19 [Dave]
Dave has joined #tagmem
15:51:27 [DanC]
i.e. please let's trust unless/until we have reason to do otherwise.
15:51:45 [Ian]
PC: note that we are delegating questions to WGs when they are appropriate. Important to tell AC when we do that.
15:51:46 [ChrisL]
More important that AC know how to raise an issue to TAG, how we resolve them, etc
15:52:15 [Ian]
15:52:29 [Ian]
TimBL: Please think about this during the next week.
15:52:33 [Ian]
15:52:38 [Ian]
On one-page summaries.
15:53:41 [Ian]
TimBL: IJ has offered to put these togethers into a harmonious whole.
15:53:58 [Ian]
TimBL: Also, IJ should start to create a glossary that will allow us to coordinate our writing.
15:54:03 [DanC]
yes, a glossary; e.g. web vs. Web
15:54:24 [Ian]
I was thinking of glossary as semantic rather than manual of style.
15:54:38 [Ian]
[There is consensus about doing a glossary.]
15:54:38 [DanC]
and object/thing has come up in intro feedback.
15:55:12 [Ian]
TimBL: If a term is already defined, point out where it's defined (and quote it).
15:55:23 [ChrisL]
And in particular, note when there are multiple definitions for the same term in different communities
15:55:37 [Ian]
TimBL: We are likely to rewrite terms in terms of each other until the whole thing is consistency.
15:55:58 [Ian]
TimBL: There are likely traps like "entity" and "resource" since defined differently in different contexts.
15:56:45 [Ian]
15:56:47 [Ian]
15:58:24 [Ian]
CL: I objected strongly to earlier draft, but we cleared up the misunderstanding.
15:58:32 [Ian]
...but I wanted to ensure that, e.g., DOM, appear.
15:58:38 [Ian]
TB: There wasn't much disagreement on the list.
15:58:54 [Ian]
..just a question of how we write stuff down. We agree that bullet 3 needs more kicking around.
15:59:32 [Ian]
TimBL: Do you think there's still a big gap?
15:59:33 [DanC]
for the record, the current version is $Revision: 1.6 $ of $Date: 2002/03/13 16:38:22 $
15:59:38 [Ian]
CL: Yes, it's still mostly about network protocols.
16:00:18 [Ian]
..less obvious; not as widely understood.
16:00:32 [Ian]
DC: Maybe better on what a doc means?
16:00:46 [Ian]
TB: Am I only one uncomfortable about distinction between documents and messages.
16:00:47 [Ian]
16:01:06 [ChrisL]
message = body plus header
16:01:15 [Ian]
TBL: DC and I share model where message is a "point" event. A document is something that can change over time.
16:01:17 [ChrisL]
document is instance-of body
16:01:25 [Ian]
TBL: You can't build a protocol out of documents, but you can out of messages.
16:01:36 [Ian]
...there's a relationship between the two (docs and messages).
16:01:41 [Ian]
..see DC's model in Larch
16:02:09 [DanC]
Ian, an analogy to explain documents/messages: the way T.V. Raman (who is blind) can "see" what's on the whiteboard just by listening to the conversation (messages) about it.
16:02:40 [Ian]
CL: TimBL on messages is fine, but seems to imply that a resource only changes based on messages.
16:02:53 [Ian]
DC: Not exactly: only time when parties learn of changes is when messages are exchanged.
16:04:26 [Ian]
TimB: So sounds like agreement that item 3 needs more work.
16:04:35 [Ian]
Action TB: Have a go at #3
16:05:40 [Ian]
DC: I'm prepared to hand off now.
16:05:43 [Dave]
16:05:55 [Ian]
IJ: I will take it as soon as TB says "Take it."
16:05:59 [Ian]
16:06:12 [Ian]
16:06:12 [Ian]
* What does a URI identify?: NW and SW
16:06:21 [Stuart]
16:06:54 [Ian]
NW: I think we should do one more pass.
16:07:18 [Ian]
TBL: I've never used the word "Uniform" in this way. I think it's a good rule.
16:07:26 [DanC]
Stuart, are you in the critical path too? or is it enough if Ian hears from Norm?
16:07:32 [Ian]
Uniform: Any URI can be used in any place where a URI is used.
16:08:08 [Ian]
Stuart: In RFC 2396, there's an explanation of what "Uniform" is supposed to mean.
16:08:12 [Ian]
DC: I remember this, sort of.
16:08:43 [Ian]
DC: The spec went to the IETF as "Universal" and folks in the IETF found another word less encompassing than Universal.
16:08:52 [Ian]
TBL: Both are important.
16:09:02 [Ian]
TBL: I felt that "Uniform" was a kind of downgrading.
16:09:16 [Ian]
TBL: IETF resisted this apparent totalitarian move.
16:10:04 [Ian]
TB: I like section 4 in second document.
16:10:13 [Ian]
(Semantics of URIs)
16:10:15 [DanC]
[[They [URIs] reduce the tedium of "log in to this server, then issue this magic command ..." down to a single click.]] --
16:10:20 [Ian]
16:10:57 [DanC]
Bray: "an addressable unit of information or service"
16:10:59 [Ian]
TB: I like definition of Resource: " An addressable unit of information or service"
16:11:10 [Ian]
DO: Isn't that circular?
16:11:21 [Ian]
TB: I don't care that it's circular. It works. :)
16:11:29 [Ian]
TOPIC: Define "resource"
16:11:29 [DanC]
google says that's from XML-Link, TimBray.
16:11:41 [Ian]
TBL: In URIs and RDF used differently.
16:11:46 [TimBray]
Iput it there... but I stole it from somewhere
16:12:20 [Ian]
From WCA terms
16:12:35 [Ian]
16:12:35 [Ian]
The URI specification describes a resource as the common term for "...anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), as well as a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources..." (see also the term Web Resource).
16:13:01 [Ian]
TimBL: You can't make a representation of a telnet session. Or a mailbox. I think it's useful to distinguish documents from other things.
16:13:21 [Ian]
TimBL: HTTP has architecture of representations.
16:13:31 [Ian]
DC: Representations are documents. But what they represent is not constrained, is it?
16:13:58 [Ian]
TimBL: If something were to give me a representation of a telnet resource, it would miss the nature of the telnet resource.
16:14:07 [Ian]
TB: My definition with service covers that.
16:14:45 [Ian]
DC: Resource is like "point" in geometry. You don't define. They just are.
16:14:52 [Ian]
CL: Yes, it's defined.
16:15:11 [Ian]
DO: If we agree that we want a circular definition, then we should acknowledge that they're circular (and rationale why).
16:15:19 [ChrisL]
16:15:40 [Ian]
TimBL: Valid questions:
16:15:40 [Ian]
16:15:45 [Ian]
- Can a car be a resource?
16:15:52 [Ian]
DC: Yes, n'est-ce pas?
16:16:08 [Ian]
TimBL: By RDF definition, yes. By URI definition, no.
16:16:19 [Ian]
CL: You can provide a URI to a photo of a car, but not a car.
16:16:22 [ChrisL]
Don't especially like it, but there are examples of such self-booting definitions that work
16:16:24 [Ian]
TB: I agree with CL.
16:16:36 [DanC] <- that identifies my car.
16:16:45 [Ian]
TimBL: In RDF, you can write a thing that describes a car.
16:16:55 [ChrisL]
Only because you asseret that it does
16:17:19 [ChrisL]
I could assert that I have a URI which defines your car
16:17:22 [Ian]
SW: The definitions I have come across are "Anything that can be identified can be a resource."
16:17:40 [Ian]
SW: Anything that can be identified is not necessarily everything that is net accessible.
16:17:50 [TimBray]
16:17:51 [Zakim]
TimBray, if you meant to query the queue, please say 'q?'; if you meant to replace the queue, please say 'queue= ...'
16:17:52 [TimBray]
16:18:02 [Norm]
16:18:08 [Ian]
DC: Addresses take on meaning by communication.
16:18:18 [Ian]
DC: We're not talking about unique addresses, just unambiguous addresses.
16:18:26 [DanC]
TimBL said the latter
16:18:27 [Ian]
(s/DC/TBL last comment)
16:18:29 [Ian]
thanks DC
16:18:31 [ChrisL]
The World is the Universe of Resources. The Web is the Universe of Network Acessible Resources
16:18:32 [Dave]
Ian, you missed my point
16:18:36 [Stuart]
\me just dereferenced Dan's car :-)
16:19:29 [TimBL]
Sorry, the requested resource does not exist <- dan's car
16:19:32 [Dave]
DO: perhaps there are computational and physical resources, and there is a separation between them in terms of addressability
16:19:35 [Stuart]
16:19:40 [Ian]
TB: In real terms, architecture is something developers care about. I think that a resource in the meaningful operational sense is one that can be network addressable. I don't think that operationally, it's useful to consider a car a resource.
16:19:42 [TimBL]
16:19:46 [TimBL]
ack t
16:19:48 [DanC]
no! please let's all lear to stop saying that resources can be retrieved. *Representations* of resources can be retrieved
16:20:24 [Ian]
NW: I am surprised that we are having this discussion. I'm not sure what to think about us contesting the point about URIs pointing to real-world objects.
16:20:24 [TimBL]
16:20:43 [Norm]
16:20:45 [Ian]
NW: In response to URIs being network addressable, namespace URIs are specifically required to not be necessarily net addressable.
16:20:54 [Ian]
SW: None of the definitions I've seen are closed.
16:21:05 [Ian]
"As in: This thing cannot be a resource."
16:21:14 [TimBL]
(The RDF URI#frag being different comes from the web architecture .. function of mime type)
16:21:24 [Ian]
SW: I would prefer to not make the distinction between an HTTP-type resource and an RDF-type resource.
16:21:38 [ChrisL]
16:21:44 [Ian]
SW: ...maybe definition of resources is expanding.
16:22:11 [Ian]
DC: Everyone please don't say "Resources can be retrieved." No. representations can be retrieved.
16:22:23 [DanC]
Norm, we don't need any new schemes to identify my car
16:22:29 [DanC]
16:23:18 [Ian]
TimBL: It's valuable to regard HTTP as a protocol that talks about the class of things called documents. They have representations you can transfer as bits. So, a representation of an image is a set of bits that encode visual information.
16:23:27 [TimBray]
16:23:36 [ChrisL]
OK except for use of the word document
16:23:36 [Ian]
TimBL: Around that, I feel that HTTP is consistent. It tells you whether it can give you the resource or not.
16:24:09 [Ian]
TimBL: HTTP is built to allow you to give a URI to a car.
16:24:13 [DanC]
Norm, it doesn't lead to contradiction, tim.
16:24:19 [DanC]
16:24:29 [Ian]
16:24:31 [Ian]
16:24:39 [Stuart]
From RFC2396 defn of Resource: "Not all resources are network
16:24:40 [Stuart]
"retrievable"; e.g., human beings, corporations, and bound
16:24:40 [Stuart]
books in a library can also be considered resources.
16:24:53 [DanC]
yes, my friggin IRC client does unauthorized completion
16:25:01 [Ian]
TimBL: In RDF, fragment identifier is used to identify abstract concepts.
16:25:24 [Ian]
TimBL: The way I saw getting over this dichotomy between two definitions is to say:
16:25:35 [Ian]
- Without the "#", an HTTP URI is restricted to talk about documents.
16:25:49 [DanC]
16:25:53 [Ian]
- You bootstrap yourself into the real world by defining the connection in the format.
16:25:54 [ChrisL]
16:26:28 [Ian]
TimBL: I have a home page that has a URI. It was born in 1991. I was born in 19XX.
16:26:40 [TimBL]
16:26:44 [Ian]
TimBL: I want to be able to distinguish the car from the document about the car.
16:26:57 [TimBL]
16:27:01 [Ian]
TimBL: HTTP doesn't give us the ability to separately ask about the car and the document about the car.
16:27:02 [TimBL]
ack t
16:27:12 [ChrisL]
ack timbl
16:27:32 [Stuart]
\me process question... do we want to make it through the other pieces too?
16:27:42 [Ian]
TB: One could probably built a consistent set of mathematics about what a resource is. What turns out to be more interesting? I could see a world where a car has a URI. But not clear to me what you would build there.
16:28:01 [Ian]
TB: Seems like a deep distinction between a resource that exists as an electronic object and something that doesn't exist.
16:28:15 [Ian]
16:28:25 [Ian]
DO: This is the bits v. atoms discussion.
16:28:54 [TimBL]
(IMO, A car could have a URI, but not a http URI given HTTP 1.1)
16:28:59 [Ian]
TB: Perhaps a resource is something you get representation of. The representation is always electronic. Perhaps that's a useful place to start building the superstructure: a resource is something that has at least one electronic representation.
16:29:44 [Ian]
DC: I dispute TBL's assertion that there was a contradiction. I agree that it's unwise to use the same identifier for two things (since you can't tell them apart).
16:30:04 [Stuart]
16:30:24 [Ian]
TBL: My interpretation is that HTTP 300, 200, and 404 responses all talk about documents.
16:30:45 [Ian]
...anytime you dereference the URI, you get documents. And documents and cars are distinct.
16:31:00 [Ian]
DC: You haven't shown the contradiction in my assertion that "This URI identifies my car."
16:31:25 [Ian]
CL: Why is fragment identifier in RDF not "part of a resource" as in other formats?
16:32:25 [Ian]
TimBL: "Fragment" is unfortunate term since not always identifying a subpart. Meaning of what is identified is language-dependent.
16:32:33 [DanC]
one way to say it: doc#name refers to whatever doc means by name.
16:33:20 [ChrisL]
Dan's definition is the same as a fragment identifier
16:33:29 [ChrisL]
Tims definition is very different, it seesm
16:33:43 [TimBL]
16:33:53 [Ian]
CL: The definition here is the current definition of the mime identifier.
16:34:04 [TimBL]
ack d
16:34:07 [TimBL]
ack c
16:34:10 [TimBL]
16:34:18 [TimBL]
ack ian
16:34:44 [DanC]
but earlier in the meeting, we established (or at least: TimBL suggested) that a telnet: resource has no electronic representation.
16:35:55 [Ian]
IJ: Author can choose preferred representation. I can therefore say "this photo is what I want as the representation of DC's car." It follows that DC's definition follows.
16:36:18 [Ian]
ack Stuart
16:36:42 [TimBL]
TBray: A telente: resource is more lik an html page than a car
16:36:46 [Ian]
SW: This discussion started as "What's a URI?". We moved to HTTP URIs specifically. Do we want to restrict ourselves to HTP URIs only?
16:37:14 [Ian]
SW: How do we move forward/
16:37:15 [Ian]
16:37:39 [Ian]
DC: Authors suggested they would give another round?
16:38:14 [TimBL]
16:38:19 [TimBL]
16:38:26 [Ian]
IJ: I suggest documenting the topic inline (can your car be said to be a resource?)
16:38:30 [Ian]
16:38:33 [Ian]
What does a document mean?
16:38:54 [Ian]
NW: I propose to come back to this in one week?
16:39:38 [Ian]
NW: No technical differences between 7 and 14 march drafts.
16:40:03 [Ian]
16:40:22 [Ian]
Action NW: Send revision this week to www-tag.
16:40:26 [Ian]
16:40:27 [Ian]
Rest summary
16:40:33 [TimBL]
16:40:51 [DanC]
16:41:33 [Ian]
DC: We used "object" in intro, rather than "resource". Got a public comment to use "thing" instead.
16:41:50 [ChrisL]
object is problematic, what are its methods?
16:42:04 [ChrisL]
thing is suitably vague
16:42:09 [Ian]
DC: The point of the web arch is that it builds the illusion of a shared information space.
16:42:14 [TimBray]
we should bloody well agree what we mean and say "resource"
16:42:25 [ChrisL]
16:43:00 [TimBL]
16:43:10 [TimBL]
ack d
16:43:14 [Ian]
DC: Please connect to other sections. E.g., Web servers and clients talk to each other, and the net effect is that everyone agrees "to what's on the whiteboard"
16:44:10 [Ian]
TimBL: We need REST to create the illusion of a shared space. What we've been battling over is that most people mean "shared information space" but that some things are not part of REST (e.g., automotive industry, telnet).
16:44:33 [Ian]
TBL: W3C has in the past focused on the shared information space. But we are extending the boundaries (e.g., web services).
16:45:13 [Ian]
TBL: Perhaps we should say that the information space model doesn't work for all things we are interested in. Are they in fact distinct?
16:45:17 [ChrisL]
I wonder if Telnet is not 'in the web' because it is a stream of text?
16:45:22 [Ian]
DC: Doesn't appeal to me on the surface.
16:45:38 [Ian]
IJ: Dan's scanner is on the Web already.
16:45:43 [ChrisL]
if so, is a streaming audio or video 'not on the Web'?
16:45:50 [TimBray]
is telnet really on the web? Hmmmmmmmmmmmmmm
16:46:04 [TimBray]
if telnet is, email is
16:46:12 [DanC]
email very definitly is.
16:46:21 [Ian]
DO: I support the idea that we say what parts of the Web conform to the notion of the shared information space. We should say what isn't in that space (if it's not).
16:47:00 [TimBray]
Any individual email message can be
16:47:09 [ChrisL]
TimBL alluded earlier to mailto being in the Web but the email message itself not being (until archived, presumablky) but its clearly a message. And that messages are nopt on the web, they produce the illusion of the Web
16:47:16 [Ian]
TB: You can give the address of a Web service port. You can *integrate* web services (and interconnections are important). But conceptually, the information space metaphor works in some areas but not others.
16:47:37 [DanC]
DC [also said]: a lot of the work I've done for the last year or so is integrating my office phone into the web... and the IRC channels I use.
16:47:49 [DanC]
cf "Real-Time Resources in the Web: IRC, Telephone, Instant Messaging"
16:47:51 [Ian]
DO: I'm on Web Services Architecture WG and have been pounding the table to get REST components in the Web services architectuer.
16:48:02 [TimBray]
when I get POPmail via Eudora, it doesn't feel like the web is involved
16:48:08 [Ian]
DO: Interesting to see how close various definitions get to qualifying.
16:48:16 [DanC]
POP could easily be done over HTTP.
16:48:36 [ChrisL]
HTTP could be (and has been) done over POP
16:49:26 [Ian]
TB Summarizing IRC thread: Does the Web architecture have to comprise {email | telnet} as a first class citizen?
16:49:32 [ChrisL]
TB: Is emaila first class citizen
16:50:15 [Ian]
TB: How far do you have to strain your definition of URI to include telnet sessions........
16:50:27 [Ian]
TBL: Split into two groups of URIs - information space and not.
16:50:30 [Stuart]
16:50:36 [Ian]
DC: I don't agree with that on the face of it.
16:51:03 [Ian]
SW: What about URIs being opaque (if we are distinguishing them)?
16:51:26 [Ian]
DO: What can RF and I do to change our document on REST?
16:51:37 [Ian]
TimBL: Rather than just documenting REST, explain how it supports the information space.
16:52:15 [Ian]
TBL: This chapter explains "if you've got packets, here's how you get information space"
16:52:45 [Ian]
DO: Perhaps elsewhere in the document series, we should talk about shared info space.
16:53:34 [Ian]
DO: Should this document be expanded to talk about the shared information space (and then describe how REST is used to implement that0.
16:53:42 [Ian]
TimBL: Move the info space to the front of the document.
16:55:18 [Ian]
Action DO: Write text about information space, to be integrated by IJ.
16:55:20 [Ian]
16:55:26 [Ian]
What does a message mean?
16:55:33 [TimBL]
16:55:50 [Ian]
CL: I'm in the middle of writing these notes up.
16:56:28 [Ian]
TB: RF jumped on this one because of RFC822
16:57:52 [Ian]
TB: I would line up with RF on this.
16:58:04 [Ian]
...seems like the notion of 1-2 headers + bag of bits is pretty useful.
16:58:10 [DanC]
line up "sorta".
16:59:14 [Ian]
TBL: Reason why people feel headers are harmful is that the way they combined is not well-defined.
16:59:33 [Ian] least XML has well-defined structure. RDF defines combination.
16:59:54 [Ian] 822, you don't have the structure; algos built on top are hard to rely on.
17:00:02 [Ian]
TB: Having said that, it works pretty well.
17:00:14 [Ian]
DC: About 5 work well. Very hard to extend.
17:00:21 [Ian]
TB: But we've hit the 80/20 point.
17:00:22 [ChrisL]
So, don't add new headers but use a core set that works already
17:00:39 [Ian]
CL: What happened with HTTP extensions?
17:00:40 [TimBL]
17:00:41 [Ian]
DC: Didn't take off.
17:00:59 [TimBray]
17:01:01 [Ian]
TBL: Required everyone to implement mandatory extensions.
17:01:05 [Zakim]
17:01:07 [Ian]
17:01:15 [Ian]
Next meeting: Next week same time, same place.
17:01:17 [Ian]
17:01:29 [ChrisL]
I have to go, another telcon
17:01:35 [Zakim]
17:01:37 [Norm]
Since we can get to the bridge 5 minutes before the call, I concur with TimBL
17:01:44 [TimBL]
RRSAgent, stop