20:32:32 RRSAgent has joined #tagmem 20:32:32 logging to http://www.w3.org/2011/10/31-tagmem-irc 20:32:37 anybody home? 20:33:26 plinss has joined #tagmem 20:33:29 We don't have a quorum right now, but are starting to chat informally about client-side state. 20:33:47 I'll take some notes. I don't >think< it's worth doing Skype, but I can try if you like. 20:34:42 I'll just hang out for a while… will be here intermittently 20:34:48 We're discussing comments on http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110930.html 20:34:57 Email from Ashok: http://lists.w3.org/Archives/Public/www-tag/2011Oct/0105.html 20:35:14 First comment email: http://lists.w3.org/Archives/Public/www-tag/2011Sep/0076.html 20:35:33 Björn Höhrmann writes in the email: 20:35:40 "I saw "All media type specifications and registrations, especially for 20:35:41 new types, must specify fragment identifier semantics" while scrolling 20:35:41 through it. This kind of wording is misleading considering that the TAG 20:35:41 has no authority over the requirements for media type registrations." 20:35:52 +1 20:39:32 Ashok has joined #tagmem 20:41:46 We're working on a rewording... 20:42:10 How about if we add the words "This document recommends ..." at the start of the sentence? 20:42:19 hmmm.... 20:42:37 ht has joined #tagmem 20:44:50 Suggest a new section 6.0. Something like: 20:45:28 Larry has joined #tagmem 20:45:37 rrsagent, pointer 20:45:37 See http://www.w3.org/2011/10/31-tagmem-irc#T20-45-37 20:45:52 "In order to ground the semantics of fragment identifiers in applicable specifications, it is recommended that IETF media-type registration procedures be updated as suggested below. 20:59:13 Going on to next comment...from Jonathan... 20:59:30 http://lists.w3.org/Archives/Public/www-tag/2011Sep/0089.html 21:00:44 IRI could reference both 3987 and 3987bis 21:00:53 Ashok: Agree on documenting abbreviations 21:01:18 Ashok: Agree that it's the HTML media type registration, not the HTML Recommendation 21:01:55 NM: Right, but the media type registration may delegate to the spec (channeling Tim, I think) 21:02:01 the problem with delegating # semantics to a format spec is that it doesn't have jurisdiction 21:02:08 the HTML media type registration is in the HTML spec, as per W3C policy 21:02:13 NM: I assume the "editorial nit" is an editorial nit? 21:02:23 it has juris. if it says it does. 21:02:35 DKA has joined #tagmem 21:02:42 problem only comes if it defines fragid semantics but does not call itself the media type reg 21:03:02 Right. 21:03:49 ht has joined #tagmem 21:03:50 i.e. the part of the format spec that says "a conforming document is …" says nothing about conformance of documents of other media types that have fragids pointing in 21:04:12 pedantry. 21:04:24 NM: So, Ashok has gotten some informal advice (no quorum here). We'll expect a new draft, and will go for formal approval after nov. 15 (per Edinburgh resolution) unless we get more comments at TPAC 21:04:29 moving on to next topic. 21:04:57 jar has left #tagmem 21:05:36 jar has joined #tagmem 21:10:23 fragids and polyglot, and compound document formats 21:14:00 betehess has joined #tagmem 21:25:26 timbl has joined #tagmem 21:26:47 DKA has joined #tagmem 21:26:59 ScribeNick: DKA 21:27:01 Scribe: Dan 21:27:21 trackbot, start meeting 21:27:24 RRSAgent, make logs public 21:27:24 Zakim has joined #tagmem 21:27:26 Zakim, this will be TAG 21:27:26 I do not see a conference matching that name scheduled within the next hour, trackbot 21:27:27 Meeting: Technical Architecture Group Teleconference 21:27:27 Date: 31 October 2011 21:27:33 ScribeNick: DKA 21:27:36 Scribe: Dan 21:27:56 present+ Henry 21:28:02 present+ Tim 21:28:05 present+ Noah 21:28:07 Present+ Dan 21:28:10 present+ Ashok 21:28:14 present+ Larry 21:28:28 present+ Peter 21:28:50 present+ Qiuling_Pan 21:29:46 Note: Qiuling is observer from Huawei. 21:29:59 logger, pointer? 21:30:08 RRSAgent, pointer? 21:30:08 See http://www.w3.org/2011/10/31-tagmem-irc#T21-30-08 21:30:15 Topic: Discussion on AppCache... 21:30:42 RRSAgent, when you are logging, please feel addreed by the vocative "logger". 21:30:42 I'm logging. I don't understand 'when you are logging, please feel addreed by the vocative "logger".', timbl. Try /msg RRSAgent help 21:30:52 [discussion on whether or not app cache manifest is actually comprised of URIs (it is)] 21:31:13 Topic: URIs 21:31:28 present+ Alexandre 21:32:48 Zakim, list 21:32:48 I see SEC_WASWG(TPAC)11:00AM, XML_QueryWG(LCF2F)11:00AM, UW_(WebRTC)12:00PM, SW_e-Gov(eGovIG)11:00AM, Team_(dnt)16:00Z, WAI_AUWG(TPAC)11:30AM, RWC_WAPI(WebAppsWG)12:00PM, 21:32:51 ... Team_(geolocation)20:08Z active 21:32:52 also scheduled at this time are WAI_PFWG(PFWGTPAC)11:00AM, RWC_WebEven(WebEvents)12:00PM 21:33:08 Topic: Links refer, URIs don't 21:33:40 Henry: My argument is that part of the problem we are struggling with is: we believe that if something is a URI then we know everything we need to know about what it means. I think that's wrong. 21:33:57 present+ Jeff 21:36:40 jar_ has joined #tagmem 21:36:59 q? 21:37:54 Henry: the ideology of early web specs came from e.g. roy fielding treating time-varried resources as first-class citizens. Resources vary over time. [NYTimes homepage changes all the time but is still the NYTimes homepage.] 21:38:37 … if I put up 5 pages of the form weather/city then it's reasonable to try weather/some-other-city and expect to get the weather for that city. 21:39:13 … under web architecture you have no grounds for complaint, but web site maintainer has violated a social contract. 21:40:02 … "indexical" is a word like "you" or "now" that can have multiple interpretations (but one meaning). 21:42:31 quote from post: Look, this is not a scientific process of discovery -- "what is the meaning of a URI? Let's look at some use cases and discover..". This is a process of design; we're designing the protocol element URI (and IRI) and designing representation systems that carry meaning by using URIs. I'm saying that designing a system where meaning depends on external events is bad design. At best, Frege and Joyce might provide some 21:42:31 additional frameworks for discussing the design choices, but I don't think they contribute even that 21:43:01 Henry: [presenting slides - which will be made available] 21:45:33 … [discussion on how use of names or identifiers depends on context] 21:46:06 … difference between referential and actionable context. 21:46:13 "what this name refers to" => "what the utterers of the name intend for interpreters of the name to understand" 21:48:12 … one reason to try to do this: there is a generalisation that covers a lot of use. By looking at it this way it becomes consistent. For example, contrast two local contexts, one using URI in an HREF (actionable), one using a URI in a RDF statement (referential)… 21:49:00 … for referential use, the fact that I could retrieve the document at the end of the URI is incidental to its use. For actionable, it's central to its use. 21:49:44 Hence, the 200 OK [response] should be more flexible. 21:49:44 q+ to agree with analysis but not the direction going 21:50:42 Henry: So - 200 OK would no longer mean "here is a representation" - it would mean "here is a representation for the context" 21:50:49 in particular, i want to argue against doing what Henry is proposing but to focus on design of RDF and related followon semantic web language contexts 21:51:22 … What a URI in the first instance tells you is not what its referent is but how to get to its referent. What you get back may vary according the context in which you found the URI. 21:51:30 Tim: That would require magic. 21:52:14 Henry: One way to instantiate this would be to use mget (get metadata). [does not exist] 21:52:27 Larry: I don't like the direction you're going on how to fix this. 21:53:10 q+ to say I don't like where this is headed for other reasons than Larry's 21:53:11 … we're engaged in design, not in discovery. 21:53:14 q+ 21:53:15 ack Larry 21:53:15 Larry, you wanted to agree with analysis but not the direction going 21:53:26 q? 21:55:18 Henry: The way I would hope this to be taken: leading towards a question: suppose we want to use the web as it stands. I want to give advice that will work [within the constraints of current web technology]. We need a meta accept header. Accept-reflect, or accept-see-other... 21:55:28 Larry: I don't think that's the right advice. 21:55:43 Henry: I'm trying to explore a class of solutions like that… 21:56:20 i'd rather see advice to create a new version of RDF which resolves the use/mention ambiguity explicitly 21:58:50 Henry: I don't think RDF is compositional. 22:01:28 DKA has joined #tagmem 22:02:34 ack next 22:02:35 noah, you wanted to say I don't like where this is headed for other reasons than Larry's 22:02:37 Noah: I expect that get representation of is different then getting metadata about... 22:02:52 RDF is compositional and referentially transparent 22:02:52 ack next 22:02:54 Henry: Every URI has one meaning, but that doesn't tell you what a get should do. 22:03:05 RDF takes URI meaning as an input 22:03:07 Tim: The architecture does tell you what a get should do. 22:03:19 it's linked data practice that has to determine the interpretation 22:03:32 and the problem is only that linked data practice is inconsistent 22:03:38 i don't think the meaning of an assertion in RDF should depend on what HTTP servers return, I think that would be bad design of RDF 22:03:41 and that's because there is no validation 22:03:58 RDF does not work that way. 22:04:27 RDF meaning depends on how its users decide to interpret URIs referentially 22:04:28 Henry: the problem is: 200 OK means "your requested use can be satisfied." It doesn't mean "your URI means something different than it did yesterday." 22:05:35 Tim: I feel a tremendous weight of previous discussions [on this topic] … I've also got alarm bells ringing about a two-level solution. 22:06:21 … [parallel to DTD language to specify SGML doctypes 22:06:27 …] 22:06:53 … Always prefer a 1-level design. Clean, consistent and complete. 22:08:26 Tim: [speaking against using arguments from natural language] 22:09:09 q+ to talk about HTTP 22:09:38 nope, will try 22:10:10 Tim: [saying that objectors seem to be against use of # because it is 'messy'] 22:11:34 Henry: The time-varying resource thing : believing that we know what we mean when we say http://guardian.co.uk - we are just fooling ourselves. You can't tell me anything at all about what that referent has to be for that to be true. We don't have any real understanding of what coherence condition there has to be on those conditions... 22:11:44 … we haven't drilled on that. 22:11:57 q+ to assert that the time-invarying meaning of http://guardian.co.uk is "attempt to use HTTP protocol to talk to host guardian.co.uk with path "" 22:12:53 I think there are two distinct attacks on RDF going on here. One based on actionability (HT), and one based on time (Larry) 22:13:09 … I feel it is not unreasonable to say "I have these URIs, I want to issue gets, I know you are going to issue a 303 and I'm going to have to issue another GET. Can't we get that out of the way?" One approach might be to use accept-see-other: in your gets. Then from the server you can serve something different rather than a 303. 22:13:21 … what it means is: short-circuit the 303 referesh. 22:13:25 or should I say the use of http: URIs in RDF 22:13:36 Tim: Yes. That's a piece of engineering we ought to do before the end of the afternoon. 22:13:50 i would rather see use/mention/time disambiguation (like tdb) added to RDF 22:14:05 Henry: doing it with an accept header [is my proposal] 22:14:33 i would not recommend people deploy difference in the deployed HTTP infrastructure; in particular, I dislike tying fixing this protocol to HTTP and its error codes 22:14:36 q? 22:14:46 did anyone read my web metadata memo? it was required reading for two f2fs. it addresses this in part 22:14:48 Tim: If you send the accept header then the server can say 200 but send back something else... 22:15:10 ack next 22:15:12 noah, you wanted to talk about HTTP 22:15:13 read != absorb 22:15:17 betehess has joined #tagmem 22:15:20 [agreement to cut the chat] 22:15:56 [the cat, not the discussion] 22:16:31 i am opposed to tying semantic web meaning to the HTTP protocol at all 22:16:41 timbl: 22:16:51 ht, let's talk 3 relationships. 1. is representation of (what you GET), 2. is version of ( an info resource), 3. describes 22:16:59 Noah: the first thing is - can we agree that this not about what URIs identify or what their "definition" is… that can save us thrashing. The discussion is about http and how you can use it. 22:17:28 … you are connegging between 2 and 3 22:18:15 yes, "identify" needs to be banned 22:18:38 ack next 22:18:40 Larry, you wanted to assert that the time-invarying meaning of http://guardian.co.uk is "attempt to use HTTP protocol to talk to host guardian.co.uk with path "" 22:19:01 Larry: I am strongly opposed to tying the semantics of RDF to http. 22:19:07 (to whomever might be reading the irc log, I am not in the room, and nobody seems to be reading my IRC entries. they are for your amusement) 22:19:31 q? 22:21:18 q+ jar 22:22:06 [discussion on the use-mention problem - and the fact that this discussion is not about it] 22:24:13 JAR: The key is figuring out how to state the problem. What's worked best for me is to avoid the loaded words. E.g. identify, resource, representation. 22:26:18 … I've been doing work about how the linked data community might use http URIs. This reorients the whole discussion. 22:27:25 ht: not possible to dispense with URI identifying just one thing. Tim and Noah want to be able to say that 22:27:25 Tim: I am happy to switch to "referent" or any other word [if it helps]. 22:27:39 Noah: Some of these words are used in the normative specifications. 22:28:29 I have 3 docs in draft (in esw wiki) 22:28:49 Tim: There is an antipattern in design of making a 1-level consistent system which almost works, and then to fix a remaining issue, adding a second level, a meta level of some sort. Problems this can get into trouble, sometimes by making, in the end meta-meta levels etc with no final solution, sometimes because there is actually no oil and water boundary between the two levels, sometimes because the second level just has its noew problems. the good pattern is: 22:28:50 level, consistent and complete. 22:29:39 1. Requirements for change proposals. and a call 22:31:49 HT: Tm and I asgree that we need to find a way to fix the 303 problem 22:32:01 Henry: We discussed: Exploring something like shortcut-303 as an accept header is worth doing… 22:32:09 http://www.w3.org/wiki/HttpRange14Options 22:32:23 http://lists.w3.org/Archives/Public/www-archive/2011Oct/0034.html 22:32:45 JAR: I've tried to lay out what a change proposal could look like... 22:33:00 … in the document linked above. 22:33:18 … next steps are documented there. 22:34:22 ACTION: Noah to schedule followup discussion of http://www.w3.org/wiki/HttpRange14Options (per agreement in Santa Clara) 22:34:22 Created ACTION-625 - Schedule followup discussion of http://www.w3.org/wiki/HttpRange14Options (per agreement in Santa Clara) [on Noah Mendelsohn - due 2011-11-07]. 22:34:40 HT: We've been talking about section 5.3? 22:35:20 JAR: What you should look at is the wiki page. 5.3. 22:35:29 [break] 22:35:47 http://www.ltg.ed.ac.uk/~ht/wantOther.html 22:37:08 larry, note that I put tdb: in the mix. attempting to keep all views represented - useful point of comparison 23:00:42 plinss has joined #tagmem 23:02:02 Lar4ry has joined #tagmem 23:02:08 Lar4ry has left #tagmem 23:03:00 Larry has joined #tagmem 23:03:02 I'd like some time to discuss the current state of work in IETF to get TAG input, participation, as it relates to TAG topics: 23:03:02 23:03:05 - W3C and Registries (Happiana) 23:03:08 - MIME and Web (Happiana, mime-sniff in websec) 23:03:12 - Extensibility (IAB document) 23:03:15 - IRI everywhere (IRI working group specs) 23:03:18 23:03:21 (IETF groups are happiana, appsarea, websec, iri). 23:03:21 23:03:25 Getting W3C/IETF liaison(s) to join us for some part of these would be great, as well as W3C staff involved in MIME registrations. 23:03:29 23:04:09 DKA has joined #tagmem 23:08:30 present+ stpeter 23:10:02 Topic: IETF cross-topics 23:10:34 Larry: I made a list of things going on in IEFT relevant to things TAG was talking about. 23:10:36 Larry's list is in this e-mail: http://lists.w3.org/Archives/Public/www-tag/2011Oct/0104.html 23:11:13 … there are probably more… Partly this was to talk about how the TAG could be effective in influencing IETF documents... 23:12:18 … we've had a lot of discussion about registries and their use. There was an ad-hoc task force working on making people happier with using IANA as a registry. Some of the proposals have to do with more transparency. It has been observed that there has been lots of misunderstandng of how the process works. 23:12:34 Ashok has joined #tagmem 23:12:46 … in the TAG I was working on and this group has reviewed a draft on MIME and the Web. I got feedback from IETF participants that it wasn't helpful. 23:13:37 … some of the comments in that document were about MIME "sniffing" - so I've been working in that [ietf] group on the mime sniffing document. 23:14:15 … we've talked a lot about languages and versioning in the past. This has been a topic that has absorbed the tag. I see there is an IAB document about extensibility. Can you talk about that? 23:15:06 stpeter has joined #tagmem 23:15:48 Larry: and then - the TAG has had an issue open for a long time about IRIs - IRI everywhere. Making sure that W3C documents reference IRIs, etc... 23:16:22 … I would also add the URN topic because. There is a URN working group [in ietf]. 23:17:12 [discussion on use of URNs] 23:19:58 plh has joined #tagmem 23:21:03 Noah: We are having some activity on persistent URIs. This could be related to the same space as URNs. 23:22:09 Larry: We are going ahead work a workshop on the 8th of December in Bristol on persistent domain names - exploring the space of possible solutions … addressing the issues entities such as national libraries have brought up about using URIs as references. 23:22:18 s/Larry/Henry/ 23:23:00 happiana 23:23:01 happiana 23:23:48 a) Reviewing and updating in general the processes around getting items into IANA registries, including media types and URI schemes. This work is ongoing https://www.ietf.org/mailman/listinfo/happiana; See http://www.w3.org/wiki/FriendlyRegistryProcess for one summary of issues, status, and possible resolutions. 23:23:49 23:24:42 stpeter: There's a bad UI to IANA… People outside the IEFT community don't know how they register things with IANA, etc… lots of things people have found confusing. Lots of people have said : let's just use a wiki. As a result, we've had discussions with IANA about how to improve the interface - e.g. better tracking tools [transparency of process]. 23:25:12 … up to and including more polciy-related issues : what does registration mean? how much approval is there necessary? 23:25:33 … I tend towards the first-come-first-served side of things. 23:25:57 … I've been working on working on a ID encouraging people to not use X- things. 23:26:23 … working on this with Mark Nottingham and Dave Crocker. 23:26:46 Tim: I supper this. 23:26:52 s/supper/support/ 23:27:31 Noah: I like distributed extensibility - use namespaces - but some of that feels like X-. 23:28:01 … I'm not sure there are easy answers of how to get lots of people innovating. 23:28:39 Tim: in CSS, you've got -opera-roundedcorners-… -ie-roundedcornders-… 23:29:28 Larry: there is an activity in the IETF around improving accessibility and use of IANA as a registrar. 23:29:51 … we have a w3c process around using IANA as a registry... 23:30:05 present+ tlr 23:30:21 present+ plh 23:30:41 plh: we do have a process for this… 23:31:13 Larry: I attempted on the happiana mailing list to raise a concern that it not sufficient to make registration easier. but that it is important to get the community to register things. 23:31:22 stpeter: Those two are probably connected. 23:31:39 Larry: We need to bring additional resources to get more things to be registered. 23:32:04 stpeter: I think there are 2 things - how can w3c work with iana, and also how does joe developer interact with iana? 23:32:19 … joe developer doesn't know how to get his URI scheme register somewhere... 23:32:39 … the guys who made up Skype: are doing it on the fly. 23:32:58 tim: Apple are doing this. 23:33:33 stpeter: it should not be so difficult to get this done (from a w3c-iana liaison perspective). How we reach the people out on the margin I'm not so sure. 23:34:01 Larry: there is a suggestion that the process for 3rd party registrations (so people could register things that they see). 23:34:40 stpeter: we could have crack team 23:34:49 s/crack/a crack/ 23:35:15 stpeter: We've been talking to IANA about making it easier... 23:35:23 http://www.w3.org/wiki/FriendlyRegistryProcess 23:35:23 Tim: When it comes to mime types, is there a ticketing system? 23:35:36 stpeter: There is a ticketing system, it's just not visible (exposed). 23:35:42 … that's what we're talking about. 23:36:18 stpeter: IANA keeps track of things but no external visibility. 23:36:24 http://www.w3.org/wiki/FriendlyRegistries 23:36:39 Larry: Mark Nottingham put together a page about friendly registration process. 23:37:52 Larry: what could to the TAG do that could help? 23:38:38 stpeter: Off the top of my head, I think it would be good to have a longer-term discussion. There are more policy issues here that it would be useful to chat through. The IESG members are sort of "in the way" here. 23:38:45 … it's slower than it has to be. 23:39:14 plh: sometimes I have groups who invent a new format and do not register the media type for the new format... 23:39:35 Tim: A rule in w3c is that all the info for the media type registration should be in the spec itself. 23:41:01 http://tools.ietf.org/html/draft-freed-media-type-regs 23:42:16 stpeter: we need to deliver something that is more useful. Opening up the tracking system is the best first thing we can do . What happens after that, we can continue to explore. 23:42:28 Larry: the next topic which is related is mime sniffing. 23:43:25 stpeter: Mime sniffing has a long history. The widget spec references it. There has been some push back from IETFers. 23:43:31 http://tools.ietf.org/html/draft-ietf-websec-mime-sniff 23:43:36 … it's more of an informational specification... 23:44:03 … should it just be limited to http? Should we talk more generally about mime sniffing in http and file: ? … 23:44:37 Larry: a thumb-drive of files should be the Web as well… 23:46:05 Noah: When I deliver something through http - something served as text/plain and looks like xml with angle brackets but is not well formed. user agents that are correct display it as text. User agents that try to interpret it as xml will not work... 23:46:32 thumb drive using file extensions? file: ? packaging? manifest? auxiliary content-type annotations? 23:48:06 Larry: another topic - google seems to be deploying an update to http - spdy. Is there an internet draft? 23:48:22 stpeter: no. 23:48:27 [some discussion on spdy] 23:48:57 W3C had HTTP-NG work 23:50:02 [discussion on how much spdy is being used...] 23:50:29 Noah: it's all over SSL so that raises caching issues... 23:56:36 [discussion on IRIs] 23:57:04 Tim: should the TAG tell everyone writing a spec to use IRIs instead of URIs? 23:57:14 Larry: Maybe we should close this issue? 23:57:30 stpeter: we have the same thing in ietf with ipv6. It forces people to think about it. 23:58:56 DKA has left #tagmem 23:59:15 DKA has joined #tagmem