02:04:20 DanC_lap has joined #tagmem 12:45:08 RRSAgent has joined #tagmem 12:45:08 logging to http://www.w3.org/2005/06/15-tagmem-irc 12:45:51 Zakim, this conference is TAG f2f June 15, 2005 (day2) 12:45:53 sorry, Ed, I do not see a conference named 'TAG f2f June 15, 2005 (day2)' in progress or scheduled at this time 12:46:06 Zakim, this conference is TAG 12:46:06 Ed, I see TAG_f2f()8:30AM in the schedule but not yet started. Perhaps you mean "this will be TAG". 12:46:23 Zakim, this conference will be TAG 12:46:26 ok, Ed; I see TAG_f2f()8:30AM scheduled to start 16 minutes ago 12:47:29 Meeting: TAG f2f June 15, 2005 (day 2) 12:47:40 Roy has joined #tagmem 12:48:28 Scribe: Ed 12:51:21 Agenda: 12:51:23 http://www.w3.org/2001/tag/2005/06/14-agenda.html 12:52:59 Vincent has joined #tagmem 12:54:15 DanC_lap has joined #tagmem 12:54:24 timbl has joined #tagmem 12:54:42 Vincent: eash scribe is responsible for editing minutes 12:55:10 Vincent: formatted html. 12:55:57 Vincent: Ed scribes in the am, Norm in the afternoon. 12:56:54 TOPIC: review document that Dan sent out at the end of the meeting 12:57:10 noah_home has joined #tagmem 12:57:25 Norm has joined #tagmem 12:57:47 DanC_mob has left #tagmem 12:58:12 -> http://lists.w3.org/Archives/Public/www-archive/2005Jun/att-0007/tag-directions.html outline 12:58:47 ht has joined #tagmem 13:02:53 Vincent: What do we do with this list? 13:03:02 - it helps us do our work 13:03:06 -or- 13:03:19 - it may also be the outline of a document we need to publish. 13:04:12 Vincent: This is a 12 month issues list. 13:04:23 Ed: Should we try and reduce the list? 13:04:49 TB: this should be a live document, and we should review periodically. 13:07:53 Noah: Pick 3-5 to start with, we may need to narrow down to 2-3. 13:08:27 TBL: Healthy for us to have more than one thread. 13:11:20 Vincent: This list is a guideline for our work, we need to go through this and set priorities. Pick a few 2,3 or 4 to work on over the next few months. 13:17:56 Vote was taken to prioritize list... outcome was; 13:20:01 top items selected were ; 13:20:08 1) Web applications 13:20:15 2) Security 13:20:22 3) Semantic Web 13:26:38 http-Range-14 is assume to remain the 'urgent' priority 13:28:21 Ed: lots of people have javascript turned off... maybe 18% of the visitors to HP web sites 13:29:58 Henry: solving issues such as Javascript interop and SVG native in browsers should also be considered. 13:31:03 TimBL: Why do people hold their noses wrt the DOM? 13:31:33 HST: Trying to do a language-independent API led to bad APIs for each of the language-specific binding 13:37:26 TBL: W3C as a working group could help produce a lot more tests around DOM. 13:38:08 W3C needs to be involved in the release of browswers in order to make this work. We havent been involved in the past. 13:38:37 Noah: There is a real trap in not getting in touch with our customers/vendors to find out where they're trying to take this stuff. 13:39:32 E4X example: http://weblog.infoworld.com/udell/2004/09/29.html 13:41:20 HT: seems to me that I feel like there is an opportunity to do it another way, other than using java script. 13:42:18 HT/Dan: if we could get the browser creators to sign-up for fixing the interop problem, there would be a large benefit. 13:42:56 s/using java script/fixing java script/ 13:44:47 Vincent: On web applications the group doesnt exist yet and even the charter doesnt exist yet. 13:45:09 If we can comment on the charter and make sure it address what we feel is important. 13:45:48 Once the group starts we can give input on the issues with the team. Helping them start without producing something signficant ourselves (work through the wg) 13:46:45 Vicnent: Other topics we can do in the short-term? 13:48:08 Dan: Should we be involved with the web apps charter? 13:49:02 http://www.cairographics.org/xr_ols2003/ 13:49:40 ACTION: Dan to get web applications charter and share it with the TAG for review. 13:50:05 HST finds the E4X example underwhelming -- like XQuery, but with idiosyncratic syntax 13:50:22 http://www.mozilla.org/projects/xul/ 13:55:00 Avalon: http://winfx.msdn.microsoft.com/library/en-us/wcp_conceptual/winfx/port_tech_wcp.asp 13:56:33 Noah: We need to look for things that stress web architecture 13:56:41 I'd like to hear from Zeldman ( http://www.zeldman.com/ ) on javascript interoperability and webapps 13:57:31 http://javascript.weblogsinc.com/entry/1234000893027332/ 13:57:39 Vincent: We are also looking at moving from Procedural to declarative languages 13:58:04 Haystack: http://haystack.lcs.mit.edu/ 13:58:05 TBL: Lots of people have reversable xslt processes. 13:59:07 Brendan Eich on "Remixable Applications": http://javascript.weblogsinc.com/entry/1234000720046078 14:04:33 'Remixable applications' turns out to mean Greasemonkey 14:04:41 http://greasemonkey.mozdev.org/ 14:05:35 Ed has joined #tagmem 14:05:49 Adenine: http://haystack.lcs.mit.edu/papers/sow2002-adenine.pdf 14:07:41 NM: Flash was less of a threat because it was typically only a part of a page, google could still get you there, but that's changing 14:08:14 ... We're seeing pages which are 100% flash, so nothing to get ahold off -- Avalon same deal 14:09:25 TRAMP: http://www.aaronsw.com/2002/tramp 14:11:02 dorchard has joined #tagmem 14:11:16 dave, we'll dial in 14:11:27 thx! 14:11:28 zakim, who is on the phone? 14:11:28 TAG_f2f()8:30AM has not yet started, ht 14:11:29 On IRC I see dorchard, Ed, ht, noah, timbl, DanC_lap, Vincent, Roy, RRSAgent, Zakim, DanC 14:11:31 TAG_f2f()8:30AM has now started 14:11:38 +DOrchard 14:11:45 +MIT601 14:13:13 the 3 that emerged as popular were: security, Web Apps, Semantic Web 14:14:05 others that got some votes... Side effects, user identity, state, context 14:16:06 ACTION VQ: invite Dean to a TAG teleconference 14:16:13 timezone challenges noted 14:17:22 DO: note the new mailing list on web description formats; seems relevant to web apps 14:17:40 Norm has joined #tagmem 14:18:04 http://lists.w3.org/Archives/Public/public-web-http-desc/ 14:18:41 DO: these description formats are, for example, for the Amazon search service; URI encoding conventions, etc. 14:19:43 (I'm kinda mystified by this; I thought WSDL was supposed to do this stuff) 14:20:16 NDW: our webapps discussion was more about gmail, google maps... client-side dynamic stuff 14:22:05 DO: hmm... the more stuff that's done in turing-complete formats, the lest you can do with declarative stuff [er... something like that] 14:22:33 DC: exactly. [The Principle of Least Power] I think the TAG hasn't written this down the way we should 14:25:09 NM: have you seen all these services layered on google maps? cheap gas and all... 14:25:44 Mark Nottingham's intro use cases for web description (HST still not really getting what the subject matter is . . .): http://www.mnot.net/blog/2004/06/14/desc_usecases 14:27:43 --- break for :15, after which resume with security 14:30:22 I've collected a list of web descriptions http://www.pacificspirit.com/Authoring/REST/ 14:56:17 we asymtotically resume, a semi-spontaneous security discussion having broken out during the break 14:56:26 Topic: Security 14:58:34 http://www.faqs.org/rfcs/rfc2617.html 15:05:29 DC: state of the art in auth is: forms + cookies. 15:06:05 ... the security properties are just like HTTP basic, but the UI for HTTP basic is that crappy little dialog with (a) no trademark logo, and (b) no "if you forgot your password..." stuff 15:06:21 DC: digest authenticaion has better security properties, but has the UI problem 15:06:38 ... the 1999 submission that suggested mixing digest auth with forms is still a good idea, IMO 15:06:40 TBL: The virus problem is software on your pc that you didnt realize you asked for. 15:07:14 DC: another security issue is that with basic auth, the server doesn't store the password, but only an encrypted form of it. But with md5, it has to store the password 15:07:31 ht: you only want as much identification as you want/need. 15:07:41 RF: yes, that's a bug in the MD5 spec that, 2 months into the development, the authors said there was "too much deployment to make such a change". argh! 15:07:52 http://www.identityblog.com/ 15:08:15 DC: so shared-secret auth could be a lot better 15:09:18 DC: then there's assymetric-key symmetric key... that's deployed for SSL certs... 15:09:19 ht: the security problem would get better by solving the identiy issue. 15:10:41 Norm has joined #tagmem 15:10:53 Dan: lets work hard to stamp out passwords in the clear 15:11:28 http://www.identityblog.com/stories/2004/12/09/thelaws.html 15:13:05 DC: if we could just do those 2 things, that would be good: (1) avoid passwords in the clear, (2) don't use turing-complete formats unless you have to 15:15:59 http://www.securityfocus.com/infocus/1688 15:16:10 http://www.securityfocus.com/infocus/1691 15:23:06 ... lots of brainstorming, not well-recorded ... 15:23:44 Public key crypto, phishing,.... 15:25:15 discussion: Should we update the web arch or add additional books to volumne 2. 15:25:39 Noah: Findings is a good way to start collecting these things, we can later determine if it raises to the level to update the arch. 15:26:25 Dan: See www.w3.org/DesignIssues/Principles.html 15:27:07 First draft of minutes from yesterday morning have been posted at: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0031.html 15:27:25 http://www.w3.org/DesignIssues/Principles.html#PLP 15:27:55 I will review it 15:28:12 s/it/PLP. 15:28:28 s/raises/rises/ 15:29:10 ACTION: Roy and Norm to review http://www.w3.org/DesignIssues/Principles.html#PLP 15:30:02 http://ai.eecs.umich.edu/cogarch2/prop/declarative-procedural.html 15:30:40 ACTION: Dan to write a report on the state of the art authentication in the web. 15:30:45 "A Report on the Sorry State of Authentication in the Web" 15:32:13 Dan notes this is as much a recruiting document to help solicit input from additional experts in the area. 15:33:29 TBL: Need to inform users and users and those who write browsers 15:36:31 TBL: suggests TAG should make suggestions, address bar and Icon changes to denote links/security. 15:38:49 TBL: some actions in Browser should not be allowed. For example, hover over link should show the true link at the bottom of the browser and the browser should not allow for it to be over-ridden. 15:39:42 Dan: The first time the software structure cam to his mind was with MP3. Real networks and Microsoft have a little battle over who's software gets to run. 15:39:59 Dan the two keep over-riding the registry as to who the top of the heap is. 15:40:26 TBL: Registry for MIME type 1 15:40:29 s/riding/writing/ 15:42:56 Ed has joined #tagmem 15:45:04 rrsagent, please make logs world-visible 15:46:01 TBL: Bug over riding DLLs use by other people. 15:47:54 discssion: Microsoft issues with DLL's 15:50:07 (does this meeting have time to explain to me how .Net purports to address "dll hell"? it has something to do with assemblies, but I don't grok as deeply as I'd like) 15:50:19 TBL: Auditing. Its both a symptem of auditing the problem as well as.. 15:52:15 TBL: We should put on our list, the xBrowser security note. 15:52:46 s/xBrowser/voice browser/ 15:54:59 TBL: have the javascript security policies been reviewed? eg "a script can only open a TCP connection to the site from whence it came" 15:55:55 HT: its difficult to apply style sheets to java script pages. 15:57:21 DC: I think browsers only run XSLT stylesheets from the same site that the document came from 15:57:32 TBL: so the community has bought into security-by-domain 15:58:58 (good question, HT, what about the grid?) 15:59:29 TBL: If your picking up a style sheet and it wasnt constraigned and then you referred back to a local copy but when you do an actual HHTP referance to that there is a forward. 15:59:36 (or an alias) 16:00:16 Regarding TBL's question as to whether JavaScript policies have been reviewed: I just checked with Sam Ruby, who was secretary for ECMAScript standardization effort. To has knowledge, that effort was scoped to the language only: no formal standardization of DOM, security models, etc. 16:03:19 Some plug-ins are trusted (like PDF) where others are less trusted because they are scripting languages which are executed locally (such as flash). 16:05:39 [NEWS] Macromedia Flash Plugin Can Read Local Files 16:05:47 http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-08/0030.html 16:08:31 HT: A point for discussion. The UK funding bodies are particularly concernced about the grid, the semantic web, and the web. Are there technical architectural issues around remote servies? 16:11:10 Vincent: We conclude our discussion on security. There is certainly interaction between the grid, ws and the web in general. 16:11:42 Vincent: We have addressed with some success authentication/passwords and principles of least power 16:12:25 rrsagent, please show actions 16:12:25 I see 4 open action items: 16:12:25 ACTION: Dan to get web applications charter and share it with the TAG for review. [1] 16:12:25 recorded in http://www.w3.org/2005/06/15-tagmem-irc#T13-49-40 16:12:25 ACTION: VQ to invite Dean to a TAG teleconference [2] 16:12:25 recorded in http://www.w3.org/2005/06/15-tagmem-irc#T14-16-06 16:12:25 ACTION: Roy and Norm to review http://www.w3.org/DesignIssues/Principles.html#PLP [3] 16:12:25 recorded in http://www.w3.org/2005/06/15-tagmem-irc#T15-29-10 16:12:25 ACTION: Dan to write a report on the state of the art authentication in the web. [4] 16:12:25 recorded in http://www.w3.org/2005/06/15-tagmem-irc#T15-30-40 16:12:52 A question arose before about Flash data access. 16:13:09 From the macromedia site: http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14213 16:13:19 ACTION: Dan to draft "Dont use passwords in the clear" 16:13:31 "For security reasons, a Macromedia Flash movie playing in a web browser is not allowed to access data that resides outside the exact web domain from which the SWF originated. 16:13:31 As an enhancement to Macromedia Flash Player 7, domains must be identical for data to be read. With this change a sub-domain can no longer read data from a parent domain and vice versa." 16:15:47 While this doesn't explicitly discuss access to local files, it leads me to believe that Flash does indeed do what one would expect: I.e. to run in a different mode when a .SWF file is launched through the web vs. when run locally. This all seems quite similar to Java. 16:17:22 We will save Semantic web for tomorrow 16:17:31 After lunch we'll address 49 16:17:41 break for lunch resume at 1:15 16:18:02 -DOrchard 16:35:27 BTW: Looking back at that "Flash can read local files" report, it was clearly listed as a bug. 16:35:33 timbl has joined #tagmem 16:41:28 rrsagent, draft minutes 16:41:28 I have made the request to generate http://www.w3.org/2005/06/15-tagmem-minutes.html Ed 17:20:34 Norm has joined #tagmem 17:26:28 timbl has joined #tagmem 17:27:20 +DOrchard 17:27:20 Scribe: Norm 17:27:41 Topic: schemeProtocols-49 17:28:07 Noah has produced a draft finding 17:28:08 http://lists.w3.org/Archives/Public/www-tag/2005Jun/0024.html 17:28:19 http://lists.w3.org/Archives/Public/www-tag/2005Jun/0025.html 17:28:47 Actual draft is at http://www.w3.org/2001/tag/doc/SchemeProtocols.html 17:29:22 Ed has joined #tagmem 17:29:22 timbl has joined #tagmem 17:29:48 Not polished even as a first draft, but useful for determining if it's going in the right direction 17:30:22 Motivated in part by P2P and streaming. Vague sense that the kind of content that flows over http isn't the only kind of content that might exist. 17:30:42 So what are the right ways to go beyond or leverage http? 17:31:42 Review can be divided into two aspects: first, is there anything that's factually wrong? 17:32:42 Second aspect: is it beginning to tell a story that the TAG wants to tell 17:40:50 q? 17:42:50 dorchard: wonders what the motivation/problem is that this finding addresses. 17:43:37 NM: Impression is that for example, some P2P protocols are integrating better into the web than others. 17:44:10 NM: For streaming, does it make sense to have lots of new protocols, or does it make sense to get a document with a particular media type 17:44:56 NM: We've never really clearly said, other than looking back, what are the guidelines for creating new protocols that you might need. And what are the other things that you might need to know that aren't in AWWW 17:45:03 DC: It would suit my taste better if you'd talked about P2P or streaming 17:45:15 ...right up front 17:45:23 NM: That's meant to be in 3rd para of the preface 17:46:22 ht: Section 4 maybe belongs in an appendix, but as far as the questions you are going to answer, I don't need to know this stuff about gateways 17:47:10 ht: How to get an FTP URI with the HTTP protocol isn't on the shortest path to the goal 17:47:23 VQ: The correspondence between the two protocols is valuable. 17:48:00 VQ: The gateway itself isn't very interesting, but the equivalence between the operations (or sequence of operations) may introduce the issue of inventing new protocols when others are already available 17:48:22 NM: One bit of advice: consider similarity to the operations avialable in other protocls 17:49:42 NM: Because http allows you to carry an HTTP URI, you can do this gateway without having to invent a new URI 17:49:54 q+ to ask about the reality of this ftp-over-http example 17:50:00 NM: Another bit of advice: ok, if you're going to build a p2p protocol, you might want to make it easy to carry other people's URIs around 17:50:20 ack DanC_lap 17:50:20 DanC_lap, you wanted to point out a few comments about misleading bits, and to express a lack of motivation. a story is traditional, by now. 17:50:21 DC: Do you have anything you feel is a short summary (one or two sentences) 17:50:51 NM: I think the one I just mentioned might be one 17:51:04 NM: last paragraph before ednote in Chapter 4 17:51:39 DC: "Protocols designed to be ... such URI names" 17:51:40 NM: And in section 3 17:51:59 NM: The second paragraph 17:52:54 NM/DC disagree about the practice of 404ing namespace URIs 17:53:09 NM: Creating a scope in a language should be a lightweight thing to do. 17:53:47 DC: This paragraph is terribly misleading. 17:54:28 NM: I'd be happy to say the "should provide servers" part a little more strongly 17:54:53 NM: What is there that keeps me Noah at IBM from naming my URIs with someone else's DNS? 17:54:55 NM: I'm writing it down here. 17:55:00 DC: I think that's already covered 17:55:31 NM: I was trying to say that you never want to preclude someone from doing the right thing which is to actually deploy 17:55:44 DC: It still feels like obscure cases 17:55:57 NM: To me it's important to say where the rules come from. 17:56:59 NM: It's a deep architectural question about what it means to mint URIs that don't have servers 17:57:12 timbl has joined #tagmem 17:58:01 DC: The part about not using someone else's DNS is in the URI Ownership section of AWWW 17:58:21 NM: The larger way to look at this is a way of building things from first principles 17:58:34 NM: Then you can look at the problems: how to get P2P on the web, what to do with streaming media 17:58:55 DC: Maybe it'll work better in later drafts 17:58:55 DC: I don't have an overall sense 17:59:04 RF: For me it's still backwards, you don't select URIs based on protocols or vice-versa 17:59:52 RF: There exist resources in the universe and there are methods of accessing them. To a certain extent, the methods cause them to be named. One way to achieve that is to map a URI scheme, simply an identifer, to the methods 18:03:11 Norm has joined #tagmem 18:03:27 RF: And then you look at the responsibilities of the handler at this point. What does it have to do 18:03:41 NM: Where is the nature of the default defined 18:04:29 q+ 18:05:43 Some discussion here about origin servers and authoritative requests 18:06:19 RF: It's what the server currently represents as the representation of that resource 18:06:45 NM: I thought the archicture said if you really got a 200 back from the origin server, you are authorized to say that that was a representation of that resource 18:06:52 NM: That it was in some sense what that URI was naming 18:07:27 q+ to suggest 2 or 3 things: (1) if (but *not* only if) you get a 200 on port 80, you have a representation of http://... (2) the Internet community has delegated to IANA a mapping from scheme names to protocols that are best current practice; today, it relates http: to the HTTP spec. (3) access to "the Web" may go thru client proxies, and local policy may be satisfied with very old representations, etc. 18:07:30 RF: No. If I give you an ID for a social security number and you use that to get RF's tax records, does that give you my tax records or a document with current information about my taxes, ... 18:07:48 ht: What it gives you is an authoritative representation of that resource at that time 18:08:05 NM: So there's no way that I could say that that's a representation of another resource (as opposed to the real one) 18:08:24 NM: Not all URI schemes work that way is my impression. The UUID scheme doens't say a lot about authoritative representations 18:08:42 RF: Not all schemes are grounded in representations (or protocols) 18:09:06 RF: When I say there's an http information space, it doesn't depend on the version of the http protocol 18:09:15 ack ht 18:09:15 ht, you wanted to ask about the reality of this ftp-over-http example 18:09:38 ht: Is this ftp-over-http example really important 18:09:48 ht: Stipulate that it's all true, does it have any interest in practice 18:09:59 ht: Are there any such gateways in the universe and are they actually used 18:10:05 RF/DC oh yeah 18:11:13 DC: The servers come out of the box configured to be origin servers 18:11:29 ht: Point me to a server that does work as a proxy server 18:11:43 RF: It's used in almost every large corporation as an interanet/extranet buffer 18:12:03 RF: The reason you can't see this from the outside world is that thye have been configured *not* to look like proxy servers 18:12:49 DC: Almost all the APIs have variables you can set to do this 18:14:52 NM: Part of the reason I brought this up was because the architecture allows it we ought to describe it 18:14:57 NM: But really the question is, should I give an http: scheme name to something that's actually in bittorrent 18:15:44 TBL: The rules are written through the evolution of the architecture 18:17:29 TBL: When you look at whether your going to make a bittorrent scheme or support bittorrent with http URIs, you're making some tradeoffs 18:17:47 NM: I didn't mean to set down rules, I meant to explore what the tradeoffs are 18:18:18 q? 18:18:38 DC: I wouldn't talk about one protocol fitting in another, I'd talk about accessing representations 18:19:45 DC: You have to motivate generality, and you've only done that about representatoins 18:19:49 ack dorchard 18:20:46 dorchard: I wanted to comment on defaulting. That's not written down but everyone uses it. The operation you use is also defaulted. Using http: doens't imply doing a get. 18:20:52 NM: I disagree with the second 18:21:10 ht: It's interesting to note that linkcheck does HEADS not GETs 18:21:37 NM: I agree with Henry. The reason GET is a default is because browsing is the most common thing we do. But for any of them, we could have an applicatoin with different defaults 18:22:31 NM: If I was handed a 'qrs:' scheme, where would I get started? The scheme should be registered at IANA. For some of those schemes, the scheme documents would be a lot like the document for http. 18:22:55 RF: Each specification defines what it knows about the univers, it doesn't define the whole universe and then itself 18:23:19 RF: Good practice moving forward is to separate the scheme specification and the protocols 18:24:21 RF: The scheme specification should point to a set of protocols (e.g., http and https). And should also describe the set of procedures that are used to map from identifiers in that scheme space to resources available via that protool or set of protocols 18:24:48 RF: The resources "just are". These are the associated set of access mechanisms. 18:25:07 DO, Ok 18:25:09 (not sure they "just are") 18:25:18 q+ 18:25:50 +1 tell us a story, uncle Noah 18:25:53 dorchard: The other thing that I was going to suggest was that in the Arch Document there have often been stories. It would be good to have a story here with P2P or streaming. 18:26:48 ack DanC_lap 18:26:49 DanC_lap, you wanted to suggest 2 or 3 things: (1) if (but *not* only if) you get a 200 on port 80, you have a representation of http://... (2) the Internet community has delegated 18:26:49 ack danc 18:26:52 ... to IANA a mapping from scheme names to protocols that are best current practice; today, it relates http: to the HTTP spec. (3) access to "the Web" may go thru client proxies, 18:26:57 ... and local policy may be satisfied with very old representations, etc. 18:27:05 q+ to parallel this with the streaming media/rtps story 18:27:21 Roy has joined #tagmem 18:27:54 Social relationships involved in the relatiion between a URI and a representation are of quite different for for diffrent protocols. Eg it takes technology AND scoial agreement to mak eHTTP 200 responses definitive, but the concepts of trust are very different. The protocols used to be the master thing, until the schem had been used for naming a lot of things -- now the prpotocl is secondary and can be upgraded, prseveing the scheme. 18:28:02 ack timbl 18:29:12 TBL: You can be held accountable for http: 200's because there are social relationships behind the servers and DNS, etc. 18:29:50 TBL: It's possible that within the life of the TAG, it'll be necessary to introduce a P2P version of http 18:30:02 TBL: But that may come with caveats 18:30:33 TBL: You may need a button on your browser that says you want the definitive version (for your home banking) 18:30:56 -> http://lists.w3.org/Archives/Public/www-tag/2005Jun/0032.html comments on SchemeProtocols.html , transcribed from my paper copy 18:31:03 TBL: The trust may be very different. We'll end up morphing the trust situation in a very positive way or a very negative way. 18:32:39 NM: The metapoint I'm trying to raise that just perhaps the story you just told is an important story that's not well articulated 18:32:45 NM: What I wanted to do in heading off into this space is to tell stories like this 18:33:56 Note to scribe: what RF said above about http: and https: may not have been what he meant to say 18:34:39 NM drifts towards httpRange-14 18:34:40 I missed it 18:36:21 ack ht 18:36:22 ht, you wanted to parallel this with the streaming media/rtps story 18:36:25 ack ht 18:38:32 ht: What Roy is calling the http: information space has the defining property that it has the DNS+hierarchy naming structure. The information space that define the http information space are about an organization of a relationship between identifiers and the resources they identify. This is completely independent of the protocol. 18:38:38 a suggestion: the http scheme is an agreement that there's a space of information resources, where one part of the name identifies a party, usually a domain owner, who gets to say the relationship between those names and representations that correspond to them 18:39:19 q? 18:39:32 q+ to ask whether operations are associated with URI scheme or protocol 18:40:00 ht: That's an interesting perspective. What I'm concerned about is the question, "if that's true, it's very strongly at odds with the naive users perspective which is that http is about what we call representations" 18:40:16 ht: retracts that statement for the moment :-) 18:40:23 (re noah's question, I care in the case of representation access, but the case of operations in general is too academic; please pay one story before we spend the time to answer. 1/2 ;-) 18:40:31 ack DanC_lap 18:40:31 DanC_lap, you wanted to ask that we go thru the bittorrent case 18:41:02 NM: Do people believe that the operations come with the scheme or the protoco. 18:41:10 s/protoco/protocol/ 18:41:26 DC: That's not a small question,that's an enormous protocol 18:41:29 s/protocol/question/ 18:42:04 Answer not obvious. 18:42:29 DC: Let's do daap: first (Digital Audio Access Protocol) 18:43:04 Apparently it is *exactly* the same as http 1.1. 18:43:23 "The Digital Audio Access Protocol, or DAAP, is used by Apple's iTunes 4.0 digital audio player to share music across a network or the Internet. It provides capability not only to stream audio from one computer to another, but also to list the host's playlists so that they can be accessed remotely." -- http://daap.sourceforge.net/ 18:43:58 DC: They came up with a different scheme so that they could get injected into the software deployment story 18:45:50 The Mac dispatches on scheme name 18:46:33 TBL: They forked http and added a few bits 18:47:49 http://daap.sourceforge.net/docs/index.html 18:47:55 (I was looking at http://them.ws/post/775/what_is_daap__ ) 18:48:51 VQ: Maybe bittorrent is a better example 18:49:01 DC: Anyway, daap seems like a way not to do it 18:49:33 DC: Nice story: My kid wrote a nice story, it gets insanely popular and automatically switches to bittorent so the load on my server only goes up a little bit 18:50:27 ht: I find a URI for your kids story, I click on it, the browser waits a few seconds and says, gee this sucks, aborts that, and initiates a bittorrent request 18:50:28 DC: bittorrent isn't the same as gnuntella, it isn't entirely peer-to-peer 18:50:40 dorchard: There's one tracker per-distributed resource 18:51:06 DC: I'm the guy who has to publish the seed 18:51:33 ht: You may have to do something and then my client has to automatically try to use bittorrent 18:51:45 q? 18:52:26 Scribe may have missed a bit 18:53:20 TBL: Speculative design of a fallback system: Dan's server when it hits a certain load it automatically sends back a response that tells the client to switch to bittorrent 18:54:47 DC: I think Henry's design is fundamentally better because the other way I have to satisfy a TCP request from my server 18:55:42 DC: I'd put a .torrent file on my server that would have the address of the tracker and some starting servers. 18:55:56 DC: The bittorrent protocol has been upgrade to be trackerless 18:56:09 ht: My question is what *I* do. 18:56:38 http://www.bittorrent.com/protocol.html 18:57:05 News article on trackerless BitTorrent: http://www.betanews.com/article/BitTorrent_Creator_Opens_Online_Search/1117065427 18:57:35 more general... http://www.bittorrent.com/introduction.html 18:57:41 DC: In http, the *publisher* gets to say what the right answer is. In this other world, the social conventions are totally different. It becomes the world that gets to say what the representation is 18:58:00 http://joi.ito.com/archives/2005/05/20/bittorrent_goes_trackerless.html 19:00:30 dorchard: A lot of people don't use google, they use bittorrent sites that do a better job of searching bittorrent files. 19:00:42 q? 19:00:55 dorchard: And they provide comments 19:00:55 "While it is called trackerless, in practice it makes every client a lightweight tracker. A clever protocol, based on a Kademlia distributed hash table or "DHT", allows clients to efficiently store and retrieve contact information for peers in a torrent." 19:00:58 q- 19:01:07 Quote was from http://www.bittorrent.com/trackerless.html 19:01:32 q? 19:01:57 ht: We're morphing this question into a P2P version of access to the HTTP information space 19:02:08 ER: It does, it's just a really bad idea 19:02:36 Some discussion of IPR, aborted 19:02:55 TBL: trackerless bittorrent has a distributed hash table in it 19:03:39 TBL: If we replace http with a not-DNS hierarchy system then we'll end up with a differnt social system. 19:04:00 TBL: When you use http, you trust the publisher, when you use bittorrent, you trust the other users running bittorrent 19:04:39 But you can do a checksum or sig check on the downloeded result, and use trusted parties or trusteed links (links with keys or hashes inthem) 19:05:07 (in the case of "file on an http server gets really popular; let's switch to bittorrent" all the clients are going to have to do a round-trip to the origin server to get the md5 and some bittorrent coordinates, unless we mix in quite a bit more stuff) 19:05:21 NM: One question is how do you get new modes of delivery (such as P2P) for things named with http: URIs 19:05:35 HST is/was trying to push on the question of the possibility of giving access to the http information space using a (collection of) transport protocols which are not HTTP or anything close to it 19:06:20 q+ to point out that the reason for continuing to use http: names is not just that timbl wants to Rule The World, but that preserving links is valuable to society as a whole 19:06:20 NM: One of the things that's likely to result from that has to do with DNS names. The social understanding of what your likely to get changes in interesting ways. 19:06:52 DanC+HST combine to ask: can we provide the "quite a bit more stuff" in a way which preserves the social properties of the information space 19:07:32 q? 19:07:39 ack DanC_lap 19:07:39 DanC_lap, you wanted to point out that the reason for continuing to use http: names is not just that timbl wants to Rule The World, but that preserving links is valuable to society 19:07:43 ... as a whole 19:08:39 DC: The value of the network is the web of names. Keeping the same names preserves the value of the web. 19:11:21 NM: I think the reasons why we wnat to use http names is worth writing down 19:11:33 "BitTorrent is a protocol for distributing files. It identifies content by URL and is designed to integrate seamlessly with the web. Its advantage over plain HTTP is that when multiple downloads of the same file happen concurrently, the downloaders upload to each other, making it possible for the file source to support very large numbers of downloaders with only a modest increase in its load." -- http://www.bittorrent.com/protocol.html 19:11:43 s/wnat/want/ 19:12:54 VQ: Noah will incorporate comments into the draft. 19:13:01 VQ: Should we link it as a finding in progress 19:13:50 General agreement 19:13:51 ACTION: VQ to make a link from the findings-in-progress page 19:15:10 ACTION: NM to produce a new draft 19:16:29 -DOrchard 19:16:34 zakim, bye 19:16:34 leaving. As of this point the attendees were DOrchard, MIT601 19:16:34 Zakim has left #tagmem 19:38:04 Topic: httpRange-14 19:56:49 lots of discussion... HT put a picture up (pointer, ht?) with a couple URIs 20:00:45 Representations vary over time; people can make different assertions about what a representation means 20:02:50 With the '#', there's a whole different architecture (involving mime types) 20:03:08 http://www.ltg.ed.ac.uk/~ht/webpropernames/img2.png 20:06:11 RF: When people use URIs, they aren't necessarily using it in an identification relationship 20:06:27 RF: They are using it in a "more information" relationship 20:07:04 RF: In Eiffel Towe, the URI is not for identification, it's a pointer to something that gives more information about the tower. 20:07:44 RF: Indirectly, it identifies the tower 20:08:15 If I replaced that with an SVG image source, a human being reading the page will reach the same conclusion (that it's the depicted real tower) 20:14:24 the "nobody uses http uris for anything but documents" is an "at your own risk" sort of conclusion, not one that you can turn around ala "if it's not a web page, it can't have a hashless http URI" 20:14:36 q+ to respond to timbl ala the "nobody uses http uris for anything but documents" is an "at your own risk" sort of conclusion, not one that you can turn around ala "if it's not a web page, it can't have a hashless http URI" 20:14:46 where did zakim go? 20:14:48 Zakim has joined #tagmem 20:14:51 q+ to respond to timbl ala the "nobody uses http uris for anything but documents" is an "at your own risk" sort of conclusion, not one that you can turn around ala "if it's not a web page, it can't have a hashless http URI" 20:15:13 http://www.httpsniffer.com/http/100304.htm 20:18:06 q? 20:19:25 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 20:19:39 303 See Other: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 20:20:06 (in preparation for straw poll, I'm swapping in SWBPDWG's request http://lists.w3.org/Archives/Public/www-tag/2005Mar/0101.html ) 20:21:27 Induction: the world is used to thinking http: URIs are documents, so they must be 20:21:50 Induction: the world is used to thinking that '#' in an http: URI is a pointer into the document, so they must be 20:24:52 my head hurts.. but I think I'm taking Tim's side on this. We need to make a clear distiction. 20:26:22 . http://web.resource.org/cc/Reproduction 20:31:21 In the picture yesterday we had two levels distinguishing "identifies" and "points to" where RDF defines "identifies" but doesn't define "points to" very well and HTTP defines "points to" but doesn't define "identifies" very well 20:31:50 In semantic web its important to know if your referancing a document vs an object. 20:35:48 http://www.httpsniffer.com/http/100303.htm 20:35:53 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 20:38:27 infoRes axiom, the lesser: { ?R a http:OK200; http:about ?X } => { ?X a webarch:InformationResource }. 20:39:49 where an HTTP GET /path to host.example is http:about 20:39:52 RF: Proposal: If an http resource responds to GET (a) with a 200 OK, then it is an information resource, (b) with 303 See Other, then it could be *any* resource, and (c) with any 4xx error, then ... ? 20:40:03 Seems to garner a modicum of support 20:40:10 NDW: I could sign off on that compromise 20:42:26 what 2xx or 3xx response codes identify non-information resources? 20:43:12 the common architecture position: "points to" and "denotes" agree on URIs without hashes. 20:43:30 http://www.w3.org/2005/06/13-tag123.html 20:43:42 The proposal is that 2xx identify information resources; 3xx say "see other" so they could be anything 20:44:02 dorchard, a 303 response doesn't give any constraints about whether the resource is an information resource or not 20:44:23 ... per the RF proposal 20:46:01 My proposal is that we provide advice to the community that they may mint "http" URIs for any resource provided that they follow this simple rule for the sake of removing ambiguity: 20:48:11 a) If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource; 20:49:18 b) If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource; 20:49:55 c) If an "http" resource responds to a GET request with a 4xx (error) response, then ... ? 20:52:09 This proposal enables people to name arbitrary resources using the "http" namespace without any dependence on fragment vs non-fragment URIs 20:54:30 (Henry, I wonder what impact this should have, if any, on the XPointer registry) 20:54:30 ... and reducing ambiguity appearing on the Semantic Web by folks misusing the non-information resource's URI to identify the information content returned by redirected request 20:56:08 (I'd prefer myTripLog#tower , rather than myTrip#tower , to be clear that the stuff before the # is a document) 21:02:19 (what if its a portal and myTripLog# is a program which generates the result you get at myTripLog#tower) 21:09:35 (myTripLog might be supported by a program, but it's not a program. it's a document) 21:09:52 Httprange-14: the issue is "TBL's argument the HTTP URIs (without "#") should be understood as referring to documents, not cars." 21:11:31 so RESOLVED. 21:11:57 Unanimity 21:12:33 ACTION: RF to declare victory and move on 21:16:09 RRSAgent, make logs world-access 21:16:20 RRSAgent, please draft minutes 21:16:20 I have made the request to generate http://www.w3.org/2005/06/15-tagmem-minutes.html DanC_lap 21:16:32 RRSAgent, pointer? 21:16:32 See http://www.w3.org/2005/06/15-tagmem-irc#T21-16-32 22:21:19 timbl has joined #tagmem 22:54:39 timbl has joined #tagmem 23:42:45 timbl has joined #tagmem