07:44:55 RRSAgent has joined #tagmem 07:44:55 logging to http://www.w3.org/2012/10/07-tagmem-irc 07:44:57 RRSAgent, make logs public 07:44:57 Zakim has joined #tagmem 07:44:59 Zakim, this will be TAG 07:44:59 ok, trackbot; I see TAG_f2f()3:00AM scheduled to start 45 minutes ago 07:45:00 Meeting: Technical Architecture Group Teleconference 07:45:00 Date: 07 October 2012 07:45:56 ScribeNick: JeniT 07:46:03 Scribe: Jeni Tennison 07:52:39 Agenda: http://www.w3.org/2001/tag/2012/10/07-agenda 08:03:30 masinter has joined #tagmem 08:03:51 Chair: Noah Mendelsohn 08:04:06 Present: Noah, Peter, Ashok, TimBL, Jeni, Larry 08:04:30 Topic: Convene 08:05:27 noah has joined #tagmem 08:05:56 http://www.w3.org/2001/tag/2012/10/07-agenda#Convene 08:06:08 noah: main goals: 08:06:13 noah: last call on fragid draft 08:06:32 ... review comments on FPWD 08:06:38 ashok: there aren't many comments 08:06:44 noah: ... ok, to move that forward 08:07:04 ... ht, jar & JeniT have asked for time on httpRange-14 08:07:23 ... I haven't put as much time on the agenda as they say they need, so we might have to juggle 08:07:43 ... with mnot, we have HTTP 2.0 and URI schema proliferation 08:08:13 ... and finally, I don't think we're doing enough, and some of what we're doing is near the end game 08:08:23 ... so we need to find new things to do 08:08:43 ... which is complicated a little by the fact we have a lot of seats up for new members this February 08:09:13 larry: we should discuss who's going to TPAC, and what to say there 08:09:28 Present: +Henry 08:10:09 noah: yes, we should talk about that under administration 08:10:16 larry: we might want more time than that 08:10:20 noah: ok 08:10:42 larry: I did send some other topics; I think most of them are covered 08:11:01 ... maybe informally we can talk about precision vs flexibility of specifications & error handling 08:11:11 ... which came up again recently 08:11:57 noah: we do have several TBD sessions, so we can see how we want to use that time 08:12:28 ht: we need 10 minutes for TAG election procedures & 10 for administration 08:12:37 ... we should concentrate on what we can't do on the phone 08:12:53 noah: let's get to 3:30 and see 08:13:03 ht: is jar calling at 3pm? 08:13:06 noah: I think so 08:13:21 larry: let's push election procedure & TPAC on Tuesday 08:13:29 ... and cover topics of interest to jar this afternoon 08:13:54 noah: ok 08:16:14 timbl: tomorrow evening we'll head over to ODI to see the building & have dinner 08:17:28 noah: we have Stuart joining us tomorrow afternoon, and Dan Appelquist is coming for dinner 08:17:37 ... and on Tuesday mid morning 08:20:45 Topic: TAG Election Procedures 08:20:55 noah: what's worrying me is that we have a large turnover 08:21:02 larry: what about the AB? 08:21:25 noah: I won't be at TPAC, but you could meet with the AB there 08:22:13 ... the other piece is about tactical voting 08:22:28 Ashok has joined #tagmem 08:22:51 larry: in the election I was elected, there wasn't competition 08:23:06 ht: the last one, there were more candidates than seats, and there was tactical voting 08:23:32 ... people didn't get to express their second choice 08:23:42 timbl: it's hard to characterise how it affects the makeup of the TAG 08:23:50 noah: so what should we do? 08:24:16 ht: ask the AB to review the voting procedures to change them to a form of proportional representation 08:24:21 noah: who's in favour? 08:24:29 (all say yes) 08:24:39 ht has joined #tagmem 08:24:56 larry: I'm concerned about a bigger question 08:25:04 ... which is whether the TAG has the right expertise that the W3C needs 08:25:13 ... that's the question: whether we have the security and protocol expertise 08:25:18 ... the liaison with other organisations 08:25:37 ... where we're going in the long term for the good of the web platform 08:25:56 ... for the election procedure, how do we optimise for these things? 08:26:03 timbl: I think that's interesting, and important 08:26:12 ... but I think short term we should send a message to the AB 08:26:20 noah: what should I do? 08:26:30 timbl: just send a message to the AB 08:26:50 ACTION: noah to send a message to the AB to ask them to review the election procedures for the TAG 08:26:50 Created ACTION-744 - Send a message to the AB to ask them to review the election procedures for the TAG [on Noah Mendelsohn - due 2012-10-14]. 08:27:04 timbl: the bigger question is whether the TAG should cover all the W3C work 08:27:28 ... or target specific areas where the TAG can give value 08:27:47 noah: I totally agree on not having the mix of people we need 08:28:05 timbl: I'm asking how we know what's ideal for the TAG makeup 08:29:06 noah: the AC might not nominate a slate of people who cover what we need to do 08:29:48 ... appointed members have generally targetted the needs we have, in contrast to elected members 08:30:06 ... the other thing is that we need more than one expert in an area such as security 08:30:16 ... otherwise we can't review each others' work effectively 08:30:35 larry: I disagree: the main impediment to the election is finding people who are willing to put up the time & expense 08:30:52 ... even if it's self-nomination, you want to encourage people with the right skill set to volunteer 08:31:15 ... the AC thinking doesn't matter, it's targetting the people who will put themselves forward 08:31:43 timbl: the model that works is if someone thinks that it sucks that the TAG doesn't have representation in an area, and they find them and campaign for them 08:31:55 ... where someone notices a gap and tries to get it filled 08:32:28 ... the big problem is where no one in the area is aware of the TAG and vice versa 08:32:43 larry: the major concern about getting people to volunteer is the effectiveness of the TAG and its authority 08:32:59 ... if we're not producing things that are relevant, then it's hard to persuade people to dedicate time to the TAG 08:33:18 ... finally, I noticed the HTML-WG is doing more elevating appeals on formal objections 08:33:30 ... I'm wondering if the TAG were involved in dealing with appeals and formal objections 08:33:44 ... more reactive to disputes in the organisation, it would call for more breadth and less depth 08:33:59 ... do we have a broad range of skills that can deal with issues as they arise 08:34:12 ... as opposed to diving into things in depth 08:34:27 ... how else does the Director decide on formal objections? 08:34:37 timbl: that's an interesting point, and it would perhaps be cool 08:34:43 ... but it does require a deep dive 08:34:56 ... by the time you have a formal objection, the argument tree is very deep 08:35:03 ht: I think we should come back to this 08:35:25 ... the narrative of the TAG includes helping the Director when everything gets too much 08:35:38 ... we produced a document that said what the Director would say 08:35:46 ... but helping Director is part of our remit 08:35:58 ... I think we should come back to this 08:36:32 Present: +Mark Nottingham 08:36:42 Topic: HTTP 2.0 08:38:04 noah: mnot, could you give us a quick overview of how things stand within IETF? 08:38:11 mnot: we were rechartered officially on Tuesday 08:38:17 ... the new charter is on the IETF website 08:38:26 ... there aren't any huge surprises in it 08:38:27 We == IETF HTTP Working Group 08:38:43 ... we're going to start with the SPDY specification 08:39:07 ... the editors will be Julian Reschke (in a technical capacity to support the production of the documents) 08:40:04 ... he puts a huge amount of effort into these specs, and he has to support himself 08:40:14 timbl: maybe W3C should have a Kickstarter system 08:41:07 larry: there are some things not in the charter, that perhaps W3C can do, or play a role in 08:41:13 mnot: yes, we would welcome that 08:41:22 ... Alexy Melnikov is also an editor 08:41:38 ... and Martin Thomson 08:41:57 ... the idea is to publish a draft based on SPDY very soon 08:42:18 ashok: quick question: the only real technical stuff in the charter was the SPDY parallel connections business 08:42:26 ... is there anything else technical other than that? 08:42:39 mnot: we're chartered to start with SPDY, which means it's a default which we'll refine 08:42:46 ... we're not doing a requirements-first process 08:43:05 ... so we'll have to respond to what people ask for in the group 08:43:16 ... I'm hoping for a good broad representation 08:44:07 noah: what about the alternative technologies? what's happened with them? 08:44:24 mnot: SPDY came from a 20% project from Google 08:44:42 ... and it's been picked up by a number of other parties 08:44:50 ... we're going to draft based on that, then get a bunch of issues 08:45:01 ... which will come from the alternative techs, including the next version of SPDY 08:45:23 ... we'll hold some meetings, dig into the issues, and try to get consensus on that 08:45:41 ... plus gathering metrics, test suites and so on 08:46:36 noah: have people been doing technical due diligence on SPDY? 08:47:21 ... to work out whether it's about speed or something else that's targetted 08:47:34 mnot: it's about optimising for speed, making better use of the underlying transport 08:48:22 larry: HTTP/NG floundered because of doing flow control at multiple layers simultaneously 08:48:36 ... you get delays that don't align 08:48:55 mnot: yes, you've expressed that and Henrick has expressed that too 08:49:12 ... we either ship with flow control or without it 08:49:33 larry: you might not see this if you run controlled servers 08:49:50 ... the SPDY results required scheduling, so that the client knows what to request when 08:49:57 mnot: it's called 'prioritisation' now 08:50:17 larry: the Google benchmarks were done using the Google frontend server, and resources that had been optimised and prioritised 08:50:49 ... we're going down a road that has intermittent failure modes, but none of the measurements of performance are set up to encounter those as you would in actual deployment 08:51:05 mnot: yes, we need more test cases and to characterise the protocol better 08:51:17 ... so Akamai is trying this out for precisely this reason 08:51:34 larry: people who are concerned about web performance, you should look at the whole picture, how you arrange your resources 08:51:47 mnot: at Velocity, there are thousands of people thinking about this 08:52:05 ... they asked whether we would provide guidance about how to get the best out of the protocol, and I think we should 08:52:12 timbl: what's the status of SPDY and Apache 08:52:17 mnot: there's a module but it's not in the core 08:52:29 timbl: I'm surprised it can plug in 08:52:47 mnot: Apache 2 is very modular and you can put new protocols in pretty easily 08:53:12 noah: so all the head of line blocking stuff can't be tackled analytically? 08:53:28 mnot: if someone can put the resources into that, we'd love that 08:53:43 ... Google, Mozilla, the people who've tried it seem happy with it 08:53:50 ... we haven't seen any counter examples yet 08:54:18 noah: the obvious role for the TAG is to just keep in touch 08:54:28 ... do the TAG members feel we need to be more focused than that? 08:54:44 larry: the only thing to do is to put it in our report of things that W3C should put resources into it 08:54:52 ... into the analytical work for example 08:55:40 ... to bring people together to collaborate to collect the tests and curate them 08:56:06 mnot: all the big test corpuses are from the late 90s, on servers that don't exist and browsers that don't exist, and web usage has changed 08:56:18 ... we've started a github repository 08:56:27 ... so we can curate the tests and replicate them 08:56:48 larry: the issue for SPDY is not when you have a mashup from 15 different sites, some of which that are spread out because of sharding 08:57:03 ... data split out because you're pulling from multiple servers 08:57:23 ... this is in contrast to the Google case where the requests are all to the same server 08:58:09 mnot: the operational characteristics are going to change, for example you won't want to shard, or have sprite images, uncombine your Javascript 08:58:21 ... because that will give you less overhead 08:58:35 larry: there's a difference between not getting full effect, and things getting worse 08:59:17 mnot: the argument is that it will give more benefit for the sites that haven't done massive optimisation already 08:59:30 ... we have to look at real code and real sites and get the numbers 08:59:56 larry: there are papers that say things get worse in some cases 09:00:50 noah: 09:02:20 ht: we had the same thing with EXI: tell us your performance metrics, show us the tests, prove it 09:03:01 timbl: in the future, to get interoperability you either need all clients & servers to fall back to HTTP, or you need everything to support the new protocol 09:03:24 mnot: SPDY is only designed for TLS, and we need more than that 09:03:38 ... we need a robust upgrade mechanism from 1.1 to 2.0 09:03:54 noah: is there a goal that all servers will interoperate with existing clients and so on? 09:03:57 mnot: yes 09:04:13 ... there might be a point in the future where 1.X doesn't exist any more 09:04:23 ... like people don't have to support 0.9 any more 09:04:27 ... but we don't have to force it 09:04:55 noah: it all feels good, except that it feels early to choose the technology 09:05:12 ... like with SOAP, having it out there squewed the technical solution 09:05:28 ... we couldn't really stop because of the deployed implementations 09:05:47 timbl: SOAP is a bad analogy 09:06:00 ... replacing HTTP is a well-defined box, you can apply a lot of focus 09:06:08 ... SPDY has been out for years 09:06:33 noah: it's only in terms of not knowing what the requirements are 09:06:47 mnot: we have high-level goals in the charter; they're fuzzy 09:06:58 ... IETF isn't full consensus, it's rough consensus and running code 09:07:15 ... I think we have enough strong voices 09:07:47 larry: I have a question: I've heard there's been an exploit? 09:08:32 mnot: 'crime' -- when you're able to look into the compressed stream to see what it contains 09:08:50 ... I can use cookies to manipulate the compression space to figure out what it contains 09:08:56 http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/ 09:09:31 ... because SPDY uses compression, if you can have the client to make multiple requests 09:09:41 ... it's quite esoteric 09:09:59 ... it doesn't just apply to SPDY, but to HTTPbis you can get authentication information 09:10:10 ... the compression scheme in SPDY is one of the issues we've discussed 09:10:26 ... because it's quite memory intensive 09:10:38 s/to HTTPBis/with HTTP basic authentication/ 09:11:09 ... so we'll be looking at that to both make it friendlier and to avoid the 'crime' attack 09:11:09 s/HTTP basic authentication/HTTP basic authentication over TLS/ 09:11:50 ... if you have walls between parts of the payload then you avoid the attack 09:12:08 ... I'd like to be able to pull out a particular header without decompressing the scheme 09:12:17 s/scheme/stream/ 09:12:27 put HTTP headers in XML and then use XSI 09:13:16 ... if you're doing a bunch of requests, often there's a lot of repeated information in the headers 09:13:16 (that was a joke) 09:13:30 noah: that would require storing some state, wouldn't it? 09:13:37 mnot: yes, the question is how much 09:14:12 noah: is there anything else we should get organised on our side? 09:14:32 Ashok: mnot, do you have the slides for your talk? 09:14:40 mnot: they're on slideshare 09:15:02 timbl: around extensibility: is it possible to use this opportunity to do extensibility better than in HTTP? 09:15:16 q+ to talk about sniffing in HTTP 2.0 09:15:17 mnot: in HTTPbis one of our goals is to improve the description of extensibility 09:15:29 ... so we've done that for each extensibility point 09:15:40 ... and established new registeries 09:15:48 ... and improving the IANA registry processes 09:16:18 ... which should make it easier to register new headers and link relations 09:16:53 ... in terms of extensibility of the protocol, we're just changing the syntax on the wire 09:16:59 ... not changing the headers and so on 09:17:27 ... we need to gateway HTTP/1.X to 2.X for example, which is constraining 09:17:51 ... I'm going to work with Julian on this, to standardise a little around header syntax 09:18:14 ... I do have a concern that there's going to be another channel for metadata in 2.0 separate from headers 09:18:23 ... right now we have control headers mixed in to representation headers 09:18:28 ... which isn't great 09:18:35 timbl: and no syntactic way to distinguish them 09:19:00 mnot: in SPDY there's framing with messages about how to use TCP and so on 09:19:27 ... you could have some metadata available for intermediaries rather than encrypted, which might be good 09:19:36 Ashok: you could put policies in there, signing and so on 09:19:41 q+ to talk about content-addressable networking for static content 09:19:43 q? 09:20:08 mnot: we'll see 09:20:24 q+ to ask about HTTPbis relations 09:20:25 http://www.slideshare.net/mnot/what-http20-will-do-for-you 09:20:30 q+ 09:20:39 ack next 09:20:41 masinter, you wanted to talk about sniffing in HTTP 2.0 and to talk about content-addressable networking for static content 09:20:43 larry: the TAG has a finding about authoritative metadata, but we have sniffing 09:21:04 ... the reason we have sniffing is because the servers are misconfigured 09:21:47 ... my proposal was for browsers to turn off sniffing if it's HTTP 2.0 09:22:04 ... to drive servers to fix their media types 09:22:29 ... could you put into the update something that removes some of this variability 09:22:42 mnot: HTTP is a hop-by-hop protocol 09:23:03 ... Akamai could front with HTTP/2.0 a 1.X server, and can't get them to fix their media types 09:23:15 larry: if you have intermediaries then they have to do the sniffing 09:23:25 ... the other way around you don't care 09:23:37 mnot: that seems convaluted 09:24:00 timbl: so you make Apache SPDY implementation parse throw an error if it's not clean code going through 09:24:47 larry: if you add SPDY support to a 1.1 server, all the content will come blank because it's a server configuration error in not providing the correct media type 09:25:18 noah: if you're an intermediary, how do you know what to convert to? 09:26:05 asking intermediaries to do the sniffing can be done only for intermediaries that want to transform the content, otherwise latency will go up 09:26:12 mnot: my inbox is full of people asking for HTTP/2.0 to fix problems with 1.X 09:26:32 ... the last time we tried to do this was with pipelining, and it didn't work out 09:26:49 ... I'm not convinced that people will implement it 09:27:01 q? 09:27:11 ... you can bring it up in the group 09:27:27 ... none of the implementers are going to like that suggestion 09:27:28 q? 09:27:35 ack next 09:27:37 ht, you wanted to ask about HTTPbis relations 09:28:03 ht: what's the relationship between HTTPbis and 2.0? 09:28:36 yves: HTTPbis is finishing, almost done 09:28:46 ... 2.0 is new stuff 09:29:05 timbl: 2.0 is a transformation of 1.1: you can point to the 1.1 stuff 09:29:23 mnot: the 1.1 series of specifications define the semantics, which we are not going to touch in 2.0 09:29:34 ht: what's in scope for 2.0 vs what was in scope for bis? 09:29:47 mnot: it's just how we serialise the semantics of HTTP onto the wire 09:29:55 it's possible to change the default for missing headers 09:30:13 ... we're bumping the major version because it's not compatible on the wire, not because we're reinventing the semantics 09:30:27 ... the APIs in the implementations won't change 09:30:28 because a 2.0 -> 1.1 gateway can make the missing header explicit 09:30:52 ack next 09:31:32 09:54:02 09:55:28 Topic: URI Schema Proliferation 09:57:06 larry: the issue was raised about sites defining themselves as handlers for URI schemes and media types 09:57:18 ... the issue was whether this could be done securely 09:57:25 ... whether there's a blacklist or a whitelist 09:57:42 ht: doesn't mean the lists are fixed 09:57:47 mnot: there could be a registry 09:57:54 larry: a list is a list 09:58:11 ... the spec said that content handlers were a blacklist, that there were some that couldn't be overwritten 09:58:29 ... but protocol handlers, they said they couldn't predict which protocol handlers were out there 09:58:33 ... so they gave a whitelist 09:58:50 ... but that wasn't extensible enough, so they introduced a special syntax for the scheme: web+ 09:59:02 timbl: where web+ means... 09:59:14 larry: this is a scheme where you can override the handling of the protocol 09:59:31 mnot: I try to think about the use cases; there's little discussion of the use cases 09:59:42 ... one is URIs that are pure identifiers eg geo: scheme 09:59:46 larry: or tel: 10:00:10 mnot: right, they're not locators, pure identifiers 10:00:11 http://dev.w3.org/html5/spec/single-page.html#custom-handlers 10:00:25 ... you can't know where to dereference the geo: URI for example 10:00:38 ... there's nowhere to go to dereference that 10:01:08 ... but with registerProtocolHandler you could say, send those URIs to Yahoo maps or Google maps or Apple maps 10:01:19 ... that's an interesting use case 10:02:05 ... with my IETF hat on, there are a lot of people in IETF who are interested in late-binding of URIs to doing something with them 10:02:29 timbl: I'd like to be able to pick what I do with mailto: 10:02:42 ... and mail ids 10:02:49 ... I'd like to do something intelligent with those 10:03:21 mnot: right, you could write a handler to maybe look locally and then go off to other servers 10:03:29 ... so that's one cluster of use cases 10:03:44 ... the other one is people building protocols on top of HTTP such as OpenID and OAuth and WebCal 10:04:04 ... something which is HTTP but I'm giving it special semantics 10:04:27 ... I'm a little more concerned about this, because you're locking your identifier to a single protocol (assuming HTTP) 10:04:31 http://developers.whatwg.org/iana.html#web+-scheme-prefix 10:05:00 ... for example, OpenStack are using HTTP, maybe they'll choose to use their own URI scheme, and I'm not sure whether that's a good use of URIs 10:05:44 timbl: take daap: you can get open source music servers 10:06:06 ... I'd like to run a server that serves up my music and metadata and playlists, but I have playqueues 10:06:07 looking at the spec, http://developers.whatwg.org/timers.html#custom-handlers 10:06:20 ... with HTTP I'd have conneg on format of music and playlists and so on 10:06:47 ... there's a lot of extensibility which is being blocked, to block competition 10:07:04 mnot: I'm pretty convinced that it's not the right way to build HTTP-based protocols 10:07:17 ... but we don't have the guidance about how to do that well 10:07:45 ... the feedback I'm planning to give personally is that I'd like them to expose a registerLinkRelationHandler 10:08:10 ... I'd like to see the markup of the link -- the link relation -- to determine how to handle the link 10:08:15 larry: my concerns are different 10:08:23 ... the use cases are compelling, and there are lots of them 10:08:38 ... it's a great feature, great motivation for doing it 10:08:48 ... both registering content type handlers and protocol handlers 10:08:54 ... but it changes the story about the use of the registeries 10:09:02 ... the applicability of the guidance we give about registering values 10:09:11 ... and the assumptions about the difficulty of deploying new schemes 10:09:36 ... my concerns are about security 10:10:00 ... and for all that we've made registeries easier to get into, it removes the motivation to register things 10:10:21 ... the community that we most want to reach to register things and follow our recommendations 10:10:35 ... if you can dynamically allocate a handler, then why bother to register 10:10:49 ... it decreases the value of registration 10:11:10 ... there's a marginal value that the registry would tell you what something means, and let you find a handler for it 10:11:36 ... but now you can just provide your own, the marginal value of declaring yourself owner of something in the registry has been reduced 10:11:46 ... there's nothing in the spec about using registered values for example 10:12:19 noah: if there isn't web+ what are we asking people to do? 10:12:38 mnot: there are two issues: one is the existence of the register*Handler, and the other is the web+ convention 10:12:58 larry: I got involved in the debate over web+ but I think that's a distraction, the first is the thing we have to worry about 10:13:13 noah: there's something very local about register*Handler 10:13:25 ... registering something in an IANA registry is very global 10:13:29 mnot: but it's not either/or 10:13:55 noah: I understand that, but Larry was saying that register*Handler would reduce the value of the other path 10:14:17 registerProtocolHandler has an immediate effect, while registering something in IANA still leaves you with "running code" as a question 10:15:13 mnot: if there are problems in the IANA registration we have to fix them, but that's separate 10:15:19 noah: what about the web+ issues? 10:15:40 mnot: I think there are a lot of questions to be answered, like what's the relationship between foo and web+foo? 10:16:01 I'm not concerned about the methods once the security and privacy concerns are addressed. I'm just wondering why we continue to work on the registries, since they aren't nearly as useless as the IANA registries. 10:16:18 timbl: was web+ designed by people who felt they didn't control the whitelist? 10:16:39 larry: the rationale for it was given as that they didn't want to do a blacklist because they were uncertain about existing deployed protocols 10:17:05 noah: web+ seems to be bundling up something in the name which is about how the URIs are used 10:17:30 perhaps vendors have lots of schemes that they don't want anyone to overwrite, but they don't want to bother blacklisting 10:17:38 ... that feels very wrong to me: we should be figuring out how to make whitelists 10:17:56 mnot: the browsers say they don't want to be updating the whitelists all the time 10:18:06 ... but actually they get all sorts of whitelists all the time 10:18:13 ... which they update all the time 10:18:48 larry: I had a use case that I was worried about 10:18:56 ... when we did mailto: there was concern about privacy 10:19:05 ... that when you clicked on mailto: it didn't send the message right away 10:19:20 ... we didn't want them to interact with the server until you had looked at the message and confirmed it 10:19:39 ... if I register GMail to handle it, GMail gets notified when I compose the message 10:19:50 mnot: the default action for any URI is that it's safe 10:20:14 larry: the problem is that the handler makes a permanent change to the system 10:20:54 mnot: I think the presumption is that the browser guys will have a user experience around managing the mappings 10:21:24 larry: this is all going to happen: there are compelling use cases 10:21:34 ... people know that if you use the web you've lost all your privacy anyway 10:21:50 ... why should we continue to bother with these silly registeries 10:22:25 mnot: my concern is mostly around that by allowing this capability in browsers, it tilts the creation of web applications toward a certain architecture 10:22:33 ... that's why I want a registerLinkRelationHandler 10:22:42 ... and the other concern is about the web+ convention 10:22:52 ... it's almost aesthetic, but it's like X- 10:23:03 noah: you're bundling something into the name, and the thing you're naming has other uses 10:23:14 ... the name has other uses which have nothing about the protocol handler 10:23:38 ... this feels like something that the TAG should do something about 10:23:51 mnot: there's emerging consensus in the IETF from discussions around X- 10:24:11 ... which is putting structured information inside identifiers, anything that is ephemeral or temporal or context-specific 10:24:34 ... we've had a few experiences of this in protocol designs, where it's not worked out 10:24:48 noah: how can we work with the IETF towards a good solution? 10:25:22 mnot: what kind of timelines are we on? 10:25:43 ht: I think the longer term question is longer term 10:25:59 ... we've lived in a world in which there have been a handful of schemes for a long time 10:26:12 ... it looks as if we're headed for a world in which that is going to change 10:26:16 ... what are the consequences of that? 10:26:29 mnot: that was my first reaction, and I'm not sure any more 10:26:38 ... I don't think we'll see 50,000 bloom overnight 10:26:53 ht: even if we go from less than 10 to more than 50 over the next five years, what's going to happen? 10:27:28 timbl: it's not just a large number, it's a shift from being defined openly in the IETF but to locking people in to a particular system 10:27:45 mnot: you have to convince people to use the URIs on their websites 10:27:50 ... I think that's a fairly high bar 10:27:57 http://www.w3.org/TR/webarch/#pr-reuse-uri-schemes 10:27:58 It amounts to introducing a new distributed extensibility point 10:28:05 Good practice: Reuse URI schemes 10:28:17 A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources. 10:28:42 And per analysis which JAR has recently done, distributed extensibility introduces the potential for interop loss 10:29:05 timbl: I'm thinking about itunes: which people use to point to an iTunes App 10:29:15 At the very least, introducing distributed extensibility into the URI name system at the scheme level is a novelty which we really need to examine 10:29:20 mnot: it's interesting because Apple have moved to using a content type 10:29:42 noah: we wrote about that 10:30:08 mnot: if we have good handlers for content types and link relations, then I don't think there's a strong need for extensibility around URI schemes 10:30:24 noah: what could we do about this that would be effective? 10:31:03 larry: my take is that this is the future, and the TAG should stop trying to limit the number of URI schemes 10:31:14 ... now doi: can be deployed, now info: can be deployed 10:31:22 ... the arguments we've given in the past no longer applies 10:31:35 ht: because you no longer have to change the browser to support them 10:31:55 mnot: there's the question about the web+ schemes, whether they should be linking to the registry 10:32:42 noah: I believe we've previously had strong review of new URI schemes 10:32:55 ... this seems to suggest that review is superfluous 10:33:27 larry: Dave Thaler took all the URI schemes in Wikipedia and registered them as provisional schemes, in the last month or so 10:33:28 jrees has joined #tagmem 10:33:38 ... there were about 70 of them 10:34:01 mnot: we can't stop people from deploying schemes 10:34:11 ... we can try educating them, and document the best practices 10:34:36 larry: there's skype: and notes: 10:34:46 ht: it becomes a market economy 10:35:06 mnot: perhaps it's self-limiting 10:36:59 ht: wrt message handlers, about registry management and IANA/IETF expert review 10:37:26 mnot: there are only a handful of people who care about this stuff, and there's consensus amongst them 10:37:47 ht: it's moving towards saying that it's about documenting the state of deployment etc 10:37:57 ... with the side effect that it serves as a collision avoidance mechanism 10:38:21 Odd that the values arent communicable 10:39:07 ... if you have distributed extensibility without a collision avoidance mechanism, then there's potential for a train wreck 10:39:27 ... so long as the registration is lightweight, you're ok 10:39:45 mnot: it would be nice if all the URI schemes, link relations and so on were well-specified and architecturally sound 10:39:50 ... but that's not the world 10:40:59 ... for me the really interesting part is whether registries are the correct approach for HTTP methods as opposed to URI schemes and link relations 10:41:59 ht: the other thing to cover is the motivation of the application focus of the major focus of the major vendors is at the moment 10:42:10 ... why they're interested in the web as the application platform 10:43:43 ... the browser as the app delivery platform 10:43:50 ... and the relevance of the mobile web 10:44:47 ... the major concern of a number of vendors is to break the platform-specific advantage 10:45:06 ... platform-specific apps have a performance advantage at the moment 10:45:24 ... a lot of why vendors are pushing the browser is about fixing that to avoid being locked out of these platforms 10:45:41 ... that's not my insight, btw, it's mnot's 10:47:26 larry: there are some principles that we would like to have, such as links 10:47:38 ... the protocol handler shouldn't have to go to the web, it could go to the local app 10:48:11 ... the question is whether creating native apps is in scope for W3C, and I think it is 10:48:28 Ashok: I am also concerned about security 10:48:39 ... about people hijacking your handler 10:49:09 noah: it feels like only half the technical things being proposed are needed to achieve the goal 10:49:30 ... a sense that we can't afford to wait to get things right 10:55:46 10:59:32 You would use 800# 11:01:01 s/way/we/ 11:28:20 jrees, you there? 11:28:24 jar, you there? 11:28:45 Hi 11:30:56 Skype, for a bit? 11:33:38 OK, not to worry 11:37:01 Hmm it changes me to 'away' when i switch apps on the phone. Interesting 11:37:22 OK, we'll try 11:53:11 Vocabulary: A set class/property/element/attribute names for use in a markup language or other media-typed content 11:53:37 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html#dfn-vocabulary 11:53:55 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html 11:56:16 +suffix registration 11:56:16 a registration for a +suffix 11:56:34 Should that be a >media-type< registration for...? 11:58:20 Zakim has left #tagmem 12:04:31 Zakim has joined #tagmem 12:04:32 hmmm http://itunes.apple.com/gb/album/beatles-1967-1970-blue-album/id400835735# 12:05:42 scribenick: timbl_ 12:07:48 Noah: We are now in our schedule up to fragid semantics 12:08:24 We traditionally do some admin and planning after the break, but we can do whatever we like. 12:08:44 note that registerContentHandler doesn't say anything about fragment identifiers 12:09:00 Jeni: 12:09:08 Jeni is speechless 12:09:11 topic:FragIds 12:09:18 Jeni: 12:09:19 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23 12:09:19 ... 12:09:45 Jeni: The hosyry is we got a proper FPWD out Juneish. 12:10:06 s/hosyry/history/ 12:10:38 [general discussion of the hosyry] 12:10:59 We got one set of substantive comments. 12:11:11 we got a positive review from Alexey M 12:11:20 … We are trying to ge this through the process ASAP, no substantive comment expected 12:11:36 … I will this session go through our response to that comment. 12:11:52 … We with then just proceed though the process. 12:12:39 … A new editors draft is up of 23rd . 12:13:54 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html 12:14:13 http://lists.w3.org/Archives/Public/www-tag/2012Sep/0042.html 12:14:29 Jeni: Looking at my response to Sebastian 12:14:56 … He seemed to be using RFC2046 terminology, different tho what is used in th ecurrent media type registration draft. 12:15:14 s/th ecurrent/the current/ 12:15:20 jrees has joined #tagmem 12:15:42 … He uses the terms 'subtype', for example. 12:16:14 …. I did a few changes of my document to change the vocabulary. 12:17:21 Larry: If you go to that URL (http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14) 12:18:23 Larry: They are holding it -- it is approved but on hold pending the suffix registration … on which it has a dependency. 12:18:49 Jeni: The comment #2 he had was about long noun phrases. 12:19:13 … The majority of the changes I made were to try to fix that. 12:19:58 … This is to make it easier to read. Also introduced new terms like metaformat and vocabulary to make the text easier to read… maybe I went to far. Let's discuss that. 12:20:36 Jeni: Noah, please now do your anti-'vocabulary' rant. 12:20:58 Larry: It looked better to me with 'vocabulary'. 12:22:10 Jeni: We use the term 'metaformat' but I am not sure everyone does. 12:22:24 Noah: I am fine with what you are trying to do. 12:23:08 Jeni: I used 'fragid' and '+suffix' as a shorthand. 12:23:22 … for media type suffix registrations. 12:24:05 +suffix registration definition to include 'per the RFC' 12:24:40 Jeni: Theo other definitions were there already [just before section 3] 12:24:49 Jeni: Now the email comment point #3 12:25:21 … He suggested the term 'pragmatics' for the rules which we use to process something, but I pushed back as I felt that was unusual. 12:25:36 … I made no change there. 12:26:22 .. "Media Subtype Registration" he said you should use but out isn't defined so I said no. 12:26:57 … "Structured Syntax Suffix Registrations" I tried to adopted what was good about his suggestion and otherwise pushed back. 12:27:54 … There were no logical issues, only linguistic ones. 12:28:21 timbl: nice abstract 12:28:51 ... use the term 'local ids' rather than 'anchors' 12:30:43 44 1793 417 679 12:31:28 timbl: if you have some generic software, it doesn't work for the media type to specify the prioritisation 12:32:44 JeniT: yes, in the body of the document it says that 12:32:46 timbl: The bit " Where fragid syntaxes do overlap, media type registrations should specify which take priority in resolving a given fragid." but in the case of an unknown media type using a known suffix, there is no known media type spec to specify which can override. 12:33:08 http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2Ffragid-best-practices%2F&doc2=http%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2Fdoc%2FmimeTypesAndFragids 12:35:32 ht: Let's just chop out masses of the abstract 12:35:48 timbl: no, nice length, nice summary -- many people will only read that. 12:37:05 JeniT: In general, the media type registration has to specify how frauds are interpreted 12:40:11 Jenit: This is attempting to summarize Best Practice 2. 12:40:58 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html#specify-resolution-of-overlaps 12:41:24 timbl: This is about multiple conflicting structures 12:45:43 ht: At the end of section 5, 12:46:10 … there is this very delicate wording issue, which is the way we dealt with the RDF case. 12:47:23 … If a point in a [lexincal] space defined by the generic processing is not in is domain, then you look for a more specific scheme to give you an answer. 12:48:08 … This means in the RDF case, this work so long as foo#baz is something the generic +xml spec does not have anything to say about. 12:48:10 todo: make sure to include fact that +xml generic processing must be preserved in media type 12:49:52 Jeni, maybe put tth eBP numbers in the TOC 12:51:09 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-09-23.html#enable-additional-fragids 12:51:23 [discussion of that, HT getting in sync w spec] 12:51:52 Noah: I don't have a problem with what you mean by "top level type". 12:52:23 .. You could say "such as image or text". 12:52:24 todo: add a 'such as' for top-level type and +suffix use in abstract 12:53:01 Noah: Are people leaning toward approaching this as a top-level draft? 12:53:10 Larry: I have some nots. 12:53:41 … Around IRIs and unicode normalization .. There are more bets practices than are listed here. 12:53:53 todo: say we're not addressing unicode normalisation, internationalisation, use of fragids in registerProtocolHandler 12:54:03 Noah: You are swelling the punch line…. should we hold off or publish? 12:54:17 Larry: No, publish 12:54:50 jeni: In the SOTD you can mention things like where other work would be possible and relevant. 12:55:04 Larry: Or in the introduction. 12:55:34 Noah: A separate Future Work Section? 12:56:06 JeniT: no need for that. 12:57:13 s/frauds/fragids/ 12:57:32 ht: The RDF problem is resolved at the result ion level, not the registration level. 12:59:23 s/result ion/resolution/ 13:00:44 … The trick is that in fact the XML system will in practice for RDF documents not return a resolved thing for a RDF fragid. 13:01:17 … You have to just avoid using about="#foo" and id="foo" in the same document or things break. 13:01:44 or it means that you are making statements about the element in the XML document 13:02:05 … Two other things we could say: Avoid things which lead to contradictory results. 13:03:10 .. Or we can also re-issue the RDF+xml spec to allow the XML one to take priority. 13:03:32 .. Or maybe we should point out what could go wrong if you don't avoid it. 13:04:13 todo: possibly add sentence that says that if you don't follow the rules aroudn honouring generic processing of fragid structures, you can get points where the same fragid points to different things based on different processing 13:04:43 maybe s/different/generic vs. specific/ ? 13:05:48 Ashok: Re BP7, the end of it says "anything" .. "should say that such fragids are resolved according to rules in the registration of the vocabulary and may identify anything." 13:05:55 jrees has joined #tagmem 13:06:06 todo: s/and may identify anything/and what it identifies is unconstrained/ 13:06:22 … I would prefer "not constrained" in some way. 13:06:59 todo: s/and may identify anything././ 13:07:31 timbl: may identify anything becomes "identify whatever is defined in the M T R". 13:08:00 Best practice 7: leave out the words "and may identify anything" 13:10:52 timbl: If you have many generic patterns defined, then the later ones cannot override the earlier ones, as they have to be consistent with systems which were defined wit knowledge of only the early spec. Therefore is reasonable to apply the algorithms in chronological order by date of spec. 13:12:04 larry: We shouldn't define Bps for a spec which is being discussed. 13:12:45 … We should get this document into the loop for the processes which produce media type registration documents in W3C and IETF etc. 13:13:18 [meta re agenda] 13:14:16 Larry: We should made sure that this document is referenced where it should be. 13:14:38 .. There is Public Relations about going to Proposed Recommenation. 13:14:47 s/../Larry: 13:15:21 registerContentHandler needs to say something about fragment identifiers 13:15:28 Jeni: I will do another draft, take it to a telecom for conformation then publish it. 13:15:54 Larry: I am happy to Last Call this now. 13:16:45 [Straw poll suggests making the basic Last Call decision now] 13:17:50 PROPOSED: We will vote to go to last call under the following -- JeniT will indicate when draft is final, then four working days for objects, failing which implicitly permission for JeniT to publish. 13:18:33 RESOLVED: We will vote to go to last call under the following -- JeniT will indicate when draft is final, then four working days for objects, failing which implicitly permission for JeniT to publish. 13:19:06 ________________ 13:19:16 subtopic: * 13:19:19 HT: 13:19:39 … I now have the write lock on 3023bis 13:19:39 ACTION-689? 13:19:39 ACTION-689 -- Henry Thompson to work with Noah to draft a further request to the 3023bis editor from the TAG to include advice regarding what a particular +xml media type registration should do wrt fragid semantics along the lines in the discussion on media types and fragment identifiers at the f2f on 2012-04-04 -- due 2012-10-01 -- OPEN 13:19:39 http://www.w3.org/2001/tag/group/track/actions/689 13:19:48 s/30/RFC30/ 13:20:25 draft-ietf-appsawg-xml-00 13:20:32 ACTION-564? 13:20:32 ACTION-564 -- Henry Thompson to track fragid issues in 3023bis, report to TAG and/or communicate with 3023bis editors as appropriate -- due 2012-09-30 -- OPEN 13:20:32 http://www.w3.org/2001/tag/group/track/actions/564 13:20:36 HT: I hope to get this published … it should come out soon as a ... 13:20:51 draft-ietf-appsawg-xml-00 13:21:10 … as draft-ietf-appsawg-xml-00 13:21:15 jrees has joined #tagmem 13:21:48 LarryL There is a deadline October 15th for -00 versions of Internet drafts =before the next IETF meeting 13:21:49 hmm ... I see no actions to Jeni on fragids... 13:22:12 HT: There is a October 19 deadline for last call for +suffix registrations. 13:22:28 [@@HT] 13:23:30 HT:There is a document with a bunch of +suffix registrations which have never been registered and includes language from JeniT's document. 13:23:55 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. 13:24:04 … It references 3023 of course, I hope it could reference my version instead of course. 13:25:03 … So text/xml and text/xml[…]entity are being undeprocated due to deployment 13:25:45 … The resolution is that text/xml can override text/ in defining default charset. 13:25:50 https://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-06 13:26:11 ACTION-689? 13:26:12 ACTION-689 -- Henry Thompson to work with Noah to draft a further request to the 3023bis editor from the TAG to include advice regarding what a particular +xml media type registration should do wrt fragid semantics along the lines in the discussion on media types and fragment identifiers at the f2f on 2012-04-04 -- due 2012-10-01 -- OPEN 13:26:12 http://www.w3.org/2001/tag/group/track/actions/689 13:26:32 close ACTION-689 13:26:32 ACTION-689 work with Noah to draft a further request to the 3023bis editor from the TAG to include advice regarding what a particular +xml media type registration should do wrt fragid semantics along the lines in the discussion on media types and fragment identifiers at the f2f on 2012-04-04 closed 13:26:36 … and our representations about frauds are bing implemented. 13:26:38 ACTION-564? 13:26:38 ACTION-564 -- Henry Thompson to track fragid issues in 3023bis, report to TAG and/or communicate with 3023bis editors as appropriate -- due 2012-09-30 -- OPEN 13:26:38 http://www.w3.org/2001/tag/group/track/actions/564 13:27:10 ACTION-564 Due 2012-10-23 13:27:10 ACTION-564 Track fragid issues in 3023bis, report to TAG and/or communicate with 3023bis editors as appropriate due date now 2012-10-23 13:27:17 [discussion of how to explain this all to trackbot] 13:27:47 ACTION-707? 13:27:47 ACTION-707 -- Henry Thompson to keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis -- due 2012-10-05 -- OPEN 13:27:47 http://www.w3.org/2001/tag/group/track/actions/707 13:28:02 close ACTION-707 13:28:02 ACTION-707 keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis closed 13:28:31 timbl has left #tagmem 13:28:46 ACTION-543? 13:28:46 ACTION-543 -- Peter Linss to propose addition to Fragid draft to discuss sem-web use of fragids not grounded in media type -- due 2012-09-26 -- OPEN 13:28:46 http://www.w3.org/2001/tag/group/track/actions/543 13:29:09 s/[@@HT]/draft-ietf-appsawg-media-type-suffix-regs/ 13:30:13 Jenit: 543 was for me to write stuff around complex identifiers in RDF etc, which lead to this work, and got repurposed at some point to something for Peter? Not sure how. 13:31:52 Larry: I have something I don't want to do but I think I should do. 13:32:43 … The registered content handler in HTML doesn't say anything, as the registered protocol …there is nothing about frauds. 13:33:17 Jeni: We should be taking on work around that whole area. 13:33:39 s/frauds/fragids/g 13:34:15 Noah: There is session at the end on TAG priorities. Remind me then. 13:34:31 ACTION: Jeni to get LCWD of fragids & media types published and respond to comments 13:34:31 Created ACTION-745 - Get LCWD of fragids & media types published and respond to comments [on Jeni Tennison - due 2012-10-14]. 13:36:20 [break] 13:39:01 ACTION: Jeni to raise a bug on registerContentHandler and registerProtocolHandler to ask for specification of how fragids are handled 13:39:02 Created ACTION-746 - Raise a bug on registerContentHandler and registerProtocolHandler to ask for specification of how fragids are handled [on Jeni Tennison - due 2012-10-14]. 14:06:20 Zakim has left #tagmem 14:08:13 No point in doing awwsw 14:08:18 At all 14:08:43 Ok. Yes, try 14:09:00 May not work 14:09:22 Have wifi on bus but draining battery 14:09:41 2 things. 14:09:48 ____________ 14:09:57 Ashok: We published FPWG 14:10:00 I have skypeout 14:10:26 I have abiloty to call 800 num as noah hinted 14:10:31 … We got on it 3 comments, Renato Ianella about a reference to a licence -- JARand he agreed o with hime. 14:10:51 Or pots 14:10:57 … One from D Booth who wants a section -- "Who are we writing this document for"? 14:11:55 … The Third comment is from a lawyer from CDT the center for democracy and technology: 14:12:25 10 If this is for non-technical people like lawyers, then there is jargon like HTTP headsets which we should explain. 14:12:31 s/10/1)/ 14:12:46 s/headsets/headers/ 14:13:09 Larry: Danny W had a comment: 14:14:40 Larry: A layer at Adobe wondered what we were doing in the first place. 14:14:55 … We should explain the history. Some anecdotes. 14:15:13 Timbl: Maybe some example of people actually confused out there on the web. 14:15:46 Noah: SOPA and PIPA came later. 14:16:26 Jenit: It was people being arrested for embedding when the were reported as linking. 14:16:52 I’m not sure what initiated our discussion of “publishing and linking” motivating the work, but now that we have the document, I see news articles daily which remind me that governance of the Internet is difficult enough… Should YouTube have taken down the offensive video ostensibly causing riots? How can facebook prevent being used for “cyberbullying” ? Are there any underlying principles we can discover? 14:16:53 14:16:53 So the question is “without rewriting this document completely from the ground up, is there anything we (the W3C Technical Architecture Group) can do to make this level of analysis more useful. To someone. 14:16:53 14:16:56 If we can find a (substantial) community that finds it (reasonably) useful, then that will be sufficient. There may be some other document we could write that would be even more useful, but the TAG has a limited attention span. 14:16:59 14:17:01 Ashok; One suggestion was to start with the legal issues and then derive the technical bits .. but we are not qualified to write that document. 14:17:34 … JAR has provided two very useful documents, one pointing to early RFCs, and a book, soI will add those in. 14:18:16 Larry: I replied to Danny: [@@ scibe -- passed into IRC above] 14:18:26 s/scibe/scribe/ 14:18:47 Ashok: We have had comments saying it is very useful to spell out these differences. 14:19:20 It was about dissonance between consesus among tech fiolks and rest of society 14:19:40 TBL: Make clear that this is not a policy document 14:19:55 timbl: We need to make it clear that the document os not law and is not policy. 14:20:08 s/os/is/ 14:20:50 Askok; Maybe we can get Thinh N'guyen to look at it, 14:21:09 … Then too look at technical terms we need to explain. 14:21:42 Purpose was to record consensus of tech community, re expectations on purpose and use of tech 14:21:49 [Two or three TAG members have read this version] 14:22:38 State the obvious. Not immediately 'useful'... Anticipatory 14:22:50 Larry: What I would like to see happen. 14:23:12 … I see a lot of activity. We have seen with concern the moves to use Internet policy to the ITU, 14:23:39 … we have seen various countries wanting to control communication, and the debate offer the YouTube video and the routing. 14:23:54 s/routing/rioting/ 14:25:08 …. I think we have reached the edge of the TAG's remit, I think we have hit a good point, and happy if we have been a bit controversial. No one else in the W3C is sodding this. I think it important for W3C too do this. 14:25:22 If we wait for the doc to be 'useful' it will be too late 14:25:47 +1 14:25:49 Noah: I hope we can say that this is very well done. Fragids we can sort out later, but this has to be consistent, as its intent is to clarify. 14:26:18 Point is to not be reactive, to put tech neck out re purpose of tech 14:26:20 Askok: You want the governance and risks documents to be separate documents? 14:26:37 Larry: "Publishing and linking" has been through a lot of review. 14:27:05 … It is clear -- or it will be when we explain -- why we got started in this. 14:27:21 I just want to be sure that, as far as it goes, it's clear and of high quality. I haven't (unfortunately) read it lately, so am not well informed. Larry says: yes, quality is very good, so I'm happy. 14:27:28 Ashok: Let's fix known bugs then ask the TAG about last call. 14:27:53 Larry: Would be nice to have it in Last Call at TPAC. 14:30:26 Yves: There is no moratorium BEFORE TPAC, only DURING 14:31:05 Ashok: The Intro needs some use cases to be found.... 14:31:15 Ashok: The Intro needs some use cases to be found….Jenit: Some pointers already in the document. 14:31:32 Larry: Just some background about why we did this 14:31:55 Ashok: Ok. 14:32:34 … We will try to get feedback from commentators rapidly. 14:32:55 … David Booth we can. 14:33:15 Noah: On the call on the 18th, let us know where we are. 14:33:27 Ashok: OK. 14:35:16 Noah: See the product page for this. 14:36:45 http://www.w3.org/2001/tag/products/PublishingLinking.html 14:37:14 ACTION: Ashok to update product page on publishing and linking: dates and link to public draft 14:37:14 Created ACTION-747 - Update product page on publishing and linking: dates and link to public draft [on Ashok Malhotra - due 2012-10-14]. 14:37:52 ACTION: Ashok to prepare draft of Publishing and Linking by Oct 15 - Due 2012-10-15 14:37:52 Created ACTION-748 - prepare draft of Publishing and Linking by Oct 15 [on Ashok Malhotra - due 2012-10-15]. 14:39:52 ______________________ 14:43:57 topic: 3032bis revision 14:44:08 [HT projects] 14:44:15 From our minutes of April f2f: http://www.w3.org/2001/tag/2012/04/04-minutes#item02 14:44:25 RESOLUTION: The TAG requests the 3023bis editors to adopt the following wrt fragids: The semantics of barename fragment identifiers is as follows: for those barenames in a +xml document which are "identifiers of an element" as defined in [XPointer Framework], a barename fragid identifies the element [XPointer Framework] says is does. The semantics of all other barename fragids are unconstrained 14:44:26 by this specification. Likewise wrt other fragids using registered XPointer schemes, i.e. that XPointer "failure to find" errors are not errors, rather a statement of unconstraint. 14:45:42 [HT edits on screen] 14:46:02 Ht: This is my proposed resolution of that change. 14:53:58 hmm. Let me check. 14:55:25 Please note that the other editors have not seen this, and may not agree to it: http://www.w3.org/2001/tag/2012/10/private_draft_draft_3023bis_draft.htm 14:55:29 [scribe asks for URI to it -- shared with the TAG but not generally accessible] 14:57:00 https://www.w3.org/2001/tag/2012/10/private_draft_draft_3023bis_draft.htm#frag 14:58:01 HT: The first question is whether the change requested (to say that for the +foo you do not claim control of syntaxes you do not control) is described here. 14:58:37 You're getting No Answer? No ring? 14:59:27 HT: Maybe by getting out of the way here we can allow some one to generate say a new spec for text/* -- this is broader than what was originally asked for. 15:01:26 01793417417 15:03:06 s/01793417417// 15:03:18 is the BCS number is what you get from calling outgoing calls callerid 15:06:40 ht: A detail question is that the way this ends doesn't say hwta happens when the attempt succeed: that we are done. Nothing else happens. 15:06:54 s/hwta/what/ 15:07:15 Noah: Works for me as is. 15:14:22 Noah: Who would object to this broadening? Let's put it out there and see whether anyone objects -- this is the Internet after all. 15:14:41 Yves: The XML community should see it.. 15:15:11 HT: But there has been really no previous document. 15:15:14 ..through the XML CG 15:15:23 Jenti: maybe people will expect errors to fail hard 15:15:35 s/Jenti/JeniT/ 15:15:35 s/Jenti/JeniT 15:19:43 timbl: XPointer's syntax includes typos 15:19:52 ... there's a narrower language that uses XPointer's schemes 15:20:10 ... and a narrower set that actually resolves to an element in the document 15:21:03 ht: noah's point was without processing you can describe three cases 15:21:23 ... the string is not a syntactially valid XPointer 15:21:29 ... per your XPointer implementation 15:21:52 s/syntactially/syntactically/ 15:22:56 ... it's helpful to pull out three possibilities (1) you resolve the XPointer (you win), (2) you lose because it's not syntactically correct, (3) you lose because the pointer doesn't identify an element in the document 15:23:41 timbl: I think there's another case in XPointer that they haven't talked about, which is about what schemes are supported 15:28:35 [discussion of possible combinations or error] 15:28:51 NM: My concern is that a fragid like element(A) should refer to element(A), regardless of whether my particular processor supports it 15:28:58 jrees, can you hear us? 15:29:23 HT: Suppose in a new media type spec "I will use th henry X-pointer scheme". 15:29:35 s/th h/the h/ 15:29:56 … What I want ois for this spec to leave it alone, so I can grab it. 15:30:40 … Whether -- the scheme is registerers by there is no resolution for this particular case -- or ….. 15:32:18 Noah: Suppose [missed] 15:32:27 HT: I need togo away and think about this. 15:32:54 … When we need to push this past the XML community, the best way is to push this past the CG.. 15:33:04 s/togo/to go/ 15:33:32 … This has to call out the fact that this maybe considered a change t othe implicit semantics which have been considered betore. 15:33:36 Yes 15:33:47 … I think i should talk about semantics rather than processing. 15:34:31 [ Discusssion involved also http://www.w3.org/TR/xptr-framework/#syntax ] 15:34:47 ______________________________________________ 15:35:00 No 15:35:09 Muted 15:55:50 RESOLVED: TAG will meet 15-17 January, tentatively at Adobe West Coast, but may switch to Cambridge depending on Noah, Tim Jeni availability. 16:03:54 Bye? 16:06:00 bye 16:06:49 RESOLVED: The TAG will (probably) meet in Cambridge March 19-21 2013 17:54:20 jrees has joined #tagmem 17:54:40 Rrsagent, pointer? 17:54:40 See http://www.w3.org/2012/10/07-tagmem-irc#T17-54-40 19:35:07 noah has joined #tagmem 19:46:56 JeniT has joined #tagmem 20:14:13 ht has joined #tagmem 20:21:03 rrsagent, draft minutes 20:21:03 I have made the request to generate http://www.w3.org/2012/10/07-tagmem-minutes.html JeniT 20:26:09 timbl has joined #tagmem 20:35:52 timbl has joined #tagmem 21:03:37 timbl_ has joined #tagmem 21:27:10 timbl_ has joined #tagmem 22:34:48 timbl has joined #tagmem