IRC log of tagmem on 2002-04-22

Timestamps are in UTC.

12:55:09 [RRSAgent]
RRSAgent has joined #tagmem
12:55:15 [Zakim]
Zakim has joined #tagmem
13:41:47 [DanCon]
DanCon has joined #tagmem
14:17:24 [Norm]
Norm has joined #tagmem
14:22:12 [Stuart]
Stuart has joined #tagmem
14:25:20 [DanCon]
that was *almost* suggested text. But it wasn't actual suggested text.
14:25:57 [DanCon]
folks seem to feel free to spout whatever opinion comes to mind, with no obligation to contribute to an architecture document.
14:26:17 [DanCon]
not your posting, Stuart.
14:26:20 [DanCon]
but most of the others.
14:26:42 [DanCon]
RRSAgent, pointer?
14:26:42 [RRSAgent]
14:26:46 [Stuart]
yep... it's a big thread...
14:26:57 [Stuart]
What is RRSAgent?
14:27:08 [DanCon]
a log-to-http-space service
14:27:34 [DanCon]
it does a few other things... tracks action items, I think. try: /msg RRSAgent help
14:30:24 [Norm]
zakim, list conferences
14:30:25 [Zakim]
I see VB_Multi()10:00AM, Team_Comm()9:30AM, T&S_()10:00AM, TAG_Weekly()10:00AM
14:30:35 [DanCon]
Zakim, this will be TAG
14:30:36 [Zakim]
ok, DanCon, I see TAG_Weekly()10:00AM already started
14:30:44 [Norm]
Dan beat me to it
14:32:57 [Zakim]
14:33:41 [Zakim]
14:34:00 [Ian]
zakim, who's here?
14:34:01 [Zakim]
I see ??P32, ??P34, ??P2, DanC, Ian
14:34:12 [Ian]
zakim, ??P32 might be Paul
14:34:13 [Zakim]
I don't understand '??P32 might be Paul', Ian. Try /msg Zakim help
14:34:19 [Ian]
zakim, ??P32 may be Paul
14:34:20 [Zakim]
+Paul?; got it
14:34:32 [Ian]
zakim, ??P34 may be Stuart
14:34:33 [Zakim]
+Stuart?; got it
14:34:39 [Ian]
zakim, ??P2 may be Norm
14:34:40 [Zakim]
+Norm?; got it
14:34:49 [Zakim]
14:35:10 [Ian]
zakim, mute Norm
14:35:11 [Zakim]
Norm? should now be muted
14:35:35 [Ian]
zakim, Norm is Paul
14:35:36 [Zakim]
+Paul; got it
14:35:43 [Ian]
zakim, who's here?
14:35:44 [Zakim]
I see Paul?, Stuart?, Paul (muted), DanC, Ian, TBray
14:35:54 [Ian]
zakim, unmute Paul
14:35:55 [Zakim]
'Paul' is ambiguous, Ian
14:36:05 [Ian]
zakim, mute Paul?
14:36:07 [Zakim]
Paul? should now be muted
14:36:15 [Norm]
zakim, who's here?
14:36:17 [Zakim]
I see Paul? (muted), Stuart?, Paul (muted), DanC, Ian, TBray
14:36:24 [Ian]
zakim, Paul? is Stuart
14:36:25 [Zakim]
+Stuart; got it
14:36:26 [Stuart]
can you hear me
14:36:30 [Norm]
14:36:34 [Ian]
zakim, Stuart? is Norm
14:36:35 [Zakim]
+Norm; got it
14:36:40 [Stuart]
then I'm muted
14:36:43 [Ian]
zakim, unmute Paul
14:36:44 [Zakim]
Paul should no longer be muted
14:36:47 [Ian]
zakim, who's here?
14:36:49 [Zakim]
I see Stuart (muted), Norm, Paul, DanC, Ian, TBray
14:36:54 [DanCon]
ack Stuart
14:36:56 [Ian]
zakim, unmute Stuart
14:36:57 [Zakim]
Stuart was not muted, Ian
14:37:07 [Norm]
zakim, who's here
14:37:10 [Zakim]
Norm, you need to end that query with '?'
14:37:15 [Ian]
Regrets: TBL
14:37:18 [DanCon]
Stuart: not here yet: DaveO, RoyF, TimBL
14:37:22 [Norm]
zakim, who's here?
14:37:23 [Zakim]
I see Stuart, Norm, Paul, DanC, Ian, TBray
14:37:27 [DanCon]
Stuart: not here yet: DaveO, RoyF, TimBL, ChrisL
14:37:59 [Ian]
14:38:07 [Ian]
Minutes of previous meeting? No objections.
14:38:17 [Ian]
Comments on this agenda?
14:38:23 [Zakim]
14:38:32 [Ian]
SW: I've put time allotments on the agenda; I hope it's useful.
14:38:53 [Ian]
14:39:35 [Ian]
SW: Additions? None.
14:39:45 [Ian]
Action item review:
14:39:56 [Ian]
DO: Write text about "Web as information space", to be integrated by IJ. Status - not done.
14:40:07 [Ian]
IJ: Integrate/combine one-page summaries. Status - not done
14:40:48 [Ian]
TBL Actions not done.
14:40:56 [Ian]
RF: Write up discussion of RFC3205 based on www-tag input.
14:41:02 [Ian]
Status Done:
14:41:53 [Ian]
DC: I propose to withdraw the action.
14:42:16 [Ian]
DC: Correction - RF's message is a proposal to withdraw the action.
14:42:38 [Ian]
SW: Action hereby withdrawn; we'll pick up when we address HTTPSubstrate-16.
14:42:43 [Ian]
14:42:50 [Ian]
Prioritization of issues list.
14:42:55 [Ian]
Strawman from SW:
14:43:45 [Ian]
DC: For me the priority is whatever goes first in the arch doc. I find it hard to address these issues without context.
14:43:53 [Zakim]
14:43:55 [TBray]
TBray has joined #tagmem
14:43:57 [Ian]
SW: So, order by doc order, not urgency/sense of importance.
14:44:12 [Ian]
DC: Doc order is not arbitrary; things earlier should depend on fewer other things.
14:44:15 [TBray]
Hah... figured out my IRC client
14:44:17 [Ian]
zakim, ??P0 is Roy
14:44:17 [Zakim]
+Roy; got it
14:44:19 [DanCon]
Zakim, ??P0 is RoyF
14:44:22 [Zakim]
sorry, DanCon, I do not recognize a party named '??P0'
14:45:30 [Ian]
TB: Two thoughts:
14:45:41 [Ian]
a) Agree with DC about starting from points of few dependencies outward.
14:45:58 [Ian]
b) Also order based on urgency relative to work going on in w3c.
14:46:16 [Ian]
(e.g., GET in SOAP)
14:47:33 [Ian]
TB: I like SW's list; it seems to meet both criteria (a) and (b).
14:47:45 [Ian]
(with exception of *-13 first).
14:48:30 [Ian]
TB: I propose 7 first, then the rest of the list as is.
14:48:40 [Ian]
TB: 7, 13, 15, 6, 14, 16, 8
14:48:58 [Ian]
SW records no dissent.
14:49:01 [Ian]
14:49:10 [DanCon]
is 13 really supposed to be in that list?
14:49:26 [Ian]
14:49:52 [Ian]
Handle issues in this order: 7, 15, 6, 14, 16, 8, 13
14:49:53 [Dave]
Dave has joined #tagmem
14:49:55 [Ian]
14:50:06 [Ian]
1. Draft Finding on Media-Types how do we progress this finding - is it done?
14:50:12 [Ian]
14:50:24 [Ian]
SW: Where are we on this? Perilously close to done?
14:50:30 [Ian]
TB, DC: I thought we were done.
14:50:54 [Chris]
Chris has joined #tagmem
14:51:29 [Ian]
Resolved: Accept finding on Media-Types.
14:51:32 [Ian]
DC: Was resolved 8 April.
14:51:33 [DanCon]
" Resolved:
14:51:33 [DanCon]
* Accept TAG finding uriMediaType-9 (as amended)." --
14:51:48 [Ian]
Action IJ: Publish this as accepted finding.
14:51:58 [Ian]
SW: Correction on DC's comment, that was uriMediaType-9 findings.
14:52:01 [Zakim]
14:52:03 [TBray]
14:53:08 [Ian]
DC: This thing needs another title.
14:53:36 [Ian]
DC: But I'm not clear we're done with this since I was thinking about something else.
14:53:44 [Ian]
TB: There were grumblings on www-tag, but no loud voices in TAG.
14:53:56 [Ian]
SW: My recollection - three issues tied together. I thought we got closure on 2/3.
14:54:20 [Ian]
NW: I bet grumbling on Namespace-Based Dispatching.
14:55:03 [Chris]
status says "being written" should be "under review" surely
14:55:23 [Ian]
DC: Note that resources don't have mime types, response headers do.
14:55:51 [Norm]
14:56:26 [Ian]
TB: Right, you're not talking about resource here, but message back from server.
14:57:01 [Norm]
14:57:07 [Ian]
NW: I propose removing contentious bit (namespace-based dispatching) and moving to "what does a namespace mean"?
14:57:13 [Ian]
TB, CL: Seconded.
14:57:17 [Chris]
ok, agreed
14:57:19 [Ian]
14:58:04 [Ian]
- Publish as accepted fixing charset sentence, and move to mixedNamespaceMeaning issue.
14:58:08 [Ian]
PC: Agreed.
14:58:09 [DanCon]
PROPOSED: nuke NS section, tweak charset (s/resource/response), accept findings on media types.
14:58:24 [Ian]
Action IJ: Publish finding, move dispatching bit to other issue.
14:58:28 [DanCon]
14:58:35 [Ian]
14:58:41 [Ian]
* "Guidelines For The Use of XML in IETF Protocols" IETF best practices draft requiring URNs for XML namespaces in IETF documents
14:58:45 [Ian]
14:58:55 [Ian]
CL: I sent notes on this:
14:59:22 [Ian]
14:59:33 [Ian]
CL: I said:
15:00:04 [Chris]
"In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. "
15:00:04 [Chris]
Yes, great. Wish we could assign them an action to go do that and say what the base URI is?
15:00:28 [Chris]
for HTTP, that is
15:00:58 [Ian]
TB: Has this draft changed recently?
15:01:03 [DanCon]
"W3C recommended practice" should cite "URIs for W3C namespaces"
15:01:05 [Ian]
SW: I have 15 April on it.
15:01:25 [Ian]
TB: I would bet $100 that when I first read this, pro URN slant was stronger. I may be wrong, though. This version is hard to object to as is.
15:01:48 [Zakim]
15:02:04 [Ian]
SW: Is the IETF wrong to mandate URNs for namespace names?
15:02:10 [Ian]
(section 4.5).
15:02:38 [TBray]
15:02:41 [Ian]
DO: I've read through CL's summary. In general, I would say that most of CL's comments are good personal comments but not required to be TAG comments.
15:02:52 [Ian]
DO: I think the TAG should highlight the particular namespace issue.
15:03:14 [Ian]
TB: This has *clearly* been rewritten since I see that some things have been fixed since I first read it.
15:03:16 [Chris]
TB notes this has *clearly* been rewritten yet still says 01.txt
15:03:32 [Ian]
TB: It would be nice if IETF kept around previous versions.
15:03:53 [Ian]
CL: This isn't the primary source.
15:04:02 [Ian]
DC: They start with "00".
15:04:23 [Chris]
dc notes numbering stats at 00.txt
15:04:29 [Chris]
All: Aha!
15:04:39 [Ian]
Resolved: Postponed to allow TAG to reread.
15:04:45 [Ian]
Homework: Read version 01.
15:05:35 [Ian]
CL: I will resort and prioritize my comments for next week.
15:05:37 [Ian]
15:05:42 [Ian]
When to use GET?
15:05:43 [Chris]
ACTION CL to re-sort notes into priority order for next week
15:06:07 [Ian]
15:06:15 [Ian]
See SW proposal on when to use Post:
15:06:42 [Ian]
DC: Demoralizing to get hundreds of comments without a proposal for alternative.
15:06:55 [Ian]
SW comments:
15:07:16 [Ian]
DC: I didn't hear disagreement about bad idea to subscribe someone to mailing list as result of GET.
15:07:22 [Stuart]
15:07:35 [Ian]
DO: I proposed s/should/may, or to use GET for browser-centric applications.
15:07:59 [Ian]
NW: I am disappointed if we get down to application level in an arch document.
15:08:40 [Ian]
CL: I agree that in general, we should go for generality. But if we can't get agreement on general points, let's consider important specifics (e.g., browsers).
15:08:45 [Ian]
TB: I proposed a solution:
15:08:52 [Ian]
15:09:13 [Dave]
15:09:23 [Ian]
TB: "
15:09:25 [Ian]
"I propose that for those proportion of SOAP requests that consist of a
15:09:25 [Ian]
service name plus a sequence of name-value-pair arguments, we devise a
15:09:25 [Ian]
simple url encoding.
15:09:25 [Ian]
15:09:52 [Ian]
TB: I made this proposal in good faith, even if it had been suggested before.
15:09:58 [Stuart]
ack TBray
15:10:03 [Ian]
DO: I find the suggestion interesting, but I don't think it addresses most peoples' issues.
15:10:26 [Ian]
DO: I think that people who want to use GET for safe methods won't be satisfied. People who are adamantly for POST won't be happy either.
15:10:34 [Zakim]
15:10:46 [DanCon]
hmm... as to whether the case when SOAP stuff can be url-encoded being a small number of cases... seems to me it's the big part of the 80/20 bucket. e.g. the hello-world SOAP app, getStockQuote, fits quite neatly
15:10:46 [Ian]
zakim, ??P18 is Paul
15:10:47 [Zakim]
+Paul; got it
15:10:51 [Ian]
zakim, who's here?
15:10:52 [Zakim]
I see Stuart, Norm, DanC, Ian, TBray, DOrchard, Roy, ChrisL, Paul
15:10:59 [Stuart]
15:11:07 [Ian]
ack dave
15:11:09 [Chris]
ack Dave
15:11:10 [TBray]
15:11:22 [Ian]
DC: URL-encoding hasn't picked up any steam.
15:11:38 [Ian]
DC: See comments from Mark Nottingham -
15:11:47 [Ian]
...WG not excited by this before.
15:11:55 [Ian]
TB: But if the TAG is expressing interest in this, that might help.
15:12:52 [Ian]
DO: There are a couple of people in XMLP WG who are interested in this topic. Why is there such a clean disconnect between these two polar views?
15:13:08 [Ian]
DO: I don't think that just saying "you're doing it wrong" addresses the gap in understanding.
15:13:39 [Ian]
DC: I've talked to 5 people XMLP WG and all of them said "Yes, GET would be the more straightforward method for simple applications like stock quotes."
15:13:56 [Ian]
DC: And I hear XMLP WG participants saying "We're not interested in the simple applications."
15:14:06 [Ian]
DO: But we hate the stock quote example.
15:14:19 [Ian]
DO: I'd like to hear how use of POST is actively harmful and how GET would be better.
15:14:27 [Ian]
DC: Paul Prescod, TB gave reasons.
15:14:51 [Ian]
PP's email:
15:14:52 [Chris]
15:15:08 [Stuart]
ack DanCon
15:15:10 [Ian]
DO: Reasons for certain styles of applications have been given. But there are other classes of applications where it's not clear.
15:15:19 [Ian]
DO: I don't think it comes up in practice.
15:15:33 [Ian]
RF: Paul is describing Web applications. The Web Services community is not dealing with Web applications.
15:15:37 [Ian]
DO: I liked RF's posting:
15:16:00 [DanCon]
"urls for everything"??? execpt information available via SOAP services.
15:16:32 [Ian]
RF: Web Services doesn't use URLs for everything. That's the problem. If something uses a URL to identify something makes it a Web application.
15:16:42 [TBray]
15:16:57 [Ian]
RF: Here's the exact principle involved: "URIs should be used to identify all important resources." Web services doesn't do this.
15:17:17 [Ian]
RF: The reason you want to use GET is that it requires URI for identification; that makes it available to other applications on the Web.
15:17:37 [Ian]
DO: I lobbied that part of definition of a Web Service was that it be addressable by URI. That's been accepted as a draft definition.
15:17:44 [Ian]
DC: The price of the stock is not addressable.
15:17:46 [Ian]
15:17:52 [Ian]
ack TBray
15:18:02 [Ian]
TB: DO and I drawing 2 conclusions from same facts.
15:18:24 [DanCon]
hmm... reviewing looking for what's now considered the meat-and-potatoes applications of SOAP.
15:18:45 [Ian]
TB: I disagree that stock quotes as hello world is a small subset of Web Services; I think it's a more important class; I think should be addressable by URL; I proposed a simple approach for doing this; I'd like to hear a cogent reason why not a good idea.
15:19:12 [Ian]
RF: If the same naming authority, that server can define any URI for that service; better than a service with no URIs into it.
15:19:57 [Ian]
TB: I agree that a large proportion of Web Services transactions may be densely structured, unsafe, etc. I don't see the benefit of going after those. But for the subset of request/response that are safe, let's use URL-encoding.
15:20:21 [Ian]
DO: Did you see MN's response on URL length?
15:20:35 [Ian]
TB: I've been doing this for years; never seen an application break due to URL length.
15:21:13 [Ian]
RF: The overall issue - if URLs tend to be long in a service, then all of the technology between them and the client improves over time. I think it's been at least six years since 256 char limits on URLs.
15:21:31 [Dave]
15:21:34 [Chris]
There is a class of application where POST is superior to GET when sending a message body such as a form result - unambiguous charset encoding for the body. Known problem with interoperability of forms in multilingual sites that depend on "charset of origin page" when url is bookmarked and there is no origin page
15:21:39 [Ian]
TB: Any anything you can't pack into a reasonable URL length is probably not good candidate for GET anyway.
15:22:11 [DanCon]
I considered writing up this "if it's long, it's not addressable" and Larry has already given counter-examples: "validation result for this (appended) document?" or... "images like this one?"
15:22:42 [Ian]
15:22:48 [Ian]
ack Chris
15:22:53 [DanCon]
(not counter-examples, exactly, but... er... nevermind)
15:22:55 [Stuart]
15:23:30 [Ian]
RF: There's no basis for "everything must use GET" in Web architecture. There is for "use an URI for everything that's important".
15:23:42 [Stuart]
ack Dave
15:24:30 [Ian]
DO: I personally have gone to significant effort to harmonize Web services with the Web (use of URIs, use of XML, right use of HTTP). But to find out my efforts have been in vain (still doing the wrong thing) is disappointing.
15:24:51 [Ian]
DO: If we are using URIs wrong, a more problematic area of misunderstanding.
15:25:22 [Ian]
TB: I assert that there are classes of Web Services that are addressable by URI and accessible by GET. Web services (SOAP) today does not enable that. There is a low cost solution to address this.
15:25:58 [DanCon]
hmm... after scanning the SOAP primer, I don't see any discussion of mapping Java/Perl/python method calls to SOAP calls. did 'object access' go away somewhere?
15:25:59 [Ian]
DO: TB has said that to hit the 80/20 point, it would be useful to have this particular feature. I am not saying this is uninteresting. I just don't think it's a principle of the Web.
15:26:14 [Ian]
TB: I would argue that first principle of Web is that things have URIs and bet GETable.
15:27:05 [Ian]
Refer to finding -9:
15:27:11 [Ian]
" * All important resources should be identifiable by URI.
15:27:11 [Ian]
15:27:27 [Stuart]
ack Stuart
15:27:42 [Ian]
DO: I think we are allowing Web Services to be addressable by URI.
15:27:56 [Ian]
DC: The results are addressable in the case of GET but not of POST.
15:29:14 [Ian]
[DC talking about SOAP features]
15:29:22 [TBray]
Ian: DO: TB has said that to hit the 80/20 point, it would be useful to have this particular feature. I am not saying this is uninteresting. I just don't think it's a principle of the Web.
15:29:22 [TBray]
Ian: TB: I would argue that first principle of Web is that things have URIs and bet GETable.
15:29:22 [TBray]
Ian: Refer to finding -9:
15:29:22 [TBray]
Ian: " * All important resources should be identifiable by URI.
15:29:25 [TBray]
Ian: "
15:29:26 [TBray]
DanCon q+
15:29:29 [TBray]
Zakim sees Stuart, DanCon on the speaker queue
15:29:56 [TBray]
Oops... had a little IRC error there
15:29:56 [Ian]
[DC comments on Primer]
15:30:13 [Ian]
PC: I don't think that the primer has ever used the term "java" or described the scenario DC described.
15:30:46 [Ian]
DC: The scenario is there in the larger community [Scribe didn't get scenario, but about querying to find out about safe methods]
15:31:05 [TBray]
15:31:44 [Ian]
PC: DC, you must distinguish the evolution of the use of SOAP. In scenario where URI points to an encapsulation of our favorite logic (and service described in WSDL, which can be consumed by SOAP-enabled software); this kickstarted SOAP from existing services, but lots of people today are writing their WSDL directly.
15:31:57 [Stuart]
ack DanCon
15:32:30 [Ian]
DO: I hear people saying coarse-grain interactions more useful; avoid a multitude of back-and-forth interactions.
15:32:57 [Ian]
PC: Most of these document-centered objects are synchronous. Typically you want your web service to be asynch.
15:32:59 [TBray]
15:33:14 [Ian]
DC: Summarizing - taking your API and hitting the button to create a Web Service is apparently no longer the right thing to do.
15:34:04 [Ian]
TB: As an XML editor, I am profoundly uninterested in Web Service community's predictions about how the tools they are producing will be used.
15:34:17 [Norm]
"No one expects the Spanish Inquisition"
15:34:28 [Ian]
TB: My personal opinion is that a low-rent RPC request/response based on SOAP wrappers will be widely used.
15:34:35 [Dave]
norm, lol
15:34:45 [Ian]
TB: ...but whether widely used or not widely used, why isn't a good thing to expose as a URI.
15:35:20 [Ian]
SW: Are we going to say anything about the use of POST to do safe things?
15:35:24 [Ian]
DC: That seems in order.
15:35:58 [Ian]
Action DC: Write more on whenToUseGet.
15:36:12 [Ian]
DC: Look at it more as "make things addressable"
15:36:18 [Ian]
15:36:21 [Chris]
to concentrate on "make things addressable"
15:36:36 [Ian]
15:37:00 [Ian]
Architecture Document, Status, Discussion
15:37:10 [Ian]
IJ: Not much progress due to ongoing work on Process Doc and UAAG 1.0.
15:37:54 [Ian]
PC: What about status of this doc at AC meeting?
15:38:06 [Ian]
IJ: TBL's slides point more to categorization than arch document.
15:38:21 [Ian]
PC: Should we get AC to read this before the meeting?
15:38:25 [Ian]
RF: Seems unlikely.
15:38:54 [Stuart]
15:39:10 [Stuart]
ack TBray
15:40:01 [Ian]
IJ: AC agenda will be sent out soon.
15:40:23 [Ian]
PC: I think the agenda is too late.
15:41:34 [Ian]
SW: What about feedback on other pieces to go in arch document?
15:43:16 [Ian]
Looking at: Current State slide
15:44:04 [Ian]
PC: Point to arch doc IJ has been working on?
15:44:09 [Ian]
IJ: I don't think it's mature enough yet.
15:44:38 [Ian]
IJ: I intend to make progress on this this week.
15:44:55 [Ian]
[PC may not be at next week's meeting.]
15:45:10 [Ian]
PC: Will there be a monthly summary end of April?
15:45:13 [Ian]
IJ: Yes, I intend to.
15:46:08 [Ian]
Next meeting: 29 April.
15:46:42 [Ian]
15:46:46 [Zakim]
15:46:51 [Zakim]
15:46:54 [Zakim]
15:46:55 [Zakim]
15:47:00 [Ian]
RRSAgent, stop