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