- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Wed, 16 Jun 2010 14:34:39 -0400
- To: "www-tag@w3.org" <www-tag@w3.org>
The TAG held a three day face-to-face meeting last week in London, from
7-9 June 2010. Unapproved draft minutes are now linked from the agenda
[1]; the referenced files with the minutes for the individual days are
at [2-4], and are appended in text-only form below.
TAG members are encouraged to review these for accuracy, and to either
propose or check in edits as necessary. Thank you.
Noah
[1] http://www.w3.org/2001/tag/2010/06/07-agenda
[2] http://www.w3.org/2001/tag/2010/06/07-minutes.html
[3] http://www.w3.org/2001/tag/2010/06/08-minutes.html
[4] http://www.w3.org/2001/tag/2010/06/9-minutes.html
=================================================
[1]W3C
[1] http://www.w3.org/
TAG F2F
07 Jun 2010
[2]Agenda
[2] http://www.w3.org/2001/tag/2010/06/07-agenda
See also: [3]IRC log
[3] http://www.w3.org/2010/06/07-tagmem-irc
Attendees
Present
Jonathan_Rees, Noah_Mendelsohn, Ashok_Malhotra,
Henry_Thompson, Daniel_Appelquist, TimBL, Yves_Lafon,
John_Kemp
Regrets
Larry_Masinter
Chair
Noah Mendelsohn
Scribe
Jonathan Rees, Yves
Contents
* [4]Topics
1. [5]Convene, review agenda
2. [6]Web Applications: Overview
3. [7]HTML / XML Unification
4. [8]Domain name persistence (workshop planning)
5. [9]Web Applications: Client-side state
6. [10]Web Applications: Security
* [11]Summary of Action Items
_________________________________________________________
<jar> convening
<jar> scribe: Jonathan Rees
<jar> scribenick: jar
Convene, review agenda
Welcome Yves to the TAG
F2F Main Goals:
Make progress on writing related to Web Application Architecture
XML / HTML integration
Other technical topics
noah: Question: what is the best form for our publications? recs,
findings, blogs
... Let's get things written, push them out, then figure out their
disposition (finding etc)
... Move domain name discussion from Tues to Mon
ht: My goal was to brainstorm with a few (non-TAG) people on whether
a more substantial meeting for consensus building is worthwhile
... Kevin Ashley, new director of DCC (digital curation center)
<ht> Helen Hockx-Yu
ht: Helen is from British Library
(discussion of agenda, how to involve John K and others who have to
call in)
Web Applications: Overview
<DKA> [12]http://www.w3.org/2001/tag/2010/05/web-apps-notes.html
[12] http://www.w3.org/2001/tag/2010/05/web-apps-notes.html
dka: (talking from projected page -- follow above link)
... TAG could act as a 'lens' relating frontline work to broader
community
... Robin Berjon has been helpful
... Look at how how 'web applications' are being used in the field
... Originally people used GET... maybe not always in the best way
... Look at patterns of web app usage, say here's how they use the
artifacts of web arch. Maybe this would be useful
... relation of messaging protocols to webarch - e.g. in social
networks
timbl: Messages vs. information space
dka: e.g. Websockets is making this connection; that's interesting
ht: +1 to drilling down enough to understand how XMPP addresses
[this]
timbl: Pattern approach is good, say: If you use these protocols in
this way you get this value.
... Applying this to web apps arch, there are many different areas,
so [difficult]
... Taxonomies are ratholes...
ht: People are inventing new things faster than we can classify them
dka: People know REST, and ask what can the TAG add to the REST
story?
timbl: REST used to mean web + Fielding... now there are new
patterns that build on this (e.g. odata, JSON, SPARQL patterns)
noah: There's a level where we might say here's the architecture
pattern, that connects client side & server side use of URIs
... Raman is giving interesting particular examples; [that's a
second level]
... connect the 2 levels (architectural patterns & usage patterns)
dka: I'm influenced by what we're doing in mobile web best practices
group. Look into applying some of that methodology. Here's a usage,
evaluate it, does it lead to a good result?
timbl: often TAG work has been triggered by a very specific issue.
Intense discussion, followed sometimes by saying it's OK.
dka: Where can we have an activist agenda?
noah: Our mandate is architecture... the web is an information
space, much of the value comes from linking
... network effects
dka: The 'cool uris don't change' resonates with people, they know
w3c says this
yves: Hard to link into a silo. Entertainment industry, for example,
tends to make monolithic [insular] apps
ashok: Is it lack of education, or is it business reasons?
timbl: One concern about web apps is that they're too slow, this
motivates things like app stores [native applications that could
have been web apps]
noah: The native apps are less clunky, little things
timbl: We can [try to] clean up the web... [or] we could push for
very hot web apps...
ht: Many of these "you need specific browser X to look at this page"
errors are false - the page works fine if you edit out the browser
detection code
timbl: (writing on white board, 3rd item in list after 'very hot
apps') Decent social networking (socially aware storage; P2P)
dka: I care about this last one, but I wouldn't put it under the
topic of web apps
noah, timbl: "For more, see the facebook page"
ht: But then it is on the web, right?
timbl: The problem is that the garden center is committed to FB
being their ISP
dka: re security, I've been focusing on DAP, GEO
... in widgets, there's the concept of a feature having a URI (e.g.
the geolocation)
... this mirrors what app stores are trying to do. E.g. "this app
wants to access you camera and location, ok?"
noah: There are 3 levels of apps, app store, drive-by, widgets (with
install step)
dka: What constitutes a web app?
ht: we talked about this in Cambridge, with John K
timbl: negotiating the interchange of data between otherwise
untrusted parties. An install is part of a trust system. The
dominant web sites are ones that get trusted.
... different [orthogonal] from technical questions, such as
shuffling data, caching
noah: Users think they know what it means to install something. At
install points they expect these annoying questions
ashok: There can be problems if your situation changes (you don't
want to allow use at a particular location, etc)
noah: Tension between install step & on-the-spot decision making
dka: Is there a middle way?
... People who are building widgets think of them as app containers,
maybe [missed]
yves: You want a local storage of [privacy/security] properties that
can be examined and changed
timbl: BT open zone
... there's an assumption that the domain is a principal ...
... individuals (social entities) and orgs are principals
... and then there are lumps of software - also treated as
principals
... Would be good if the TAG looked at this... maybe recommend
keys... the user interface is the hard part
ht: It always comes back to the question of principals. These
systems founder because of the identity not being useful to you.
... That doesn't tell you whether you should accept content from
that principal.
jar: Lampson emphasizes accountability
ashok: Certs are often meaningless
<ht>
[13]http://cacm.acm.org/magazines/2009/11/48419-usable-security-how-
to-get-it/fulltext
[13]
http://cacm.acm.org/magazines/2009/11/48419-usable-security-how-to-get-it/fulltext
noah: PKI, Verisign but also PGP, Lotus Notes, integrated UI... PKI
is a low level building block
jar: Lampson article is cynical, interesting even if you don't agree
timbl: The CORS idea seems bizarre to me, isn't the web public
anyhow, why should scripts be different from other agents? - but
it's a reputation system
yves: Host X is fine for some things, but what if I don't like their
tracking system?...
dka: Let's look at the list, think about priorities
Break for 15 minutes.
<DKA> FYI - art heist blog article in NYT I was referring to
earlier: [14]http://nyti.ms/d7qjaW context: freedom of the
Internet, also privacy]
[14] http://nyti.ms/d7qjaW
Reconvening.
Agenda shuffling
HTML / XML Unification
<DKA> msg ht let me know if you think guests this afternoon will
want internet access - if so, I need their email addresses if
possible so I can get them passwords.
<DKA> hrm
noah: There've been repeated efforts on tag soup / html moving
forward.
... Raman had nominated TimBL to convene some kind of group to
tackle this problem
timbl: When Raman said the TAG was ineffective, I said what should
be done?
... I've wanted to bring the XML and HTML forks back together
... Making a client has been made more difficult, with two stacks
... re mime types, Larry has said to fix it by fixing incentives ...
... we want a culture where it's considered good to clean things up
...
... maybe we'll try and fail
... So how can we clean this up.
... E.g. maybe fix the validator, so it would say "you could do such
and such and then it would work with so and so client"
... To what extent do you move HTML toward XML, or XML toward HTML
... One end of the scale, non-nested close tags are silly, we can
just say it's not OK
... On the other hand, default namespaces seem really convenient
... thus a range of attitudes depending on feature
... Possibility of a group with representation from both
communities, people who understand issues deeply
... I've wanted to do this, but have felt there hasn't been backing.
TAG support would be helpful
<Zakim> ht, you wanted to mention the widespread use of XML
toolchains in web/document management environment
ht: Yes
<DKA> +1 to bringing together moderates rather than extremists.
<noah> I don't think moderates/extremists is the point. In fact,
most of the people in the community I think have important
perspectives. I think we need to bring together experts who
understands the needs of the communities and the details of the
technologies.
ht: I've become aware that there's a big community that has bought
into XML toolchains.
... But this doesn't count with HTML5 community because they're not
building web apps. Instead they're making documents
timbl: Example website?
ht: Many of the drivers for HTML are trying to make the browser the
application delivery platform
... The member participation in XHTML2 was from info delivery bus,
not app deliv bus (yes, this is a specious distinction)
... There's overlap but these are different communities
... We mustn't leave the XML community behind. They bought into XML,
and they get no benefit from HTML5
... They're shipping XHTML. They're uncertain about what would
happen if they moved to HTML5
<Zakim> DKA, you wanted to give a brief counter-example...
dka: When we launched VF5 portal over browser on phone, that was
based on an XML toolchain
... news, weather, horoscope - info sources don't want to build
their own mobile sites, so we say, give us XML (partner markup) and
we'll take care of it
<ht> Here's an example of an all XML toolchain-produced website,
managed using the Factonomy product I mentioned -- the site owners
(almost) never see markup, but maintain and augment the site via
form-based interfaces: [15]http://www.scottishhumanrights.com/
[15] http://www.scottishhumanrights.com/
dka: XSLT, WML, XHTML
... Now, the devices have grown up, the clients have more mature
browsers, the info providers now have skills, so portal
infrastructure may have a diminishing role
... Portal is evolving toward a directory
noah: compare AOL, Yahoo! ?
dka: Maybe this story gives a data point
... If it's easier for an intermediary to use HTML5, they're going
to gravitate toward it
timbl: A little person will get drupal ...
<timbl> .. and hope that drupal works well with mobile
<timbl> So the CMSs (open source and other) have to be\ fixed to
work with mobile.
<Zakim> ht, you wanted to present the above example
ht: SHR writes no documents, just adds, organizes. Skins and layouts
chosen from menu. The toolchain pulls both structure and content out
of database and renders it in XHTML
... javascript is used to make site look same in all browsers ...
[grumble...]
<Zakim> noah, you wanted to noodle on JSON
noah: Why was XML brought to W3C? Because hope was that it was to be
used generally on the web
... Losing to JSON et al.
<ht> HST wonders how sure you are that XML is (still) losing to JSON
-- I hear less about it than I used to, and more about ATOM
noah: the HTML5 app builders are not using XML ...
timbl: RSS, ATOM
... there's lots of XML on the web... Word ...
... issue is important to anyone who writes scripts, has to deal
with two different DOMs
<timbl> SVG, DOCX
yves: JSON has implied datatypes; XML datatypes are complex. JSON
easier, natural
... compound document is a hard problem, huge problem in XML/HTML
integration
timbl: If people are moving data around, the direction to go is to
standardize some way to map JSON to/from RDF
ht: parsing XML is faster than parsing JSON...
noah: transient effect
<timbl> ht, pointers please!!!!
ht: (that was just a footnote)
<ht> [16]http://performance.survol.fr/2008/04/json/
[16] http://performance.survol.fr/2008/04/json/
<ht>
[17]http://blogs.nitobi.com/dave/2005/09/29/javascript-benchmarking-
iv-json-revisited/
[17]
http://blogs.nitobi.com/dave/2005/09/29/javascript-benchmarking-iv-json-revisited/
<noah> JAR: Somehow reminds me of the LISP vision: universal format
for data [did I get that right?]
<noah> JAR: RDF somewhat the same
<noah> JAR: Seems there's a constant struggle around getting data
sent around in a machine processable way, and integrated with UI
stuff.
<ht> [18]http://labs.mudynamics.com/2009/05/01/json-xml-performance/
[18] http://labs.mudynamics.com/2009/05/01/json-xml-performance/
<ht> [19]http://ejohn.org/apps/jsonvxml/jsonvxml.png
[19] http://ejohn.org/apps/jsonvxml/jsonvxml.png
ht: [cleaning up html ...] validator should give positive feedback,
feedback directed to the authors ... this seems promising
... What is the benefit we're trying to achieve? What is the
motivating headline? We want to make the web (fill in blank)?
timbl: simpler, cleaner?
<ht> Whitepaper about short- and long-term benefits
timbl: benefits, motto
<ht> And then a catchphrase similar to "cool URIs don't change"
timbl: Since 2 years ago, progress on polyglot documents, important
idea & set of use cases
... Many discussions on namespaces
<ht> The survival of polyglot as a 1st-class citizen is what really
matters for the XML-tool-chain-doc-management stuff I've been
banging on about
timbl: strategy?
jar: Task force vs. working group vs. other - let's be clear
. action timbl to Create a task force on XML / HTML integration
action timbl to Create a task force on XML / HTML convergence
<trackbot> Created ACTION-437 - Create a task force on XML / HTML
convergence [on Tim Berners-Lee - due 2010-06-14].
action-437 due in one month
<trackbot> ACTION-437 Create a task force on XML / HTML convergence
due date now in one month
. RESOLVED: The TAG recommends the formation of a task force to
drive the reunification of XML and HTML
RESOLUTION: The TAG recommends the formation of a task force to
drive the reunification of XML and HTML
(passed by general acclaim)
<ht> OK, I have found the beginning of the thread about Tim's
document:
[20]http://lists.w3.org/Archives/Member/tag/2008Aug/0067.html
[20] http://lists.w3.org/Archives/Member/tag/2008Aug/0067.html
Yves will scribe this afternoon
ADJOURNED until after lunch.
<ht> [Member-only link above, sorry]
<Yves> scribenick: Yves
<scribe> scribe: Yves
Domain name persistence (workshop planning)
(round of introductions)
Helen Hockx-Yu & Kevin Ashley
ht: commonly raised issue about using http URIs for persistence is
because of possibilities of 404.
... persistence for multi hundred of years, how (owned) domain names
could achieve such persistence?
... might lead to a workshop on digital data persistence.
... there are two main lines, first one is to go to IANA for new
TLDs under new rules that deserve to live forever
... leading to more stable reference than with usual domain names
... alternate way is to allow existing domains to fall in that
category of "persistent domain"
... open question, what would be the basis for selecting/allowing
specific domains to become persistent
... also some legal issues relative to endowments
jar: question about attaching metadata to a document, more difficult
to do in an archive system than on a regular web site
... advocates for URN claiming it was more reliable, how to you
solve the URN resolving issue?
Kevin: difference between persistent of content, and persistence of
domain name
jar: there are three aspects, the data, the cataloguing aspect, the
metadata, and how to access them
... persistence, cataloguing are almost solved problems, but
automatic retrieval and update of metadata in archived records is an
unsolved issue
Helen: we start with seeds URI and crawls. We did two domain crawls
(of .uk). between the 2 crawls, more than 5% became unavailable, and
new ones emerged. Also ownership changed on some domains, with
different content.
timbl: how many domains have meaningful whois information?
Helen: the goal is not to detect who the owner is, but that it
changed
... memento project is to embed time and date dimension in http
requests, allowing you to do conneg based on time
... you can link to dated version, and the memento server would
serve the closest in time dated version of the content
... there is a plugin for firefox that adds a time slider.
timbl: so you need to add in your server a link to the memento
server of your choice
... difficulty at W3C to mementoify our content is because ACLs are
not versioned in time, so you can get content at a specific time,
but not the list of who was able to access this data
Kevin: same issue with government material
ht: there are some examples of useful software where the free
version of it is only accessible through the wayback machine
Helen: in our case, we store things in archival format, so when
people request archived copy, they may not be able to access the
content
(arc)
ht: there are different requirements. in the IETF or W3C case,
"follow your nose" means that when you get an http exchange, you can
follow blindy the set of rules, so everything you need to know is on
the web. But it all depends on http URI resolving.
... having the bits available in an archived site is good, but
having the /TR/ and RFCs available at their URIs is crucial
<Zakim> ht, you wanted to mention the meeting last Friday, and next
steps
<noah> TAG Finding on linking to alternate formats:
[21]http://www.w3.org/2001/tag/doc/alternatives-discovery.html
[21] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
ht: trade off between conneg and linkable versions. If you have
multiple versions, it is good practise to have URIs of the specific
versions, and a way to list and compare alternates
Helen: because of technology limitation archived content is not an
100% faithful copy of a website (because of active content), also
lots of producers don't want theit content archived
<ht> So, kinds of reference preservation goals. . . in archives, for
web standards (follow your nose), [what else]
Helen: like making accessible things that were removed on purpose
(like for legal reasons) on one site
<Zakim> jar, you wanted to suggest 'persistent linking'
<ht> and "interarchival reference" to the list above
<noah> Should we start thinking about the workshop?
<ht> UNESCO ICA -- International Council xxx Archives
ht: archival task is a bit similar to search engines to avoid
tarpits (automatic crawling)
... jar's issue is persistent linking and not persistent content
... need to find a direction
<ht> ISO group forming wrt Web (archive) Metrics, says Helen H-Y
(discussions on who would be interested in participating in a
workshop on persistence)
<ht> Possible attendees: DNS people (Ask TLR?), Memento designer
(Herbert van de Sompel), Internet Archive (wayback)
<ht> (different) National Library people
<ht> Ray Denenberg, Stu Weibel
<ht> JR's question: Which intervention point(s) are the most
promising?
<ht> Australian National Data Service; IIPC (International Internet
Preservation Consortium), Int'l library of Singapore (mtg at IPRES,
Vienna, September), then IIPC next May in NL
<jar> I prodded the TAG on Memenot in December:
[22]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0109.html
[22] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0109.html
<ht> , National Library of Scotland, IIPC
<noah> Henry lists things to do moving forward:
<jar> IIPC = [23]http://netpreserve.org/about/index.php
[23] http://netpreserve.org/about/index.php
ht: need a white paper to document the different use cases and
scenarios, so that we can point possible invitees to
<noah> Is the whitepaper input to or prepared with output from the
proposed workshop?
white paper as a way to ground the discussion on agreed and
understood points
Web Applications: Client-side state
<noah> ACTION-430?
<trackbot> ACTION-430 -- Ashok Malhotra to propose a plan for his
contributions to section 5: Client-side state -- due 2010-06-07 --
OPEN
<trackbot> [24]http://www.w3.org/2001/tag/group/track/actions/430
[24] http://www.w3.org/2001/tag/group/track/actions/430
[25]http://www.w3.org/2001/tag/2010/05/WebApps.html
[25] http://www.w3.org/2001/tag/2010/05/WebApps.html
<johnk> hello, this is John - is it OK for me to dial in?
<noah> Yes, great JK. We'll figure out the phone here and dial in
ASAP.
<johnk> thanks
<johnk> yes, when my phone boots up ;)
[discussion moving to security because of John's arrival]
Web Applications: Security
<noah> [26]http://www.w3.org/2001/tag/tag-weekly#WebAppsSec
[26] http://www.w3.org/2001/tag/tag-weekly#WebAppsSec
<noah> [27]http://www.w3.org/2001/tag/2010/06/01-cross-domain.html
[27] http://www.w3.org/2001/tag/2010/06/01-cross-domain.html
<noah> ACTION-240?
<trackbot> ACTION-240 -- John Kemp to read thread on RDFa, CURIEs
and profile and summarize
[28]http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html --
due 2009-03-21 -- CLOSED
[28] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html
<trackbot> [29]http://www.w3.org/2001/tag/group/track/actions/240
[29] http://www.w3.org/2001/tag/group/track/actions/240
<noah> ACTION-340?
<trackbot> ACTION-340 -- John Kemp to summarize recent discussion
around XHR and UMP -- due 2010-06-04 -- PENDINGREVIEW
<trackbot> [30]http://www.w3.org/2001/tag/group/track/actions/340
[30] http://www.w3.org/2001/tag/group/track/actions/340
[31]http://www.w3.org/2001/tag/2010/06/01-cross-domain.html
[31] http://www.w3.org/2001/tag/2010/06/01-cross-domain.html
JohnK: document updated after email feedback from the original TAG
email on the topic
... it is clear that no specification completely forbid to leak
information form one site to the other (cross-origin forgeries)
Tim: is it because it is not about all URIs and methods for
retrieving them (like script, or <img> tags)?
jar: it is considered safe to load an image or script, not sending
information
<jar> *loading* script is ok... it's honoring the script's requests
that's troublesome
ashok: if you want websites to cooperate, same origin policy will
forbid that. cors will help that while still allowing same origin
policy checks
... does cors provide solution to xsrf/clickjacking? => not
johnK: validating origin alone is not enough to decide to do the
request or not
timbl: origin is the origin of the script, the main question is how
to run script form an untrusted website
Noah: I sign on an airline site, get a cookie from that site. I
visit another site that wants to cancel my flight (attack script).
it starts with a GET request. With CORS, the cookie will go out,
potentially authenticating me, it will have extra header
... for the browser to hand or not the data to the script if it is
from the authorized list
... now, what if it is a POST (or any unsafe operation)
JohnK: for any unsafe operation there is a 'pre-flight' request
[32]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/13
24.html
[32]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html
<jar> DBAD = don't be a deputy
[33]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/at
t-0468/CORS.pdf
[33]
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0468/CORS.pdf
jar: if you reuse credentials, there will always be [potential for]
confused deputy attacks
Noah: surprising in the GET case that instead of having the server
not returning the data if not allowed, it sends back data and trust
the user-agent to do the security check on its behalf
<johnk> dka: that link is also to CORS - (see the link below the
title to /cors)
<DKA> oops :)
<DKA> I meant: [34]http://www.w3.org/TR/widgets-access/
[34] http://www.w3.org/TR/widgets-access/
jar: when you authenticate yourself, you give information to your
user-agent
ht: in a capability oriented system, there are URIs that allows to
identify compound resources that are resources+locks
<johnk> a capability URI is not only a pointer to a resource, but
the ability to use it
<johnk> ... do something to that resource
Noah: is there an guessability of capability URI?
jar: not if you don't have the credentials to use that capability
[that must be garbled]
... protection against CSRF is about unguessable tokens, in the URI
or not
ht: unguessable, but it is interceptable?
jar: in banks, they also use defense against interception
<johnk> CSRF prevention example (from my Google account register
domain HTML form):
<johnk> <input type="hidden" name="secTok" id="secTok"
<johnk> value='a06972ccb723db43c20d95985e5f17c5'/>
[35]http://www.w3.org/TR/UMP/#access-control-allow-origin-header
(about U:)
[35] http://www.w3.org/TR/UMP/#access-control-allow-origin-header
s,[36]http://www.w3.org/TR/UMP/#access-control-allow-origin-header,
37]http://www.w3.org/TR/2010/WD-UMP-20100126/#access-control-allow-o
rigin-header
[36] http://www.w3.org/TR/UMP/#access-control-allow-origin-header
<jar> oauth vs. capabilities:
[38]http://www.eros-os.org/pipermail/cap-talk/2010-June/014235.html
[38] http://www.eros-os.org/pipermail/cap-talk/2010-June/014235.html
<jar> Why we're talking about this (1) the finding that could be
read as no secrets in URIs, (2) web app security in general
<noah> Explaining a bit about OAuth vs. CORS/UMP might be
worthwhile, but I'm a little reluctant to get into doing an analysis
of the whole server-side vs. client-side data integration tradeoff.
<johnk> ok
<jar> timbl: Do we accept the idea that origins can be principals?
<jar> timbl: Consider a company that provides scripts, and is
generally trusted to do so
timbl: using domains as principals means that you trust the script
to do the right thing, be an intermediary, respect the access
controls
<jar> timbl: Hypothesis: using domains as principals counts, and
means something... that you trust the scripts to do the right thing
... to be trustworthy intermediaries, to implement some kind of
access control on behalf of others
<timbl> So in an ACL-based system, users have to be able to add
script domains to the ACLs.
johnk: how do we move forward? broad architectural isue about
security on the web. The current model is mixing user agent
authentication and server-based authentication
... so security is build on hacks over hacks
... the algorithm for user agent is sufficiently complex that is may
leave holes in the implementation
<jar> johnk: will ordinary web developers be able to do the right
thing, or will it be too complex
johnK: need to have a way to allow web developers to do the right
thing without having to think too much about it
ashok: critical to allow people to assess trust, but why is it at
the header level, and not using policy URIs?
<Zakim> noah, you wanted to ask about followup & more sessions at
this F2F
jar: it has been proposed
ADJOURNED
<johnk> ok, I'm going to drop off
<johnk> please let me know if you have any idea of dates for the
next meetings
<johnk> bye!
<johnk> thanks Yves
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [39]scribe.perl version 1.135
([40]CVS log)
$Date: 2010/06/15 12:39:36 $
[39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[40] http://dev.w3.org/cvsweb/2002/scribe/
=================================================
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Technical Architecture Group Teleconference
08 Jun 2010
[2]Agenda
[2] http://www.w3.org/2001/tag/2010/06/07-agenda
See also: [3]IRC log
[3] http://www.w3.org/2010/06/08-tagmem-irc
Attendees
Present
Dan Appelquist, Tim Berners-Lee, John Kemp (by 'phone, in
part), Yves Lafon, Ashok Malhotra, Noah Mendelsohn, Jonathan
Rees, Henry S. Thompson
John Kemp, Larry Masinter, T. V. Raman
Chair
Noah Mendelsohn
Scribe
Dan Appelquist (morning), Henry S. Thompson (afternoon)
Contents
* [4]Topics
1. [5]Content-type Override (sniffing)
2. [6]http semantics
3. [7]Client-side storage
4. [8]Web Applications: Security
_________________________________________________________
[agenda discussion]
Content-type Override (sniffing)
action-370?
<trackbot> ACTION-370 -- Henry S. Thompson to hST to send a
revised-as-amended version of
[9]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
the HTTP bis list on behalf of the TAG -- due 2010-05-17 --
PENDINGREVIEW
[9] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html
<trackbot> [10]http://www.w3.org/2001/tag/group/track/actions/370
[10] http://www.w3.org/2001/tag/group/track/actions/370
ht: Yves is one of the editors of the spec. He has suggested putting
our requested text into another section (of HTTP bis).
Yves: We have discussed with Mark. He has suggested [and it was the
consensus in HTTP bis] that it should be in the security section.
ht: I think it's the best compromise.
<Yves>
[11]http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0327
.html
[11]
http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0327.html
<noah> We are reviewing the above email, which has suggested
amendments to the TAG's proposed HTTPbis text on sniffing.
ht: [comparing yves's version to henry's version]
ht: this is better than the status quo.
... the thing that has been taken out is the idea that you shouldn't
do any kind of media type change unless you have evidence to support
the belief that the media type is mistaken.
noah: [points to "risks of sniffing" proposed text in
[12]http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0171
.html]
... text "type of the actual document" doesn't [scan]. If you have
an XML document, it is also text/plain in some sense but if you
server it as XML then you are signalling that [the receiver] should
process as XML.
[12]
http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0171.html
ht: I feel that 7.3 [Media Type Issue] in Yves's message is a
reasonable compromise.
... My feeling is that - I would be happy if we closed this issue
with the following email to the [http bis] mailing list - "thank you
for your response to our suggestion. The prose offered by Yves would
be a significant improvement. Further changes suggested by Mark
Nottingham would be [fine] but we're not worried.'
noah: I'm not so convinced.
... I'm not happy with the "may not be that of the actual document"
text. Also disinclined to close the issue.
ht: how about a response more like : "thank you for re-opening this
issue. We think the version suggested by Yves in his message of 24
March would adequately address our concerns. We're less comfortable
with the suggested addition in Mark's message of June XX because it
confuses..."
... I'm not happy that it goes in the security section because the
core question is that it overrides user intent but that's a cost I'm
willing to accept for getting the text in the document at all.
Noah: this word - "identify" - bothers me. I don't think the
content-type header identifies.
ht: Suggest another word.
Noah: I think it's about the sender's intent. If I send you
something as [e.g.] PDF, I don't want you to interpret it as
text/plain.
[some wordsmithing]
noah: ...correctly convey the intended [type] of the content...
Yves: it's worth clarifying the text.
ht: "does not reflect the intended interpretation of the content"
<noah> Sounds good to me.
Noah: ok to seek consensus on this?
Tim: What the TAG often ends up doing is coming up with phrases like
this that [can only be interpreted] with a background in Web Arch.
... I think the new text is fine.
jar: I wonder what it would be in IETF-jargon?
... the core idea in IETF is the stack - e.g. the server
automatically provides a content type which is not appropriate at
the application level.
Noah: we could say "we don't think it's appropriate to say that the
content type identifies the content" and suggest an alternative.
ht: quotes chapter and verse
noah: anyone unhappy?
... i think the right concerns have been laid out...
... I propose to put down 370... and look at other actions related
to sniffing.
... Larry has written an interesting message in relation to
ACTION-425. We could go over it...
ACTION-425?
<trackbot> ACTION-425 -- Larry Masinter to draft updated MIME
finding(s), with help from DanA, based on www-tag discussion -- due
2010-05-31 -- PENDINGREVIEW
<trackbot> [13]http://www.w3.org/2001/tag/group/track/actions/425
[13] http://www.w3.org/2001/tag/group/track/actions/425
Noah: Shall we do ACTION-387 first?
ht: should we now bring that message up and review it?
ACTION-387?
<trackbot> ACTION-387 -- Henry S. Thompson to review JK/NM's stuff
on sniffing, authoritative metadata, self-describing web, incl.
[14]http://lists.w3.org/Archives/Public/www-tag/2010Jan/0025.html --
due 2010-06-07 -- PENDINGREVIEW
[14] http://lists.w3.org/Archives/Public/www-tag/2010Jan/0025.html
<trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/387
[15] http://www.w3.org/2001/tag/group/track/actions/387
noah: The real context for this - we had a set of discussions. John
Kemp suggested some updates. I had some concerns... We could leave
this to this afternoon when John will join us.
ACTION-425?
<trackbot> ACTION-425 -- Larry Masinter to draft updated MIME
finding(s), with help from DanA, based on www-tag discussion -- due
2010-05-31 -- PENDINGREVIEW
<trackbot> [16]http://www.w3.org/2001/tag/group/track/actions/425
[16] http://www.w3.org/2001/tag/group/track/actions/425
[17]http://masinter.blogspot.com/2010/06/mime-and-web.html
[17] http://masinter.blogspot.com/2010/06/mime-and-web.html
<noah>
[18]http://lists.w3.org/Archives/Public/www-tag/2010May/0063.html
[18] http://lists.w3.org/Archives/Public/www-tag/2010May/0063.html
<noah> Mail 0063 is a draft from Larry that we will now review.
<noah> Yves says
[19]http://masinter.blogspot.com/2010/06/mime-and-web.html is the
same text, with better format. We'll review that.
[19] http://masinter.blogspot.com/2010/06/mime-and-web.html
Noah: Brings up Larry's blog entry.
[group reviewing]
tim: I really like this article.
... and I like the fact that he's passionate about cleaning things
up and has included a list of to-dos. To this is a good role model
for future TAG things.
... now the philosophical rant: there has been some misunderstanding
in semantic web contexts that the semantics of a fragment identifier
depend on mime type.
... we've been telling people to use a URI name but it also depends
on the mime type...
... so that was the confusion. Both things are true - "this [the
fragment identifier] is a name" - and when you dereference it the
MIME type [needs to be consistent].
... in the RDF spec says "if you want to know what the triples are
in this document - this is how you parse them into a set of
triples." it doesn't say "some of these URIs may include fragment
identifiers."
jar: You're right that it doesn't say that but the RDF/XML media
type registration does say that.
<Yves> [20]http://www.ietf.org/rfc/rfc3870.txt
[20] http://www.ietf.org/rfc/rfc3870.txt
jar: you run into trouble if you're using another type - e.g. RDFa.
So the HTML doc you get back from the FOAF namespace URI, it avoids
the dual use...
tim: There are two designs and an "un-design"
... design 2: you can have the same ID being used in a way so that
the human reader when they look at an abstract property they are
directed to a written description.
... design 3: "we know what we mean..."
ht: second tim's description on 2nd position. There's a sentence on
RFD-3986 which says "there's content negotiation and this notion
that the media type defines the semantics of fragment identifies"
concluding : if you use fragment identifies in context of content
negotiation it's your job to see to it that the semantics of the
fragment IDs are not incompatible with each other.
<noah> [21]http://tools.ietf.org/html/rfc3023#page-16
[21] http://tools.ietf.org/html/rfc3023#page-16
noah: I see [a potential problem] in the RDF / XML space.
... this is the spec that defines the "+xml" convention.
<ht>
[22]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
ml-03.html#naming
[22]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming
[EdNote: We were looking at the above, at least some of us some of
the time, but the most recent version is
[23]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
ml-04.html. It does not appear to differ in the areas under
discussion.]
[23]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html
noah: +xml convention spec [specifically calls out] fragment
identification. If you look at that section [in 3023 itself] it says
"not defined yet." So there is a potential train wreck coming up.
ht: You're right - this is the definitive statement - but nobody
pays attention to it.
tim: What's the solution?
ht: It's time to look at this again - it's opportune.
<Yves> [24]http://tools.ietf.org/html/rfc3870#section-3
[24] http://tools.ietf.org/html/rfc3870#section-3
Yves: Pointed to fragment identifier section of RDF media type
registation...
Noah: This doesn't resolve anything.
ht: the particular question on 3023 BIS is - it does not give any
advice.
noah: the problem is that the +xml stuff is tricky.
... there is a published rfc-3023 - to which
[25]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
ml-03.html#naming is a proposed revision...
... I would remove "fragment identification" as something that can
be [automatically] identified...
[25]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming
ht: I think - if you write in a media type registration document
e.g. for SCD+XML - if we define in the W3C spec that defines SCD,
"fragment identifier semantics is thus and overrides XML
semantics"... then that's [OK].
... you're right - the clear implication of
[26]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
ml-03.html#naming as it stands is that if you use the +xml media
type you are licensing all the interpretations of 3023bis.
... the RDF serialisation can do what it does because 3023 is
under-specified. Once this new version comes out, we've got a real
conflict.
[26]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming
noah: I think the spirit is very similar.
ht: but the letter is different.
... quotes: "if [xpointerfranework] and [xpointerelement] are
inappropriate for some XM-based media types it should not follow the
naming convention +xml"
tim: two options: A) remove stuff about frag id, leave rdf+xml; B)
leave frag ID, remove +xml from rdf
ht: I had in mind a 3rd way: unlike the other properties, fragment
identifiers can be overridden in a + spec.
... that would still require changing the spec.
noah: [seeking clarification on (A)]: "remove stuff about frag id as
part of generic processing"
tim: Yes.
noah: I may have written software that doesn't recognize RDF but
does know the +xml convention. Now that won't work for RDF+XML
[responding to Henry's 3rd way].
tim: [names Henry's proposal: "grandfather"]
ht: fragment identifier interpretation happens...
tim: In your FOAF file you can use an XSLT -
jar: If you serve it as rdf+xml it won't work in a browser - you
have to serve it as .../xml.
noah: what are our options?
jar: 4th option: figure out by context what is identified.
yves: pragmatically that's what implementations will do.
... [gives an example involving video]
tim: That should be in the spec.
... We could say "the video tag must only be used for pointing to a
video and all video mimetypes must use media fragments mime types."
... if you happen to have scalable video graphics or animated SVG as
a video then the mime types must support media fragments.
... The TAG should change the architecture document to add that
text.
noah: I'm OK with that.
yves: [on using the frag id for specifying a part of a video] if the
time-range is unknown for the media type then it is ignored.
ht: whatever happened to vertical bar? | server-side fragments?
... real question: is this what you said, Jonathan, for the 'pragma'
option: "it's OK for generic processors to process generically and
'RDF' processors to process specially."
jar: [sort of]
... so the question is: suppose through con-neg you get 2 completely
different documents? Then you'd say "that URI is not a good URI
because we don't know what it's designating."
... this is the HTTP semantics problem.
ht: if you give an XInclude processor an XML document to process and
it finds xi:include elements with href elements, it will interpret
the result as an XML document - unless you say not to.
... whereas an RDF processor goes the other direction.
noah: I'm more worried about people who run generic tools on
documents that are lying around ...
tim: xinclude - can I say "xinclude something#foo" ?
ht: yes: [No, corrected later -- XInclude forbids fragids in its
'href' attrs, and provides a separate way of designating fragments]
tim: Then this does break.
... if you use that to refer to the element tree, in an RDF document
it doesn't refer to an element tree it refers [to a concept].
noah: [calls a break] we will pick this up again tomorrow. I propose
what we do is come back to ACTION-425 when Larry can be with us.
ACTION-370 we come back to tomorrow. ACTION-387 we come to this
afternoon.
[back from break]
http semantics
jar: [presents slides at
[27]http://www.w3.org/2001/tag/2010/06/http-semantics.pdf]
... problems that I see in these discussions on "what do URIs mean /
name" etc...
... these are the sorts of questions that I'm trying to model or
address.
... didn't get as far as I wanted to get.
... not trying to "define meaning."
... trying to dispel fear and uncertainty around providing metadata
for resources on the Web.
... needs to be grounded [in operational interpretation] but not too
soon - you do it formally so what you do has broad applicability.
... [presents "http semantics landscapes: exchanges" diagram from
slides]
... this is not a class diagram.
... it's a template for diagrams involving instances.
... the point is: you can do an ontological account - a scientific
account - looking at what really happens in an HTTP exchange.
... [introducing "exchange variability" diagram] if you want to look
at patterns -
[27] http://www.w3.org/2001/tag/2010/06/http-semantics.pdf
jar: you can have 2 different request messages that contain the same
URI. They can lead to 3 different response messages... This leads to
a cascade of events. Eventually you'll have a response. The outcome
of these 3 exchanges are these 3 different representations.
... [e.g. 2 are in PDF and 1 is in HTML]
... there are some properties of the representation which are common
and some which differ.
... talking about "properties of exchanges."
... subclasses of exchanges: defined by restriction or by inclusion.
... in this modelling, we have some basic axioms already emerging -
e.g. "every exchange has a send request."
... which can be expressed in OWL...
... even with this minimal theory you can do something interesting -
e.g. dated URIs used at W3C - a resource with an interesting
property in that it only has one representation. It is possible to
model meaning to an extent.
jar: you could talk about the class of exchanges with this URI -
class of exchanges with this URI possesses this invariant.
... so classes of exchanges talking about invariance on a
representation, invariance on the exchange, ...
... you can also talk about the relation of these exchanges to the
world.
... there are ways you can specify classes not just on restrictions
on individual members - you can say "these particular members" or
"has been accessed twice" ...
... [in response to question by Ashok] the origin is specified as a
string and a port number... those would be properties of the
exchange. If you wanted you could have rule - if the exchange was on
this origin then do this... a restriction.
Ashok: It would make this more useful [to add rules]...
jar: you need a good foundation first...
... [back to slides - "subclasses of Exchange" slide 2]
... some subclasses: empirical / promise / API / constraint
tim: here we're talking about network protocols and meaning.
... there are social protocols - e.g. when somebody lies - in order
to design something in the real world you need to consider all the
possible things an "evil" person could do. Some of these cases you
don't have to worry about.
... we need to distinguish between modelling how things are supposed
to work and what happens when they don't work.
jar: this gives a start...
...
tim: what's interesting to me - what the TAG says is a meta-level
promise. If "people behave" the TAG will promise that the server
will never complain that people have accused them of saying
something they didn't say...
[brief toilet-roll discussion]
jar: [back, thankfully, to the slides]
... you can say : all the exchanges I've observed are members of the
following class...
ht: is the following claim a claim you want to make: 2 exchanges
that differ in ways which are not captured by these classes are
actually not different in any interesting way?
jar: is that a definition of interesting or a consequence of
interesting?
ht: definition, I guess.
tim: [gives example of how ethernet cable gives a promise of
containing ethernet packets]
jar: hypotheses - take e.g. dublin core metadata - if you make an
assertion that something has this dc:title, etc... there are
different ways to interpret that but one way to interpret is that
the representation will satisfy those dublin core properties.
yves: when you have a promise - that somebody made the assumption
that something will happen - there is a link to time - during this
time X the promise might change...
jar: promises might go bad.
... the time at which it happened is a property of an exchange.
... last subclass of exchange: induced.
... if you're a librarian or a scientist, what you're interested in
talking about is content, data, measurements, ...
... e.g. a telescope is an example of an "induced" resource.
... [more on induced exchange classes]
... maybe for each kind of thing that you want to allow 200
responses for you state [what happens].
tim: this is why it's important to model the semantic web stuff.
jar: the question of "what is an information resource" is a
rat-hole. The interesting question is what classes of exchange are
appropriate to this information resource? And if the answer is
"none" then [maybe?] it's not an information resource.
ht: what kinds of differences between representations would be
allowed for representations of the same resource?
jar: suppose i want a class of "news sites"? I can do that. but if I
were to do that with something that today provides news but tomorrow
is frozen in time then tomorrow it wouldn't be news.
yves: the news site is a good example. If you do a get on
newssite.com/latestnews then you get back something with a
timestamp...
ht: brian smith wrote "semantics of clocks" article - [jar] said you
could say "an internet clock is a good internet clock if the time
represented by the relevant string in the response is within some
epsilon of the time of the response." you could say something
parallel about news sites...
DKA: Can you define art?
<ht> Scots law requires that responses to offers of oral contracts
must be "timeous" for the contract to be binding
jar: I wanted to touch on validators as a possible application. Web
architecture validators. A Link http header could be way to
communicate promises. Even if you're the one making the promise you
might want to self-monitor with a validator.
... [digression] a promise is a speech act and it has parts.
... we now have 10 active metadata ontologies - e.g. "on this web
page there is a mention of this gene" if they use the URI as the
subject of that statement then they are worried it might change, the
con-neg might go wrong, etc...
... their fear is that they won't be understood.
... what is acceptable to this audience now is things like web
citation - "from this URI I got the following stuff or some stuff
with these properties at this date..."
... the link header might give some assurance - if it says "this is
stable content" - they would have more assurance to be able to use
that URI as a subject.
tim: so "persistence commons"
... w3c has a draft persistence policy...
yves: they don't want to use the URI because it might change...
ht: there isn't a transparent way to write a URI which is
recognisably a reference to a published journal article.
jar: you can say "info:doi/" - [with some caveats]
ht: [+1 to the idea of a validator]
noah: wrap for lunch?
<jar>[A location detection service:
[28]http://npdoty.name/location/]
[28] http://npdoty.name/location/
[Resume after lunch]
Client-side storage
AM: [29]http://www.w3.org/2001/tag/2010/05/WebApps.html
[29] http://www.w3.org/2001/tag/2010/05/WebApps.html
[AM speaks to the doc't, not scribed]
<noah> NM: Is this an API spec?
<noah> [30]http://www.w3.org/TR/2009/WD-webstorage-20091222/
[30] http://www.w3.org/TR/2009/WD-webstorage-20091222/
AM: Yes
NM: In this design, the javascript gets the data and can do what it
wants, but the browser doesn't do anything automatically (c.f.
cookies)
AM: Yes
... Name-value pairs
JR: 1970s-era file system
AM: Maybe name-value pairs plus indices
NM: What is index good for that names can't do?
AM: More like a database
Google Gears was there
scribe: with SQL-like access
... but not typed
... WebSQL was based on [a particular] product
<DKA> Web SQL: [31]http://dev.w3.org/html5/webdatabase/
[31] http://dev.w3.org/html5/webdatabase/
AM: Hasn't progressed because there is only one (proprietary)
implementation
... But it looks like the indexed API is going ahead
... More efficient than simple name-value
<DKA> The note from the Web SQL spec: This specification has reached
an impasse: all interested implementors have used the same SQL
backend (Sqlite), but we need multiple independent implementations
to proceed along a standardisation path. Until another implementor
is interested in implementing this spec, the description of the SQL
dialect has been left as simply a reference to Sqlite, which isn't
acceptable for a standard. Should you be an implementor interested
in imp
<DKA> ... contact the editor so that he can write a specification
for the dialect, thus allowing this specification to move forward."
JR: You don't need CORS . . .
[scribe lost]
NM: App has javascript from A, tries to get stockquote from B, not
possible w/o CORS
... Same thing applies once we have local storage -- JS from A wants
stored information originating from B
TBL: Suppose we had a consistent access-control ontology
... with people, and sites, and origins
... and reconstruct something similar to CORS, but more general
<DKA> [32]http://dev.w3.org/html5/webstorage/#privacy seems
problematic to me - full of MAY clauses...
[32] http://dev.w3.org/html5/webstorage/#privacy
<timbl> yes.
<timbl> "User agents may, if so configured by the user,
automatically delete stored data after a period of time." or
configure by the (eg) bank.
AM: Agreed
NM: How do we follow up on this?
AM: It's possible that the 'may' is opening the door for something
like CORS
<timbl> "User agents may allow sites to access session storage areas
in an unrestricted manner, but require the user to authorize access
to local storage areas." -- that is the user expressing trust in a
set of code - that is equivalent to software instalation
DKA: [Eudora example]
TBL: You have a local IMAP cache
... some clients expose the cache in IMAP format
NM: what about a better GMail searcher, which would need special
permissions to get at the GMail cache
TBL: Facebook is using web storage, and LinkedIn offers better
functionality if you allow it in
DKA: I want to build that using OAuth
NM: But it won't work offline
DKA: Yes it will, it will keep working on my behalf [between the
two, w/o my participation]
TBL: That's going all the way down the road to trusting big services
... I'd like to be able to run my IMAP client offline
DKA: But now a polluted website can inject a script which can
harvest my email
TBL: There's no such thing as a little bit trusting
NM: Distribution is a complex issue
... This whole thing also breaks down because the storage stuff
isn't integrated into our access model
... Compare this to the way caches work
... where we do have names
... The web storage model has no names in that sense, and no
RESTfulness
... So the existing access control mechanisms may well not
generalize
DKA: Always assumed this was just an optimization
JR: These things always start small and market forces drive towards
more functionality
<timbl> Possible recommenders of trust in scrupts: 1) The user 2)
The writer of another script (which created some data) 3) a third
party registry like the addons.mozilla.org or iTunes AppStore
HST: I had the experience of using earlier versions of some of this
... and it was all same-origin protected -- every access had a
URI-prefix which was SO checked and which constrained subsequent
access
HST: Looking briefly at the WD-webstorage-20091222, that appears to
be still true
... The session store vs. local store difference matters
... Not clear exactly what patterns of access are allowed . . .
YL: This is all similar to what happens wrt information in local
HTTP cache -- the browsers know where data comes from, even if it
comes from cache
<timbl> Yves discusses provenance tracking at the javascript
language level
YL: So you could require annotation of data with its origin
JR: But this will still be vulnerable to CSRF
TBL: A lot of semweb are going in the direction of annotation of all
triples with provenence info -- triples are becoming quads
... And feeding into reason maintenance systems so conclusions can
be quickly withdrawn if premises are compromised
ACTION Ashok to comment to web storage guys: basically all of this
is origin-based, but section 6.1 has a 'may' -- is this a door being
held open for CORS?
<trackbot> Created ACTION-438 - Comment to web storage guys:
basically all of this is origin-based, but section 6.1 has a 'may'
-- is this a door being held open for CORS? [on Ashok Malhotra - due
2010-06-15].
NM: Concerned we need a plan of how to feed this into our overall
WebApps story
AM: Work towards some bullet points?
TBL: Propose "Storage structure and access control should be
considered separately"
<Zakim> timbl, you wanted to ask JAR what easier way of doing this
was
TBL: JR, how do we do this?
JR: How do we avoid confused deputy attacked? Where a deputy gets
too much power, and does more than it was intended to be allowed to
do
<noah> The chair infers that the group would like to continue
technical discussion.
JR: The way to do this is to pull the authorization as far forward
as possible, by recording who/what/when is authorized
... instead of saying there was a point at which they were
authorized to do everything
TBL: You have to have a way of specifying what is allowed -- is that
code?
JR: Could be
TBL: Two ways -- characteristic function, or name, for what they are
going to do, in order to authorize up front
JR: You have a description of what they want to do, it's to call
some function with some args
... The pblm with CORS is that it just controls access to particular
API, as it were
... Whereas e.g. with Kerberos the authorization act includes what
it is you can do with the authorization
... Whereas with a login-based mechanism, you get authorization to
"be" a particular user, and all kinds of things come from that
[scribe missed a bit]
<timbl> jar: This (login is much too high granularity
JR: In Javascript this is easy, the auth. decision is an object,
which encapsulates the capability to do the action . . .
JR: Adam Barth says this isn't yet viable, because it depends on
secure ECMAScript, but there's a lot of ordinary Javascript still
around
AM: Who are we aiming this at?
NM: As per WebArch, not the authors of HTTP, but the smart user
population looking for guidance as to how to use it
... So to describe a stable architecture which shows how the specs
fit together
... Which may as a by-product help the authors of the specs that are
still under construction
<jar> Adam has done some cool work making origin-based authorization
decisions work as well as they can in javascript
AM: I had started with the understanding that there were two goals:
session storage and persistent storage. Now I see we need to add a
third: [controlled] cross-site access.
JR: What's needed is a narrative, not a design
DKA: Possible kinds of actions: We could try to intervene in the
progress of the Web Storage spec. What kind of proposal could we
point them towards?
NM: Implementations shipped already, or not?
AM: Not even in last call
NM: No, I meant the code
TBL: I'd be surprised if it was baked
HST: But Mozilla shipped with something close to this at least a
year ago
DKA: I will try to find out
JR: Adam Barth is trying to write an RFC on how to use cookies
securely
<jar>
[33]http://www.eros-os.org/pipermail/cap-talk/2010-February/013753.h
tml
[33]
http://www.eros-os.org/pipermail/cap-talk/2010-February/013753.html
NM: We could say something from the TAG on client-side storage which
didn't get into the deep security pblms
<johnk> hi, I'm on the call now
<noah> Ashok will prepare input to discuss on the telcon on the 17th
(if we have one)
<noah> ***BREAK***
Web Applications: Security
NM: Goal is to have a better idea of whether there's serious writing
to be done
... what next steps if not writing
AM: If you want sites to cooperate, is CORS/UMP/OAuth/What the way
to do it?
NM: What is your opinion, if you have one --- anyone?
AM: I don't know yet
JR: Hard to answer, because I've been in the capability camp for so
long
... So if I were designing an app, I would take whatever mechanism I
could find that would let me layer capabilities on top
NM: But the web community is going to make a call. . .
JR: I don't think CORS will scale
NM: What about UMP?
JR: Yes, I think it has the right properties -- from an engineering
perspective
<johnk> +1 to Jonathan
<johnk> agree that UMP is better from architectural perspective
JR: I see you could need some more structure on top, to match web
needs . . . there would be a certain amount of re-invention of the
wheel for the next level, for instance wrt UI
AM: I still need to think about it, read the specs again
DKA: I'm more familiar with the CORS approach, I also know OAuth,
which I think is sometimes the right response
... It's a well-used bit of web arch.
... I think the widgets digital signature stuff could also be useful
... Similar to CORS, but based on signatures, not origin
NM: How is this an access-control mechanism
<DKA> [34]http://www.w3.org/TR/widgets-access/
[34] http://www.w3.org/TR/widgets-access/
DKA: Here's the spec:
The doc't is specific to widgets, but it could be extended to docs
as well
ACTION Appelquist to introduce signature-based approaches to access
control
<trackbot> Created ACTION-439 - Introduce signature-based approaches
to access control [on Daniel Appelquist - due 2010-06-15].
YL: I don't think CORS is the ultimate solution to WebApp security
-- UMP is much simpler. People understand Same Origin, CORS is hard
to make sense of, where UMP is simpler
... It provides what people mostly need, which is cooperation
between two sites
... Much better way in for devs who are not seriously engaged with
security issues
HST: So, is Kerberos a capability-based system?
JR: Like capability, in that you get an unguessable token, but it's
still a capability just to be a particular person
... But it illustrates that the outcome of login can be an object
<johnk> OAuth is the new Kerberos, roughly-speaking
<johnk> SAML was the new Kerberos, before OAuth
HST: So I get that's it's not a clean distinction. . .
<noah> Possibly pertinent Kerberos RFC
[35]http://www.ietf.org/rfc/rfc1510.txt
[35] http://www.ietf.org/rfc/rfc1510.txt
<noah> Wikipedia simplified description of Kerberos protocol:
[36]http://simple.wikipedia.org/wiki/Kerberos_%28protocol%29#Simplif
ied_description_of_the_protocol
[36]
http://simple.wikipedia.org/wiki/Kerberos_%28protocol%29#Simplified_description_of_the_protocol
HST:I've recently started using the MarkLogic XQuery + XML datastore
system. It uses a very fine-grained inventory of permissions, down
to the individual function level, as well as distinguishing read,
add and change permissions on the datastore, but it still assigns
sets of those to user groups, and so depends on user authentication
== ambient authority
HST: Having said all that, +1 to finding, articulating and selling a
capability-based story
NM: Not sure I have the grounding to make an informed judgement
... The concerns I hear about CORS come from impressive sources, and
I think I hear good things about UMP, as far as it goes
... In particular, I don't see how UMP extends to cookie
functionality, which seems to be what people really need
... WRT capabilities, my early experience was not good, so I will
need to be convinced in practice we can make it work
<noah> Not quite what I said: capability systems are very cool and
can work well, but they tend to be somewhat difficult to implement
and roll out. So, I want to see something that the community will
accept as practical. Maybe or maybe not something like WebKeys
signals a direction. I just don't want to gamble on some unseen
capability system working until we've seen early versions getting
traction on the Web.
AM: JR pointed out that Javascript does not have encapsulation --
without that, how can you do capabilities
JR: By adding features to the language -- that's what SES (Secure
ECMAScript) does
JR: UMP is capabililties at the protocol level, that's not the same
as capabilities in the programming environment, we need both
<jar> Too many features -> too much access -> loss of encapsulation.
Javascript. Remove features -> can't access stuff you shouldn't be
able to get -> recovery of encapsulation. Secure Javascript.
JK: Based on experience and reading the specs, I think the
origin-based approach we have to security today needs to be fixed,
CORS is not going to do it, and UMP looks like it will
... But I also note that the in-practice approach people have taken
to protecting against CSRF and click-jacking amounts to something
very close to capabilities in practice
JK: Fixing origin-based by hacking pseudo-capabilities on top of
other hacks seems doomed, something cleaner from the ground up
should be preferred
<noah> John's framing resonates for me: a key question is whether
the permission token is integrated with or separate from the
identifier. The latter approach is, more or less capabilities.
TBL: Is this a research-grade problem, or is it really ready? The
extra stuff you, JR, said was needed?
JR: There is Waterken, which is built on top of UMP using web keys,
which is a commercial product from Tyler Close
<jar> [37]http://waterken.sourceforge.net/
[37] http://waterken.sourceforge.net/
JR: Note that UMP does not imply Web Key
<Zakim> jar, you wanted to briefly note that use of UMP does not
require use of unguessable secret URIs. you can put the CSRF token
in a parameter i.e. elsewhere in the request e.g. in
JR: Using UMP for CSRF protection is isomorphic to what people are
doing today, for example using hidden POST parameters
... containing a nonce
<johnk> yes exactly
JR: UMP extends this existing story wrt e.g. click-jacking, w/o any
javascript, into general javascript usage
ht:I have a PhD studnet, Alex Milowski, who has been looking at
capability-based security for distributed computation with
semi-trusted actors. A simplified example is the 'The triangle
architecture'
Think of SETI at home... hierarchical decomposition
suppose a URI names a part of a decomposition of a probem
Diagram description: Henry shows a central coordination node sending
http interactions to a farm of worker nodes.
ht: but the GET has to be done asynchronously, the results may take
days or weeks to compute.
<noah> He described it as peer-to-peer, but the diagram is a
one-level tree.
ht: triangle architecture: I will give URI to each work for use in
delivering answer, as well as the question
... so I have an S3 account... I want you to do a computation... and
put the answer there (on my nickel)
OAUTH doesn't work here. Too much authority granted
timbl: OAUTH is designed to do that
noah: SAML too?
ht: we're just starting to understand the options here
<noah> SAML = Security assertions markup language
ht: so we want a capability to store the result. time, location and
scale limited.
<noah> Not sure, but XACML may be pertinent too (see:
[38]http://www.oasis-open.org/committees/xacml/ )
[38] http://www.oasis-open.org/committees/xacml/
<noah> Wikipedia on XACML [39]http://en.wikipedia.org/wiki/XACML
[39] http://en.wikipedia.org/wiki/XACML
ht: We know S3 doesn't have this ability today, but we can build a
gateway to S3 that does...
... Capability seems the simplest way to talk about this.
noah: I'd recommend you look at ACL-based approaches
AM: I don't thing XACML is capability-like
... I think it's about access control
NM: I think it's a bit more fine-grained. . .
DKA: What's also relevant is that we have browser and server as
actors
... which makes me look to OAuth, rather than XACML which would set
a very high bar
<johnk> XACML is a language for representing access control policies
<johnk> SAML is a language for making assertions about a "security
principal"
NM: I find the Web Services approach awkward, but it is driven by
use cases similar to the one just offered
... such as long response times
JR: We're not in an either-or situation altogether -- based on
time-scale, for example, capabilities are designed for time-bounded,
seconds, days or weeks, whereas ACLs are more 'permanent'
TBL: Capabilities have completely different properties depending on
whether they can be copied or faked
JR: If you're cooperating over a secure connection, no third party
can get the capability
HST: But you don't necessarily trust the person you send the
capability to
... E.g. in the triangle architecture
TBL: You may assume everyone is reliably identified, so you can
grant a capability only to me
JR: Signing things is only necessary if they can be interpreted
<jar> HT's example is interesting because it's ok if the capability
is leaked. doesn't protect anything that matters much
<Zakim> noah, you wanted to talk about tokens integrated with or not
integrated with the identifier
TBL: MiM could get the capability and immediately use it
HST: Not if the real actor's public key was in the capability
request
JR: Or if the connection is encrypted
NM: JK said something really interesting: comparing a token in a
POST header with a capability expressed in a URI
... but slightly different, in that the coupling between the
identifier and the capability is different, not by much, but
different
... which reminded me of my concerns about web key
... Since a link is a capability, I have to be careful to send my
URIs carefully, i.e. using HTTPS
... But we've also added a post facto requirement for people to
protect their caches, logs, ....
... Maybe there's existing advice which forestalls this, but it runs
against part of our story about making the Web work: share links,
etc.
... Makes me nervous to be sure we've spotted all the places that
have to be secured to guarantee that URI-embedded capabilities can't
leak
JR: Just remember that UMP isn't committed to web key
NM: yes, understood
JR: There's always a credential -- it's got to be communicated, and
it has to be protected
... currently, it's distributed among cookies, ssl keys, IP
addresses
... It's always in the response
... And that's not going to change
NM: Yes, but my comment was that putting the secret in URIs entrains
a huge history of what browsers and other tools do with URIs
... and that history is very different in impact from the parallel
history wrt e.g. cookies
JR: It's a question of what Javascript you write.
NM: I thought there was a crucial difference between UMP and
XMLHttpRequest wrt cookies -- XMLHttpRequest automatically attaches
my cookies for site X to any request to site X
... UMP doesn't
HT: If I do use URI-encoded capabilities, and do what I described in
my example, with a GET over HTTPs, but my Apache server logs every
URI, the log file, albeit restricted to root, contains the
capability and goes to all my sysadmins. I don't want that.
JAR: Yes, if not used with something else like a login.
<noah> [40]http://www.w3.org/2001/tag/tag-weekly#WebAppsSec
[40] http://www.w3.org/2001/tag/tag-weekly#WebAppsSec
HST: So NM's point is simply that expectations about for example
privacy vary wrt existing bits of Web Arch, e.g. URI vs. header
JR: Right. Nothing to do with UMP?
NM: Right.
... JK, what about ACTION-340?
JK: I think that's done
<noah> ACTION-340?
<trackbot> ACTION-340 -- John Kemp to summarize recent discussion
around XHR and UMP -- due 2010-06-04 -- PENDINGREVIEW
<trackbot> [41]http://www.w3.org/2001/tag/group/track/actions/340
[41] http://www.w3.org/2001/tag/group/track/actions/340
<noah> close ACTION-340
<trackbot> ACTION-340 summarize recent discussion around XHR and UMP
closed
<noah> ACTION-417 Due 2010-07-13
<trackbot> ACTION-417 Frame section 7, security due date now
2010-07-13
<noah> ACTION-435?
<trackbot> ACTION-435 -- Jonathan Rees to consult Tyler Close
regarding UMP-informed web storage vulnerability analysis -- due
2010-06-15 -- OPEN
<trackbot> [42]http://www.w3.org/2001/tag/group/track/actions/435
[42] http://www.w3.org/2001/tag/group/track/actions/435
<noah> ACTION-435 has been bumped to 15 June
<noah> ACTION-280?
<trackbot> ACTION-280 -- John Kemp to (with John K) to enumerate
some CSRF scenarios discussed in Jun in Cambridge -- due 2010-07-06
-- OPEN
<trackbot> [43]http://www.w3.org/2001/tag/group/track/actions/280
[43] http://www.w3.org/2001/tag/group/track/actions/280
<noah> We just moved ACTION-280 from Dan to John, and made date in
early July.
ACTION-33 due 2010-07-15
<trackbot> ACTION-33 revise naming challenges story in response to
Dec 2008 F2F discussion due date now 2010-07-15
<noah> ACTION-344?
<trackbot> ACTION-344 -- Jonathan Rees to alert TAG chair when CORS
and/or UMP goes to LC -- due 2010-06-10 -- OPEN
<trackbot> [44]http://www.w3.org/2001/tag/group/track/actions/344
[44] http://www.w3.org/2001/tag/group/track/actions/344
<noah> JAR: I want text of action to record why I'm doing this. I
think it's so we can do a review of their Last Call regarding
security considerations.
<noah> close ACTION-412
<trackbot> ACTION-412 Try the clarification question, blog item, or
wiki approach to metadata-in-uris vs CSRF closed
_________________________________________________________
Minutes formatted by David Booth's [45]scribe.perl version 1.134
([46]CVS log)
$Date: 2010/06/10 09:50:51 $
[45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[46] http://dev.w3.org/cvsweb/2002/scribe/
=================================================
[1]W3C
[1] http://www.w3.org/
Technical Architecture Group - f2f minutes - 9 June 2009
09 Jun 2010
See also: [2]Agenda, [3]IRC log
[2] http://www.w3.org/2001/tag/2010/06/07-agenda
[3] http://www.w3.org/2010/06/09-tagmem-irc
Attendees
Present
Henry Thompson, Noah Mendelsohn, Jonathan Rees, Ashok
Malhotra, Dan Appelquist, Tim Berners-Lee, Yves Lafon
Regrets
Larry Masinter, John Kemp, T. V. Raman
Chair
Noah Mendelsohn
Scribe
Dan Appelquist, Ashok Malhotra
Contents
* [4]Topics
1. [5]HTML / XML Unification
2. [6]Content-type override (ACTION-370 revisited)
3. [7]Fragment ID semantics and XML Media types (continued)
4. [8]Web Applications: Identification and URIs
5. [9]Review Pending Actions
6. [10]Overdue actions
* [11]Summary of Action Items
_________________________________________________________
<trackbot> Date: 09 June 2010
<DKA> ScribeNick: DKA
HTML / XML Unification
Noah: [going back to our discussion yesterday on RFC-3023.]
... What is the follow-up / action?
Yves: I can do it.
Tim: The "grandfathering" option [wasn't a good one]. It's possible
we can eliminate one of the other options.
Yves: Should we contact Chris? Nail down what the issue is first?
Noah: To be picked later at 11:15.
... We had a discussion on day 1 on HTML-XML reunification. Let's
come back to it.
<Yves> (for the minutes, yesterday's white board
[12]http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg )
[12] http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg
[Discussing
[13]http://lists.w3.org/Archives/Member/tag/2010Jun/0011.html]
[13] http://lists.w3.org/Archives/Member/tag/2010Jun/0011.html
ht: this is in reference to HTML wg issue 41.
<noah> ACTION-427?
<trackbot> ACTION-427 -- John Kemp to read 4 distributed
extensibility proposals and summarize them w.r.t. proposals TAG has
discussed to date -- due 2010-06-06 -- OPEN
<trackbot> [14]http://www.w3.org/2001/tag/group/track/actions/427
[14] http://www.w3.org/2001/tag/group/track/actions/427
ht: interesting thread - subject "facebook have started facebook
namespace declaration to connect web pages to facebook"
... the assertion is that there are thousands to millions of html
pages with namespace declarations in them (other than the XHTML
namespace).
noah: David R from Facebook presented on this at WWW. Said: we don't
think people will get namespaces right.
... also, this is in service to RDFa. So resolution to Qnames isn't
happening.
tim: so facebook are using RDFa.
ht: with the binding for the curie.
... what's crucial is that the namespace binding be in the DOM.
tim: for people doing interesting things with RDFa in scripts it's
important. for Facebook maybe not.
ht: there seems to be a fair consensus that what this points towards
- what we need is to ensure that these namespace bindings are in the
DOM - therefore they're available for the parser element names and
attribute names (and for javascript to do the same)
tim: actually - james clark's [XML parser] strips the namespace
bindings out.
<ht> HST contests TBL's assertion
ht: it illuminates sentiment in the [html] working group. There's a
sense of "don't break the Web" - now there are all these pages that
are using namespace bindings. That's relevant info for discussion of
[html] issue 41.
noah: how is that going past www2010?
ht: hasn't come back up again. not currently on the front burner.
... the fact that Facebook did their design the way they did is
relevant.
action-427?
<trackbot> ACTION-427 -- John Kemp to read 4 distributed
extensibility proposals and summarize them w.r.t. proposals TAG has
discussed to date -- due 2010-06-06 -- OPEN
<trackbot> [15]http://www.w3.org/2001/tag/group/track/actions/427
[15] http://www.w3.org/2001/tag/group/track/actions/427
ht: html wg issue 41 is open - not currently being discussed. we
could take the initiative and put forward our preferred proposal.
... the most committed pushback from HTML wg is in the area of the
DOM API.
... it comes back to polyglot documents - ref HTML authoring
guidelines draft of 27 may 2010.
<noah> HTML Working Group draft on HTML/XHTML Compatibility
Authoring Guidelines
<noah>
[16]http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-autho
ring-guide.html
[16]
http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html
ht: is there a succinct discussion of what the XML spec requires of
a conformant XML processor and what the HTML spec requires of an
XML-mode processor?
... seems this spec does call for a conformant XML parser. So it's
behaving like what the XML spec calls an application.
noah: intent [of this document] is to talk about XML as
conventionally processed. it's about writing HTML which is
processable as XML.
yves: if you have an SVG tag in the DOM do you have the namespace?
tim: when SVG is parsed it's given the SVG namespace int he DOM.
<noah> I like the document a lot. I can't necessarily say that the
details are right, but the tone and structure seems to me to be very
effective, and I assume most of the details are right.
<ht>
[17]http://dev.w3.org/html5/spec/the-xhtml-syntax.html#parsing-xhtml
-documents
[17]
http://dev.w3.org/html5/spec/the-xhtml-syntax.html#parsing-xhtml-documents
[Discussion on what this means...]
<scribe> ACTION: Henry to ask Hixie what is meant in this [section
9.2] by "retrieving an external entity" and could some clarification
be added. [recorded in
[18]http://www.w3.org/2010/06/09-tagmem-minutes.html#action01]
[18] http://www.w3.org/2010/06/09-tagmem-minutes.html#action01
<trackbot> Created ACTION-440 - Ask Hixie what is meant in this
[section 9.2] by "retrieving an external entity" and could some
clarification be added. [on Henry S. Thompson - due 2010-06-16].
<noah> We took a few minutes to unravel the data: URI in section 9.2
of the HTML 5 draft and verified that it encodes entity definitions
of the form:
<noah> <!ENTITY Tab "	">
<noah> <!ENTITY NewLine "
">
<noah> <!ENTITY excl "!">
<noah> <!ENTITY quot """>
<noah> <!ENTITY QUOT """>
ht: we need to get clear just how close the DOMs are - suppose I
follow the polyglot recommendation. Is it really true that the DOMs
are the same regardless of which way it gets processed?
noah: there are 3 styles of DOM we might be concerned with. the XML
DOM you'd get with Xerxes with no reference to HTML5 spec. At the
other extreme is the DOM you'd get if you served it as text/html...
ht: phrase that's in the spec: 2 sets of rules for processing html
documents: one set for html, one set for xhtml documents.
noah: potentially there are 3 DOMs... stack of XML spec+ the DOM
spec; HTML5 HTML DOM; HTML5 XHTML DOM
... are these three distinct in terms of what they build?
... I assume that [polyglot spec] is talking about the latter two
modes.
ht: indeed
... quotes html5 doc...
<Yves>
[19]http://www.secrets2moteurs.com/exalead-rachete-par-dassault-syst
emes.html
[19]
http://www.secrets2moteurs.com/exalead-rachete-par-dassault-systemes.html
<Yves>
s,[20]http://www.secrets2moteurs.com/exalead-rachete-par-dassault-sy
stemes.html,,
[20]
http://www.secrets2moteurs.com/exalead-rachete-par-dassault-systemes.html
<noah> So, my feeling is there are a few use cases here.
<noah> The compatibility document correctly points out that one use
case is to use generic XML tools, and that's indeed important.
<noah> Nonetheless, when we talk about polyglot, our fundamental
concern is that there be compatibility when the same bits are served
>to HTML5 processors< in two diffent modes: 1) as text/html and 2)
as application/xhtml+xml.
<noah> It's also nice if the DOMs built by other XML tools are
similar, but those tools won't do things like scripting, so are
ultimately a different use case.
Yves: in html4 there was a difference in expectation (when served as
HTML or XHTML) about character sets...
<timbl> Abstract:
<timbl> A polyglot document is one which is at the same time an XML
document and an HTML5, and meets well defined set of constraints.
Polyglot documents are those which use a specific doctype, namespace
declarations, and a specific case, normally lower case but
occasionally camel case, for element and attribute names. They use
lower case for certain attribute values. Further constraints include
thos eon empty elements, names entity references, and to the use of
scripts
<timbl> style. Polyglot documents meeting these constraints may be
interpreted equally well as XML or as HTML5.
ht: [points to special parsing rules for mathml elements]
... [and SVG cases]
... there is a whole bunch of work done for known names in SVG and
MATHML namespaces which are camel case. There are specific
exceptions in HTML5 for this...
[discussion on how to move forward]
<timbl> That above is what I think of as an abstract. The text for
te abstract they have at the moment is a SOTD para
<timbl> .
<ht> Turns out it is a parse error in HTML parsing mode if you start
an element with _anything_ other than a-zA-Z !
<ht> And case-folding operates all and only on A-Z --> a-z
jar: what should our internal message be regarding namespaces? What
seems to be getting lost in arguments is connection between specific
situations and high-level goals TAG and W3C is trying to promote.
E.g. self-dscribing Web.
... I'm worried about losing track of requirements as we make
choices about what technical approach to take.
noah: one thing you didn't mention is distributed extensibility...
jar: same as "nose-following" story...
noah: I think there's a fundamental disagreement in the community on
high-level goals around distributed extensibility.
jar: I think that is part of the nose-following story...
noah: when you raise with languages and systems a question of who
gets to write new specs and who gets to extend them... that's
important.
... members of the community have different views of the importance
of allowing distributed innovation.
... if [we] could bring together a group of people who could show
how [distributed extensibility] can be done that could be useful.
tim: namespaces and distributed extensibility are linked... [in
people's minds]
<ht> Fundamental fact [assertion]: 'the' DOM is a misnomer: A DOM
instance has to 'know' whether it is an XML DOM or an HTML DOM,
because the DOM spec. says, wrt string comparisons, that for the
former name comparison is case-sensitive, while for the latter it is
case-insensitive
jar: even URI based distributed extensibility is based on
registries, the domain name registry...
... what I would like someone to do is what I've been trying to do
with persistence. Try to lay out and compare all the different
solutions so we can compare them on criteria whose meaning we agree
on.
<ht> "Document objects are assumed to be XML documents unless they
are flagged as being HTML documents when they are created. Whether a
document is an HTML document or an XML document affects the behavior
of certain APIs and the case-sensitivity of some selectors."
[discussion around white board image from December '09 Cambridge
meeting - table of different proposals...]
<ht> Should be
[21]http://www.w3.org/2001/tag/2009/12/10-tagmem-minutes.html
[21] http://www.w3.org/2001/tag/2009/12/10-tagmem-minutes.html
jar: would like to [frame the question] as "what do you have to do
in order to extend the language"? Operationally.
... we ought to be able to lift up the analysis a level to get more
engagement.
ht: practical advantage of this approach is that it doesn't start
with a discussion of syntax.
tim: introducing indirect namespace could be a way of decoupling
these things.
<noah> Hi Larry, hoping you're feeling better
<noah> We're about to take a break.
<masinter> yes, better today
<masinter> thanks
<noah> You should know that your media type writeup got a very
favorable reception, and we're putting off further discussion of it
until you could join us on a telcon
<noah> Speaking of which, I will shortly be asking TAG members to
send hints on which weeks the are/are not/might not be available for
summer telcons, so if you have a chance to email that it would be
helpful.
<noah> Take care.
+1 to jar's comments on describing things operationally.
<masinter> great, i was glad it was helpful. I also got some
positive feedback from Ned Freed, with some suggestions on how to
move foreward fixing up MIME type registry and other things within
IETF
<noah> Thank you so much for doing it.
<masinter> and Graham Klyne, who I believe is current MIME
registration "Expert" reviewer
<ht> ACTION-437?
<trackbot> ACTION-437 -- Tim Berners-Lee to create a task force on
XML / HTML convergence -- due 2010-06-14 -- OPEN
<trackbot> [22]http://www.w3.org/2001/tag/group/track/actions/437
[22] http://www.w3.org/2001/tag/group/track/actions/437
tim: I think [the polyglot spec] should be normative.
noah: Could someone take an action to draft a response for our
review? Then tim review.
tim: it should be written as a subset of documents. it shouldn't be
called guidelines. like a profile of a language.
jar: I agree.
ht: I agree
noah: I read it and liked it. If I were writing html documents, this
is what I'd want.
... eg it had good guidelines in it - good practical advice.
tim: in some cases they don't give this information - they don't
explain why.
noah: points to notes on use of CDATA in polyglot spec.
... yes, you can define a set of documents but the set of documents
you choose might depend on the outcome - identical DOMs, mostly
identical, etc...
... can anyone take an action to draft a strawman proposal?
... We could bring it up in the next telcon.
tim: we could do it here.
noah: we could do it in the afternoon.
... break for 20 minutes.
[break]
<masinter> hope things are going well, happy birthday Tim
[we ware back]
[maybe]
noah: we need consensus of what feedback TAG should give if any on
the compatibility document.
<jar> Tim wants a spec that can guide creation of a validator
noah: the current draft we are reviewing is serving a different
audience than the document Tim is proposing. You're [Tim] serving an
audience of what is and what is not a polyglot...
... this document [the guidelines doc] is more for content authors.
tim: I'm addressing the document we have in front of us - it is
"mathematical" -
noah: I am also curious for some of these things: this document says
"if you want something that's completely polyglot then here's your
rule", "if you want mostly polyglot but differences in the DOM then
do it this way"
... this is signalling to the user that it is a matter of degree.
jar: tim, you want it to say "if you do x you get the following
benefit".
... this seems doable.
... [one issue is] they don't want to make it normative - make it
into a spec...
noah: let's move forward. let's try to get some of the technical
work done here.
<jar> (the editor *might* say that for some (principled) reason it
can't be normative...)
tim: [presents his draft notes]
[discussion on title]
noah: how about "XHTML / HTML Compatibility" ?
... drop "authoring guidelines"
jar: We're trying to change it to a spec that can be validated
(against).
[we are live editing Tim's notes]
<ht> "per the HTML5 specification regardless of whether they are
processed as HTML or as XHTML"
<noah> Or "regardless of whether they are processed as HTML or as
XHTML, per the HTML5 specification "
<timbl> [23]http://www.w3.org/2010/06/09-polyglot.txt
[23] http://www.w3.org/2010/06/09-polyglot.txt
tim: apart from this are there other changes we want to see?
ht: I'd like to see more script authoring guidelines -
... there are ways of accessing the DOM that only work under one
serialization.
... if you look for some elements in your script you might only get
them if you analyze the document as an HTML document ... [has to do
with cases of elements and attributes]
... We could ask "are there any other aspects of DOM access aside
from name matching [that need to be spelled out]?"
noah: would it be worth mentioning the existence of formal MUSTs.
<jar> How about "2116 language should be used in normative text, and
not used in
<jar> nonnormative text. "
noah: specifically at minimum all the text with formal MUSTs should
be normative.
jar: this is a request to the editors
<jar> I agree, "is" is better than "must"
tim: we should take the MUSTs out and say "a polyglot document IS
one"...
<noah> I can live with either, slight preference for "is"
jar: a polite sentence about the desire to have a validator...
<jar> Something like "We request the editors, in revising this
document, to keep in mind
<jar> that we will want to base a validator on the MUSTs given in
this
<jar> document."
<jar> I'm saying that the spec should be helpful to someone
*writing* a validator - not that we are asking anyone in particular
to *provide* a validator
<jar> yves: So JAR is saying: All the MUST- (or is-) level
requirements must be testable.
<timbl> [24]http://www.w3.org/2001/tag/2010/06
[24] http://www.w3.org/2001/tag/2010/06
<noah> Note that Tim has checked in draft response at
[25]http://www.w3.org/2001/tag/2010/06/09-polyglot.txt
[25] http://www.w3.org/2001/tag/2010/06/09-polyglot.txt
jar: I'm talking about validating whether a document is
syntactically valid according to...
tim: would only work for the class of documents that don't have
scripts.
<jar> my mistake, validating scripts for containment in the polyglot
subset is untestable.
noah: the class of documents with scripts that have less-than
signs...
<jar> but other than that...
tim: that is testable.
<timbl> In general, whether the scripts "do the right thing" is not
testable.
[discussion on what can and can't be determined programatically]
ht: I might have another document which has scripts and loads this
document into an iframe...
... why is tbody on this list? it's only because of scripting?
tim: yes.
ht: I want a stronger invariant. I want the promise of polyglot
documents that they produce the same DOM and tbody violates that.
yves: [but those exceptions / warnings are discussed in the
document]
noah: 6.1.1 says "a table must have a tbody"
tim: I agree with what they've done.
... I disagree with henry. I'm fine for the tbody to be in there...
ht: I'm interested to know how big the list of [exceptional cases
where the DOM is different] is.
... e.g. because the HTML5 spec constrains where you get CDATA
sections...
tim: I think one of the nice things about this is that it gives a
recipe.
ht: I think [tim and myself] are in violent agreement.
<jar> (1) class of syntactically valid html docs, (2) class of
syntactically valid xhtml docs, (3) intersection of (1) and (2), (4)
subset of (3) for which specified user agent behavior is same, (5)
subset of (4) for which dom is the same for arbitrary processors ...
tim: not trying to define the class of every single document ...
<timbl> This group was asked to go away and define some somewhat
arbitrary subset of 5
<jar> my (1)-(5) list is my attempt to list the document classes
that we've just been discussing... checking my understanding
noah: do we have consensus from those in the room? If so, should we
wait for those not in the room?
<timbl> PROPOSED: To pass [26]http://www.w3.org/2001/tag/2010/06 on
to the authors as feedback from the people here present.
[26] http://www.w3.org/2001/tag/2010/06
ht: [I think we should run with it.]
+1
<noah> +1
<Ashok> +1
<timbl> logger, pointer?
[discussion on whether we are looking at the right section]
jar: [we should] just do it.
<timbl> +1
<jar> request that Tim add URI for editors draft, with the date on
which retrieved, to be clear to them what we looked at (CVS 1.14)
<timbl> Sent
<Ashok> scribenick: Ashok
<scribe> scribe: Ashok_Malhotra
Content-type override (ACTION-370 revisited)
<noah> [27]http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html
[27] http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html
ht: Expalins the document
... we are happy with the text that Yves proposed
... suggests two minor changes
... suggests changes to section 3.1.2
.s/Expalins/Explains/
NM: Please mention tag action
<ht> proposed RESOLUTION: HST to send the contents of
[28]http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html to
ietf-http-wg, cced to public-html and www-tag, with minor fixes
given above
[28] http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html
No objections
RESOLUTION: HST to send the contents of
[29]http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html to
ietf-http-wg, cced to public-html and www-tag, with minor fixes
given above
[29] http://lists.w3.org/Archives/Member/tag/2010Jun/0014.html
ht to close action once msg is sent
issue stays open becuase there is other work on it.
NM: Will discuss Larry's MIME type document on next telcon
Fragment ID semantics and XML Media types (continued)
NM: # During our discussion on 8 June, we noticed what appears to be
a conflict between the fragment ID semantics for media type
application/rdf+xml, and RFC 3023 as published, and also with
proposed revisions to RFC 3023 (see also section: A Naming
Convention for XML-Based Media Types). We agreed to continue the
discussion on 9 June.
Tim: Design is which some frag id are 'concepts' and some are
anchors and you can tell from the context
The other design the RDF ones are RDF are RDF but others can be used
as anchors
Tim: The TAG shd recommend ...
... cannot do generic processing of frag ids just on the basis that
it is XML
<ht> Close ACTION-370
<trackbot> ACTION-370 HST to send a revised-as-amended version of
[30]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to
the HTTP bis list on behalf of the TAG closed
[30] http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html
NM: We shd contact the folks who think you can do generic processing
and tell them they cannot do generic processing
<noah> [31]http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg
[31] http://www.w3.org/2001/tag/2010/06/tag-whiteboard-08.jpg
AM: We are going to recoomend alpha, correct?
ht: I prefer the pragma' solution ...
jar: Is there really a conflict in XML Processing?
NM: I have a case which breaks ... I can write a tool that sees a
URI with fragId
<noah> Example:
<noah> 1) I write a tool that finds a link with fragid
(lnk#somefrag)
NM: that sees +XML and use XPointer to navigate thru the doc and I
am unhappy
<timbl> PROPOSED: That the text about fragment id semantics should
be removed from the stuff about generic procesing
<noah> 1) I write a tool that finds a link with fragid
(lnk#somefrag)
<noah> 1) I write a tool that finds a link with fragid
([32]http://lnk#somefrag)
[32] http://lnk/#somefrag)
<noah> 2) The tool follows the link, gets back application/rdf+xml.
Unfortunately, when I wrote the tool, I had not read the spec for
rdf+xml, but I had read the 3023 and/or 3023 bis specs.
<jar> you mean you follow [33]http://lnk (you do the relevant GET)
[33] http://lnk/
<noah> 3) My tool, believing that 3023 applies, interprets somefrag
as an xpointer, and infers that the URI (attempts to) reference an
element named somefrag
<noah> QED?
ht: What's wrong?
NM: He wanted to reference to the element
HT: Do generic XML processor XML as XML?
NM: Tool does not have knowledge of the vocabulary
HT: A generic processor cannot be wrong
<jar> Here's my example: in [34]http://example.com/w rdf+xml I say
<foaf:Document id="zzz"> <owl:sameAs
rdf:resource="[35]http://example.org/x"/> </...> ... then the
browser (a generci xml tool) follows
href="[36]http://example.org/w#zzz" - should it (should ie be
allowed) to go to example.org/x ? or to the rdf:Document element in
example.org/w ?
[34] http://example.com/w
[35] http://example.org/x
[36] http://example.org/w#zzz
<DKA> Found an interesting and possibly relevant draft by Mark Baker
from 2002:
[37]http://xml.coverpages.org/Baker-draft-generic-xmlns-dispatch-00.
txt
[37]
http://xml.coverpages.org/Baker-draft-generic-xmlns-dispatch-00.txt
Tim: Explains example on whiteboard ... interpretations of <FOO
id='bar'/>
... difference between XML tools and RDF tools
HT: If you had the same triples in a triple store you would have a
contradiction
... but why would you load both in the same triple store?
... I don't think the contradiction is the fault of the frag-id
<Zakim> noah, you wanted to discuss why it's broken
NM: I'm in the queue to answer HT's question
... I described an XML tool ... HT asked what's broken
... 3023 encourages sub-media types
... encorouging that is broken
... I would remove the para fron 3023 that starts "Fragment
Identification -"
<noah>
[38]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
ml-03.html#naming
[38]
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming
<Zakim> jar, you wanted to examplify
<jar> "XPointers (see Section 5) can work with any XML document"
JAR: Explains his example above ... the tools is now a Web Browser
... say HTML4 user agent
... media type is RDF+XML
... browser has a choice of XML processing or RDF processing and
will end up with different results
<jar> It is possible to come up with examples that say that there's
a problem, but it's hard for me to imagine that there is *currently*
a problem in any particular case (since all of our examples involve
hypothetical tools)
<ht> [39]http://www.w3.org/TR/xinclude/#processing
[39] http://www.w3.org/TR/xinclude/#processing
<noah> Probably true, Jonathan, but if you're implying that we can
leave the architecture "broken" just because no current software
badly misbehaves, I'm unconvinced.
<DKA> ScribeNick: DKA
[discussing 4.2 in xinclude spec]
henry: you can't use fragment identifiers.
noah: this is a red herring.
<timbl> timbl: PROPOSED: That the text about fragment id semantics
should be removed from the stuff about generic procesing
noah: [back to proposals] back to proposal a (alpha).
<timbl> Well, red herring ecept that as Yves points out is demos
that you really can't use fragids with generic processing.
ht: one way to get an xpath data model is to point a conformant
processor at anything.
noah: web arch says "follow your nose"
jar: if xpointer is about infosets then what [dan c] said works...
<scribe> ScribeNick: Ashok
<Yves> [40]http://www.w3.org/TR/xptr-framework/
[40] http://www.w3.org/TR/xptr-framework/
<Yves>
s,[41]http://www.w3.org/TR/xptr-framework/,[42]http://www.w3.org/TR/
2003/REC-xptr-framework-20030325/,
[41] http://www.w3.org/TR/xptr-framework/
[42] http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
HT: Says "internal structures of XML Processors"
<jar> If xpointer is about infosets, then the 'pragma' approach
makes sense, since there's no ambiguity... if xpointer is about
resources and 'identification', then the 'alpha' (don't allow
xpointer on rdf+xml) makes more sense...
<ht> "A software component that identifies subresources of an XML
resource"
<jar> ht: Two ways to argue from this that the current situation is
not broken
HT: from this you could argue that current situation in not broken
... ontology is not an XML Resource
<jar> ht: 1. you could say, it's not an xml resource, it's an
ontology
Tim: You are defining XM Resource ... this would take you a long
time
<jar> ht: (didn't get around to saying what 2. was)
HT: This is pushing me towards solution Beta --- we should not have
used XML+RDF just RDF
YL: If we say frag-id processing is not part of general XML
Processing ... media types tell you what to do
<Zakim> ht, you wanted to express concern about levels
YL: warnings about frag-id processing
<timbl> HT, [43]http://www.w3.org/2007/ont/xml#Node
[43] http://www.w3.org/2007/ont/xml#Node
YL: Frag processing should not be part of generic XML processing
<timbl> is the class of XML node as parsed ... DanC wrote the code
in 2007
<timbl> [44]http://www.w3.org/2000/10/swap/cwm_xml.py
[44] http://www.w3.org/2000/10/swap/cwm_xml.py
<ht> I am concerned that by losing the notion of generic processing
as legitimate for at least barename fragids, we are losing real
value. . .
NM: I see some support for gamma --- generic processors shd be aware
of special processing required ...
<ht> But, question arises, I guess, what is an example of generic
processing of URIs+fragIDs, given that XInclude is _not_ an example
NM: Yves wanted an opt-in/opt-out approach
YL: I'm close to alpha
HT: I want some time ... I would like help from the XML Core WG
<noah> . ACTION Noah to draft proposed TAG comment on 3023bis
regarding fragment ID handling
<noah> The action is to reflect our so-called option alpha, I.e.
fragid processing should not be generic, because train has left the
station on rdf+xml
<noah> Note will be sent for TAG internal review, with 4 day speak
or hold peace window.
<noah> ACTION Noah to draft proposed TAG comment on 3023bis
regarding fragment ID handling
<trackbot> Created ACTION-441 - Draft proposed TAG comment on
3023bis regarding fragment ID handling [on Noah Mendelsohn - due
2010-06-16].
NM: We are done with this agenda item.
<ht> -M 0 -F /etc/autossh/ssh_config -n w3tunnel
<ht> Host w3tunnel
<ht> IdentityFile /etc/autossh/id_dsa
<ht> UserKnownHostsFile /etc/autossh/known_hosts
<ht> HostName jay.w3.org
<ht> User ht
<ht> LocalForward 6667 irc.w3.org:6667
<jar> cognate
Web Applications: Identification and URIs
NM: raman wrote a draft on client-side manipulation of URIs
... I presented the Google Maps scenario
... Raman was assigned ACTION-422 to do that
... he wrote something that idid not fulfill the action
... I took ACTION-432 to write the Google maps case
AM: I offer to try and integrate NM and TVR words into a coherent
draft
CLOSE ACTION-432
<trackbot> ACTION-432 Review client state finding update w.r.t. maps
case closed
CLOSE ACTION-422
<trackbot> ACTION-422 Examine the current text of his client state
finding and update appropriately with Noah's email from ACTION-353
closed
ACTION Ashok to trya nd integrate NM and TVRs words into a coherent
draft
<trackbot> Created ACTION-442 - Trya nd integrate NM and TVRs words
into a coherent draft [on Ashok Malhotra - due 2010-06-16].
JAR: Are there any issues here?
NM: TVR wrote a draft describing a specific scenario
... he did not want Google Maps case because "everyone knows that".
jar: Does thic touch on media-type registration?
... how do you follow your nose if there is a frag-id?
s/garg/frag/
<jar> action jar to chase down what specs say regarding looking up
fragid in 2nd representation if not found in 2st representation
<trackbot> Created ACTION-443 - Chase down what specs say regarding
looking up fragid in 2nd representation if not found in 2nd
representation [on Jonathan Rees - due 2010-06-16].
<jar> e.g. FOAF
<jar> related to (not same as) using javascript to 'resolve' fragids
(gmail)
HT: Question of whether you should be able to conneg between
TEXT+XML and RDF+XML
<jar> noah: location bar doesn't update as you pan and scroll maps
HT: side issue on address bar updating
... it matters if the URI can leak or not -- say by emailing
... if you reload the URI it violates the nedia types spec. I think
there is an issue here
Review Pending Actions
ACTION-404 on DanC
Reassign to Yves to evaluate
scribe: due June 29
<jar> (question is whether html agrees to use ietf link relation
registry)
ACTION-409 Reopen with due date of June 29
<noah> ACTION-433 is overtaken ACTION-437. Closing 433.
<noah> CLOSE ACTION-433
<trackbot> ACTION-433 Help Tim get in touch with staff etc. re
XML/HTML unification closed
Overdue actions
<noah> ACTION-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW
discussions -- due 2010-05-29 -- OPEN
<trackbot> [45]http://www.w3.org/2001/tag/group/track/actions/201
[45] http://www.w3.org/2001/tag/group/track/actions/201
<noah> ACTION-201 Due 2010-10-05
<trackbot> ACTION-201 Report on status of AWWSW discussions due date
now 2010-10-05
<noah> ACTION-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2010-05-31 -- OPEN
<trackbot> [46]http://www.w3.org/2001/tag/group/track/actions/282
[46] http://www.w3.org/2001/tag/group/track/actions/282
<noah> JAR: I'm on the way to proposing that is same as AWWSW work.
<noah> ACTION-282 Due 2010-10-05
<trackbot> ACTION-282 Draft a finding on metadata architecture. due
date now 2010-10-05
<noah> ACTION-341?
<trackbot> ACTION-341 -- Dan Connolly to follow up with Thomas about
security review activities for HTML5 -- due 2010-05-28 -- OPEN
<trackbot> [47]http://www.w3.org/2001/tag/group/track/actions/341
[47] http://www.w3.org/2001/tag/group/track/actions/341
<noah> There is a BOF coming up at IETF for possible new security
effort
<noah> That's in addition to the W3C effort
<noah> YL: They'll be including work on WebApps
<noah> JAR: Maybe we don't need to track it? Those are all good
people?
<Yves> [48]https://www.ietf.org/mailman/listinfo/hasmat
[48] https://www.ietf.org/mailman/listinfo/hasmat
<Yves>
[49]http://www.ietf.org/mail-archive/web/hasmat/current/msg00001.htm
l
[49] http://www.ietf.org/mail-archive/web/hasmat/current/msg00001.html
ACTION-341 Resaiigned to Yves due date June 15
<noah> ACTION-341?
<trackbot> ACTION-341 -- Yves Lafon to follow up with Thomas about
security review activities for HTML5 -- due 2010-06-15 -- OPEN
<trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/341
[50] http://www.w3.org/2001/tag/group/track/actions/341
ACTION-368 Jar will send mail to DanC saying you can close 368 if
you want to.
<noah> ACTION-379?
<trackbot> ACTION-379 -- Noah Mendelsohn to check whether HTML
language reference has been published -- due 2010-03-24 -- OPEN
<trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/379
[51] http://www.w3.org/2001/tag/group/track/actions/379
ACTION-379 NM: There has been interaction. Keep open. Bump date
<noah> ACTION-379 Due 2010-07-20
<trackbot> ACTION-379 Check whether HTML language reference has been
published due date now 2010-07-20
<DKA> issue-58?
<trackbot> ISSUE-58 -- Scalability of URI Access to Resources --
open
<trackbot> [52]http://www.w3.org/2001/tag/group/track/issues/58
[52] http://www.w3.org/2001/tag/group/track/issues/58
ACTION-381 Jar: Push it out 2 weeks
<noah> ISSUE-58?
<trackbot> ISSUE-58 -- Scalability of URI Access to Resources --
open
<trackbot> [53]http://www.w3.org/2001/tag/group/track/issues/58
[53] http://www.w3.org/2001/tag/group/track/issues/58
<noah> ACTION-390?
<trackbot> ACTION-390 -- Daniel Appelquist to review ISSUE-58 and
suggest next steps -- due 2010-05-25 -- OPEN
<trackbot> [54]http://www.w3.org/2001/tag/group/track/actions/390
[54] http://www.w3.org/2001/tag/group/track/actions/390
DKA: I have been looking at this.
<jar> DKA: elastic computing resource
Tim: Problem is there is a bug in the code
Dka: There is more ....
<noah> YL: There are differences between getting the same URIs, vs.
honoring cache headers, vs. with DTDs we made a decision that
referent is immutable, but that violates a notion that HTTP headers
should never expire > 1 years
<noah> DA: Maybe you partially answered: what do you think the TAG
can do?
<noah> DA: One thing to say it's "not nice", but we don't have
police powers.
<noah> JAR: To mark a response as "never expires, the response
server sends a response saying it responds with a date in
approximately 1 year"?
<noah> YL: Let's look at the right version
<Yves> [55]http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-09
[55] http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-09
<jar> "HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future."
<jar> This sentence was removed going from 2616 to 2616bis: 'To mark
a response as "never expires," an origin server sends an Expires
date approximately one year from the time the response is sent.'
<noah> NM: The problem is, it's really hard to write a normative,
enforceable spec, that tells you when you MUST retain a
representation for resuse.
<noah> NM: Lacking that, this is a hard problem to solve.
<noah> WE ARE ADJOURNED
Summary of Action Items
[NEW] ACTION: Henry to ask Hixie what is meant in this [section 9.2]
by "retrieving an external entity" and could some clarification be
added. [recorded in
[56]http://www.w3.org/2010/06/09-tagmem-minutes.html#action01]
[56] http://www.w3.org/2010/06/09-tagmem-minutes.html#action01
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [57]scribe.perl version 1.135
([58]CVS log)
$Date: 2010/06/09 16:09:15 $
[57] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[58] http://dev.w3.org/cvsweb/2002/scribe/
=================================================
Received on Wednesday, 16 June 2010 18:35:13 UTC