See also: IRC log
[Agenda planning. . .]
NM: Let's try issue HttpRedirections-57
http://www.w3.org/2001/tag/2009/12/08-agenda.html#HttpRedire
JR:
http://lists.w3.org/Archives/Public/www-tag/2009Jun/0057.html
... Going through the history---first two points are the origin
of this
... 1) 303s aren't supposed to be cached -- bug in 2616 --
fixed in HTTPbis
DC: Let's endorse that fix
LM: Not sure about that -- not prepared to endorse -- abstain
NM: This becomes relevant because we encouraged people to use 303
JR: Any reason not cache 303 responses?
LM: No
NM: draft RESOLUTION: TAG endorses the proposed change to HTTPbis to allow caching of 303 responses
DC: Specific proposal is where?
<jar> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.4
<DanC_> is this OK? "A 303 response SHOULD NOT be cached unless it is indicated as
<DanC_> cacheable by Cache-Control or Expires header fields."
JR: This is different from 307. . .
DC: I think the HTTP spec. is usually neutral wrt caching
JR: OK, we need to explore this further -- the difference from 307 is worrying
<noahm> I heard DC say HTTP was neutral in the absence of cache-control or expires header
<DanC_> ACTION: jonathan to research 303 caching change in HTTPbis [recorded in http://www.w3.org/2009/12/09-tagmem-minutes.html#action01]
<trackbot> Created ACTION-347 - Research 303 caching change in HTTPbis [on Jonathan Rees - due 2009-12-16].
JR: Sub-issue 2) There's a need
for a non-3xx response, in order that the original URI stays in
the status bar
... Unlike 302, 303 or 307, where the target goes in the
address bar
<DanC_> (researching the bug...)
JR: This is described as a security concern
<DanC_> (many/most purl users want the purl bookmarked, not the redirected addressed)
TBL: But we really don't want that for e.g. 307, because it's only a temporary redirect, so people shouldn't e.g. bookmark it
LM: The single result display in
the address bar is insufficient for what we want to tell the
user
... Doing UI design is inappropriate for us. . .
JR: I agree, that's why I want to lose this part of the issue
LM: The principle we can endorse
is that the URI you see should be a URI you can use to get you
what you see
... Going further to say it should be a long-term,
bookmarkable, etc. URI is a bit fuzzier
NM: WebArch says use one URI for
a resource
... even when they're not going away, it can be a problem, for
example when example.com redirects to example-1.com or
example-2.com for load balancing
JR: What should I do
<jar> For all practical purposes it's impossible to get a purl.org URI into your bookmarks list
DC: Let's find out why Mozilla decline to address the PURL folks' request to fix this, so that you could bookmark PURLs
TBL: Flight of fancy on 303x, 303y, 303z. . .
<DanC_> "304622 min -- All nobody RESO INVA Adding a live bookmark via feedview uses the location of the feed rather than the location given in the referring page's link element; redirects, PURLs don't work "
<DanC_> maybe this is the bug https://bugzilla.mozilla.org/show_bug.cgi?id=304622
<noahm> proposed ACTION: Jonathan to research reasons why browser providers (e.g. Mozilla) aren't willing to meet requests (e.g. from purl) to switch address bar URL following successful redirect
<noahm> ACTION: Jonathan to research reasons why browser providers (e.g. Mozilla) aren't willing to meet requests (e.g. from purl) to switch address bar URL following successful redirect [recorded in http://www.w3.org/2009/12/09-tagmem-minutes.html#action02]
<trackbot> Created ACTION-348 - Research reasons why browser providers (e.g. Mozilla) aren't willing to meet requests (e.g. from purl) to switch address bar URL following successful redirect [on Jonathan Rees - due 2009-12-16].
<jar> or to not switch
JR: 3) Rhys Lewis was working on
a finding wrt httpRange-14, but that work stopped when the SWEO
note Cool URIs for the SemWeb was published
... I think that work should be picked up and made into a
finding
... which would replace/elaborate the email message which
currently stands as the resolution of httpRange-14
... That was the context for ISSUE-57 at its inception
... Additional points that have been added, are my points
4--6
... Latest news: AWWSW task force has reported:
http://www.w3.org/2001/tag/awwsw/http-semantics-report-20091204.html
... A number of forms for this work, of which I'm the main
editor
... helped along by our discussion at the last f2f
... A lot of text to introduce one key definition:
... for the phrase "corresponds to", which comes from the
definition of the 200 response code, in 2616 and HTTPbis
LM: I wouldn't take this too seriously -- we didn't when we wrote it
JR: We agree entirely. It's the practice which matters to actually pin this down
LM: I note that this story works/should work pretty much for ftp: as well
JR: Wrt WebArch, 'representation'
corresponds to 'entity' or 'content entity'
... and 'represents' corresponds to 'corresponds to'
<DanC_> LMM: the HTML spec uses 'resource' for what HTTP calls entity. I filed a bug; we'll see...
LM: Note that the correspondence is at a particular instant
JR: Yes, at a particular time
LM: And in a particular context
JR: It's hard to pare things down
to the point where we could focus
... So there's now a bunch of stuff which has been moved off
the table
... Section HTTP Exchanges summarizes what we all know about
GET requests
DC: hmm... in pt 5, "preferably"? the server decides which resource the name refers to...
JAR: but an intermediary might get confused
DC: ah... "preferably" makes more sense for intermediaries
TBL: 304? 307?
JR: Yes, step 6 pbly should be
clarified wrt responses other than 200
... [works through the RDF formalization]
TBL: Why did you avoid 'representation'
JR: Because people objected to giving a URI to something called 'representation' a URI
TBL: All I was concerned is to distinguish the original resource, identified by its URI, and the 'resource' which is some representation of that resource, which also may have a URI, but is not the same
JR: Right
... correspondence is a 4-place rel'n between resource, a
content entity, a start time and an end time
HST: Context is richer than just time
LM: Accept headers
TBL: But there's still something core
JR: I try to work breadth first
HST: I didn't mean Accept Headers, but rather deixis, e.g. http://localhost/
DC: or http://my.yahoo.com/
JR: On to section "What this semantics is careful not to say"
<masinter> http://tools.ietf.org/html/draft-masinter-dated-uri-05
<masinter> vs http://tools.ietf.org/html/draft-masinter-dated-uri-06
LM: Server response is a speech act
JR: Precisely -- let's look at
some more recent slides
... How do you prove correctness of an HTTP proxy, cache, API
or theory
<DanC_> Potatoes don't say anything
<DanC_> bug in "Content negotiation" slide: speaks_for should be corresponds_to
slide21 should have corresponds_to instead of speaks_for in conneg slide (21?)
<jar> TOPLAS 1993 ?
<DanC_> (I think of it as BAN logic)
JR: Now make use of Abadi,
Burrows, Lampson and Plotkin logic (ABLP)
... originally for crypto
... and access control
<DanC_> (a larch formalization http://www.w3.org/Architecture/iiir-larch/BAN.lsl based on a 1989 SRC Research Report )
LM: What's good about this is precisely that it qualifies everything with the principal who/which/that says it
JR: Crucial observation -- HTTP defines corresponds_to as follows:
"example.com controls {http://example.com/foo corresponds_to E}"
JR: The domain of "says" is
principals, Non-principals don't say anything
... Not all resources are principals
NM: Break for 15 minutes
<jar> There are two versions of ABLP, the DEC SRC TR from 1991, and the TOPLAS paper from 93 or 94
<jar> not to be confused with the earlier BAN paper from 1990, which overlaps in content
NM: Resumed
JR: [Gets to slide 12, reconstruction of httpRange-14]
NM: So this is stronger than the original conclusion?
JR: Yes
... The original 'resolution' simply constrained the range of
the corresponds_to relation
... but it didn't actually address the original problem
NM: Elaborating the "image conneg example": URI identifies a photo. Conneg used to retrieve either jpeg or gif. They agree up to a point in conveying the photo, but not completely, does the theory allow/explain that?
JR: This theory as it stands isn't articulated enough to determine the relationship between corresponds_to and speaks_for
NM: Good progress here, wrt
httpRange-14
... Note that we're OK, mostly, when we ask for, say, the
Declaration of Independence, and what we get back has some
advertising in a sidebar
... and I think this can address that
LM: I think this is very good stuff. I hope we can use it to clarify what is meant by Origin
LM: The whole CORS, confused deputy, etc. debate is hampered by a lack of clear definition of precisely this kind of thing: what is an origin, a deputy, etc.
LM: Linking SemWeb and Security would be a great thing, possibly a win for both sides
NM: Great idea -- specific action?
DC: I'd like to write this up in a different editorial style
<timbl> Have we finished JAR's slide set?
JR: Sure
<timbl> ah
JR: Connects with CAPdesk, DARPA-funded DARPAbrowser
<noahm> The chair would very much like for Dan to propose an action for himself.
<DanC_> . ACTION Dan write up speaks_for applied to httpRedirections and httpRange using motivating examples
<noahm> Thank you!
<DanC_> ACTION Dan write up speaks_for applied to httpRedirections and httpRange using motivating examples
<trackbot> Created ACTION-349 - Write up speaks_for applied to httpRedirections and httpRange using motivating examples [on Dan Connolly - due 2009-12-16].
<johnk> Pointing out Miller et al's Horton paper: http://www.erights.org/elib/capability/horton/
<johnk> re: "delegating responsibility in digital systems"
<jar> JAR is babbling about Mark Miller's previous work: DARPAbrowser and CAPdesk (w.r.t our discussion of 307 and what's in the browser URI bar, etc. )
TBL: Slides done, can we try to
find a replacement for 'speaks_for'
... We have a URI, we get a 200
... Using 'speaks_for' as the relationship which relates
content to the resource
... but if R is a person, the content can't 'speak_for' a
person
<DanC_> contexts in which the term gets used "a secure channel from Bob speaks for bob"
TBL: that is, an entity speaking for the agent
<masinter> you get a 200 from a server, where the server speaks for the person
JR: In the old days we sent
letters, and my letter did 'speak_for' me
... No resource speaks for me, it doesn't say that
<DanC_> (it's clear to me that offline witing is going to be more efficient than group discussion, but if Tim has a clear example, I'm interested to capture it.)
<DanC_> i identifies Pat Hayes
<DanC_> 2. 200 from resource identified by i
Slide 9 appears to back Tim
<DanC_> conjecture: 200 response speaks for Pat
HST: Stipulate that we have a URI
for Pat Hayes
... Then your slides appear to say that if I get a
ContentEntity from GETting that URI
... that it a) corresponds_to Pat and therefore, per the
'Controversial Axiom', that it speaks_for Pat
JAR: would give us a reason to ask Pat not to assert such things, because it breaks our theory
JR: Ah -- the ContAx isn't
licensed by any existing spec.
... I think it's useful to explain a lot of WebArch
TBL: So if it is, we have a reductio wrt Pat saying what he says about that URI
<DanC_> phpht
JR: Oh, yes, and, the ContAx
should include server says that E speaks for R
... not E speaks for R directly
AM: Looking at R doesn't say any s, then E doesn't (mustn't) say any s
JR: This is meant just to be a restatement of the positive direction
AM: This says E's only role is to say what R says
JR: Yes, that's the ContAx
JAR: yes, advertising conflicts
DC: I'm getting useful input, not guaranteed to end up in the same place
LM: Please try to include Origin
DC: Not sure how, but I'll at least try.
HT: I think perhaps there are too many levels at which entities say things. It's clear to me that an XML document says some things, because of the semantics of XML. I.e. the infoset.
TBL: I dispute that it says those things.
DC: I understand both positions.
JAR: Me too.
HT: I'm being intentionally obtuse in part to get to talking about a 3rd party, which is the interpreter of the message. We often think of this as a human observing a screen, can also be listening to audio.
HT: It's that which ultimately says things.
JAR: Similar to the crypto case, in which the interpreters have to be part of the proof system.
<masinter> A potato says "help i'm a potato" ?
<DanC_> (the dispute between TBL and HT is issue ISSUE-28 fragmentInXML-28; odd that tracker considers it closed when it's plain that the TAG doesn't have consensus.)
TBL: When it's RDF, what it says is what the triples it produces say
<DanC_> (the resolution in tracker sides with Tim)
HT: Isn't that analagous to my statement that what an XML document "says" is first order the Infoset, and then 2nd order the interpretation of those.
TBL: No, I'm talking about the interpretation of the graph.
HT: Ah.
HT: What I [originally] scribed is wrong when I attributed to TBL "what it says is the triples it produces"; should have scribed "what it says is what the triples it produces say"
NM: good progress here, great
work JR
... DC is going to try to restate/elaborate
<DanC_> action-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW discussions -- due 2009-12-01 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/201
<DanC_> . action-201 due 15 Mar 2010
[procedural discussion]
<DanC_> action-201 due 15 Mar 2010
<trackbot> ACTION-201 Report on status of AWWSW discussions due date now 15 Mar 2010
TBL: I'd like to see some interaction with the Tabulator work
<DanC_> ACTION-116 due 31 Dec 2009
<trackbot> ACTION-116 Align the tabulator internal vocabulary with the vocabulary in the rules http://esw.w3.org/topic/AwwswDboothsRules, getting changes to either as needed. due date now 31 Dec 2009
<noah> ACTION-201 Due 2 March 2010
<trackbot> ACTION-201 Report on status of AWWSW discussions due date now 2 March 2010
LM: Could we have used a Link Header in a 404 response?
JR: Yes
LM: But not a link in the body of 404 document itself?
DC: No
LM: But I like the idea of having links in the body, because you can have lots of them
http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html
<noah> http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html
<noah> This is in relation to ACTION-303
AM: Doesn't this allow me to just support an earlier version?
<Zakim> noah, you wanted to talk about problems with >requiring< future proofing
HST: The 'earliest appropriate'
sentence is meant to rule that out.
... Maybe that needs to be stronger
NM: I have a long history of
interest in this
... I like this as a goal for many circumstances
... But there are cases where it doesn't work
... The XML 1.1 experience is illustrative in this case
... So we shouldn't require this kind of future-proofing of
references
... Specifically in terms of systems which are involved in
communication
<DanC_> +1 "should future-proof" is too strong. The simple case of citing a frozen spec is fine in many cases
<Zakim> johnk, you wanted to wonder whether it is confusing to combine conformance and referencing behaviour in one statement
<noah> Seeing where you're going, Henry, unless new editions >never< allow for new content, I think my concern stands.
JK: Conformant implementations? Should that be separated from what is referenced? Trying to pack too much in?
<noah> Or maybe I'm not guessing right as to what your concern/suggestion will be.
JK: How references are written is different from what is a conformant implementation
<Zakim> DanC_, you wanted to ask for a reminder of a specific case we're particularly interested in... it was somewhere in the HTML 5 references, yes?
DC: There was a specific case wrt the HTML 5
<masinter> think IETF tradition is to make the 'future proofing' more part of general policy than being specific in each draft. A1 references B1. When B2 updates B1, implementations of A1 may or may not follow B2
HT: As it stands, there are only stubs in the HTML 5 references.
DC:HT: No.
HT: Last I looked. E.g. following link from content-sniffing you got something that just said content sniffing.
<DanC_> http://dev.w3.org/html5/spec/references.html#references
<noah> We pause to read HTML 5 references section....
HT: Ah, it's better than it was.
DC: So if we pushed on any of these, we would pbly find the editor would have a reason
HT: E.g. the text in the references says "[CSS] Cascading Style Sheets Level 2 Revision 1, B. Bos, T. Celik, I. Hickson, H. Lie. W3C, April 2009.", but links the undated copy.
HST: So what does it mean for an implementor? Specifically, implementors 5 years from now have to figure out what was meant. We're trying to fix that.
<Zakim> TBL, you wanted to point out that anyone using this language assumes there is a contract with future working groups to maintain the operability of the referencing spec, when
TBL: If you propose we use the
present and the future -- why not earlier ones?
... As for the future, that depends on the sort of WG and the
sort of spec.
... If the group doesn't commit to back compatibility, you
can't rely on it
<masinter> Is the distinction between "edition" and "version" important?
TBL: You might try to negotiate a
commitment from the WG that they won't change. . .
... Or you might just require people to check
<masinter> Can distinction between "technical specification" and "applicability statement" be useful? "applicability statement" calls out specific dated versions, while general "technical specification" doesn't? Two documents, one of which updates.
TBL: So it's not clear that we can go with what you propose
LM: I like the difference between
edition and version
... We used to differentiate between applicability statements
and language specs.
... So you would only have to update the appl. statement
<Zakim> ht, you wanted to reply to Noah wrt editions vs. versions
LM: Alternatively, you could have policy outside the doc. altogether
NM: You haven't addressed my concern, because it wasn't lack of back-compat that broke the XML 1.1 situation
HT: The response to Noah and Tim is to say "yes, all those criticisms apply to unrestricted blank checks" (leaving aside for a sec refs to older versions), by relying on the W3C Policy for Edtions (stepping gently around XML 1.1/10 5th edition in particular), is precisely because it makes this plausible.
NM: Do new editions allow new content?
HT: Yes.
NM: Then I still have a problem. See problems deploying XML 1.0 5th edition. A sometimes inappropriate (depending on the specs) expectation is created that implementations that haven't been updated will support new content sourced by those that have been.
JR: Conformance to a spec. that has a variable in it is intrinsically vague
<Zakim> jar, you wanted to consider classes of comforming implementations (conforming to various combinations of specs)
JR: So there's a time-sensitivity wrt the answer to "does this conform?"
<Zakim> noah, you wanted to mention that there can be issues with 3rd party specs.
NM: TBL mentioned SOAP in passing
[AM leaves]
NM: SOAP wasn't sure about
supporting XML 1.1
... It depended on the Infoset, and we weren't sure that even
if we went to XML 1.1, the Infoset would have been
well-future-proofed enough for it all to hold together
... So in some ways, my willingness to future-proof my
references depends on other specs also being well
future-proofed
<Zakim> johnk, you wanted to ask how can we apply henry'd text to the specific issue noted?
HST: Yes, we have a real case of this with XML 1.0 5e and XML NS 3e
JK: Addressing dated prose in conjunction with an undated URI is separate from future-proofing?
LM: My assumption is that the dated ref. is normative
<jar> If dated spec A normatively cites undated spec B, and artifact Z conforms to A - what does that mean? Maybe: (1) it conforms to A(B(t)) for some t, or (2) it conforms to A(B(t)) for all t, or (3) if conforms to A(B(t)) for t >= now
DC: Hidden URIs are less significant
<DanC_> (editorially I like including the full, dated URI in a citation, but I much prefer using the document title as the link text.)
HST: Jonathan attempted
to answer John. I agree as far as it goes but want to go
further. You're right, I was trying to address two problems: 1)
dated vs. undated refs conflict, and BTW some peoples' styles
to make the URI explict...
... there are many
variations on that 2) usually, all that people tend to say is
by grouping into normative and non-normative. It's rare for the
conformance section to clarify what is meant by making a
reference normative.
<noah> FWIW, Dan, though it's clunky, I tend to feel that making both live links, to the same URI, is the least bad approach.
<jar> the normative reference speaks for the spec that refers to it
<DanC_> (oh... and I don't like "available at"; I consider the semantics "identified by", and I leave it implicit)
<DanC_> http://lists.w3.org/Archives/Public/public-html-comments/2009Dec/0002.html
<noah> Queue is open only for next steps discussion
DC: I asked the HTML 5 editor to
add 'work in progress' to links to documents which identify
themselves as work in progress
... The response was 'busywork'
NM: I don't think this can go further unless my concerns and maybe TBL's are addressed
<DanC_> (aha! found some work I did in this area: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0136 'formally defining W3C's namespace change policy options w.r.t. recent TAG versioning terminology' )
JR: I thought restricting to editions was good enough
TBL: I had missed that HST meant to constrain to editions, that satisfies me
<noah> What I have in mind is something along the lines of:
<noah> The TAG believes that this is good practice in many cases, but not in all. We recognize that, particularly in cases where no assurance is given that future editions won't support use of new (I.e. previously invalid) content, the advice given here may be impractical.
<DanC_> I think the short para HT proposed is "too clever by half"; it'll only be an effective communication if it recapitulates critical parts of the edition policy
<DanC_> also, I want to make it clear that it's not the only "template" we endorse by providing more than one template; e.g. another one for really frozen, dated specs
<jar> whether in practice the "edition" process as specified and executed is sufficient to protect investment is something I'm not qualified to answer. it sounds as if it would be, as specified, if followed, but haven't checked...
<DanC_> close action-303
<trackbot> ACTION-303 Draft text on writing references closed
<DanC_> close action-304
<trackbot> ACTION-304 Write up issue around normative references to particular versions of specs closed
<scribe> ACTION: Henry to revise http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html based on feedback on www-tag and the feedback from TAG f2f 2009-12-09 discussion [recorded in http://www.w3.org/2009/12/09-tagmem-minutes.html#action03]
<trackbot> Created ACTION-350 - Revise http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html based on feedback on www-tag and the feedback from TAG f2f 2009-12-09 discussion [on Henry S. Thompson - due 2009-12-16].
<johnk> http://www.erights.org/elib/capability/horton/
<DanC_> Miller et. al.
NM: Adjourned for lunch.
Note: the lines below, up to the announcement that the meeting is "resuming", are in response to informal requests that were made during breaks for information about certain recent Microsoft announcements. These were not discussed during the formal meeting sessions.
<timbl> http://pinpoint.microsoft.com/en-US/Dallas
<noah> Tim, if you're interested in Microsoft's Dallas, it was introduced at their developer's conference a couple of weeks ago. You can go to the transcript of the keynote at http://www.microsoft.com/presspass/exec/ozzie/2009/11-17pdc.mspx and look for the word "Dallas". The video of the keynote, with demos, is at http://cdn-smooth.ms-studiosmedia.com/presspass/mpeg2/1001009_PDCD1_500k.mpg
<noah> You can use the transcript to find the right place in the video.
NM: Resuming.
<masinter> I believe the TAG asked me to review widget:
<masinter> I did so
<masinter> the webapps working group replied
<masinter> i answered their replies this morning
<masinter> if the TAG would like to review the correspondence and chime in later, then we don't need to take up meeting time here. If you'd like, I can go over what I think the open issues are. Opinions?
<masinter> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/
<masinter> see "Comment on Widget IRI" messages
(still working on the agenda)
<noah> http://www.w3.org/2001/tag/2009/12/08-agenda.html
<timbl> http://www.w3.org/DesignIssues/PersistentDomains
close action-311
<trackbot> ACTION-311 Schedule discussion of a persistent domain name policy promotion closed
timbl: Above link is old, but
background
... Argument against using http: URIs as names, is that DNS doesn't
socially support you. The domain name is rented, not owned.
... One proposal, if it's broken, fix it.
... DNS was controlled by IETF, ICANN, and it being up for rent was
assumed a good idea
... now the dangers are becoming known.
... All the white house pages disappeared when the administration
changed (e.g.)
danc: (asks about how that example bears...)
<masinter> points to http://larry.masinter.net/9909-twist.pdf again
timbl: Many companies put up things that people would like to find later
danc: There is a third-party business around finding things like that
<DanC_> (I don't see how domains would help in either of the supposedly-motivating cases timbl just gave)
timbl: Anyhow. One way to tackle is
to make a new TLD that has different rules
... You might use it for archivable web pages , under a set of
rules
... concerning transfer of rights to other entities so that pages
can continue to stay live
<masinter> points to http://larry.masinter.net/duri.html and previous version http://tools.ietf.org/html/draft-masinter-dated-uri-05
timbl: there might be a pot of $ to
pay for this
... Problem is to design a social system, maybe as a DNS play, or
by setting up a consortium
<masinter> points to whitehouse.gov
timbl: Suggesting that to help make this happen, the TAG could write a finding advocating it
ashok: These would be *unalterable* pages?
timbl: To be determined
ashok: Can you then sell something in this archive space?
timbl: What transfers is responsibility - not any right to change
jar: It's a contract with the public
<Zakim> ht, you wanted to suggest a workshop
ht: There are many design points. We
could spend time talking about alternatives...
... I wonder is for the TAG to host a workshop before we write a
finding, to scare up a representation of the interested
parties
... a new TLD is a problem for existing URIs that are supposed to
have persistent resolution
... but might be worth paying the cost
... Another way to go is to talk ICANN into a process around
existing domains & persistence
<DanC_> (ah.. that would be better... a way for any domain to get permanent status, sorta like 501(c)3 )
ht: Can we get theorists, library
community, other constituencies together to talk
... How about a workshop?
<DanC_> +1 workshop
<masinter> points out talks from previous 1999 workshop on Internet Scale naming
<noah> Wondering whether cost/logistics would work out for workshop proposal. If so, seems appealing, but not sure whether we can get
<Zakim> DanC_, you wanted to note that it's not any more broken that it could/should be. New domains are not going to get companies to keep their product manuals online or stop the
danc: Tim's examples didn't motivate
a TLD for me...
... Giving more visible to best practices is a good idea
though
... There's a running business that does endowed web
publication
ht: I haven't found any reference to DNS insurance
danc: There are journals like PLoS
that charge authors because they agree to host the content in
perpetuity
... you pay once, it's there forever
noah: (pokes fun at this)
danc: The White House doesn't have the URI persistence ethic
<masinter> points to "This American Life" story about a cyrogenics firm which promised perpetual freezing: http://thisamericanlife.org/Radio_Episode.aspx?sched=1239
masinter: Points to 1999 workshop "problems URIs don't solve"
<masinter> points to http://larry.masinter.net/9909-twist.pdf again
masinter: Organizations split. They
merge. They go out of business. Sub-sites move. Countries
disappear.
... In perpetuity has to be around content, not just names
... People will look to organizations like archive.org for
long-term resolvable names
<timbl> ./me quickly runs a script to change all the links in all his HTML to point to an internet archive version of the URL just in case
masinter: Getting a guarantee is not the same thing as getting a credible guarantee
<masinter> points to http://larry.masinter.net/duri.html and previous version
<masinter> http://tools.ietf.org/html/draft-masinter-dated-uri-05
lm: would like advice on how to
progress with these two projects
... duri = dated URI, guarantees persistent reference, but
resolution may be tricky
<timbl> I wonder whether "that described by" is one word in Latin
lm: still puzzled about this approach
danc: Use cases?
lm: tdb: has an optional date... actually two of them, when the resource was read, and when it was interpreted
danc: I've never seen a situation where the complexity of duri: is required
<Zakim> noah, you wanted to say that the TLD with persistent assignment seems very appealing, restricting the owner's ability to alter the pages doesn't. Seems best approached as an
danc: The URI scheme space is high price real estate, so better to do as an RDF property for those who are happy to use RDF
noah: Something was said about locking down the content, Tim hesitated
timbl: source code repository with version control
<masinter> 1999 workshop: http://www.isr.uci.edu/events/twist/twist99/
noah: What about perpetual ownership
of name - should be orthogonal to an obligation to preserve
... Preservation of content should be more granular
ashok: Who will host all this stuff? Not a private company, which can go away.
timbl: A consortium of libraries.
ht: Replication is the only assurance
of permanence
... This is a huge design space.
<Zakim> johnk, you wanted to ask what is the incentive for someone to use duri and if not sufficient incentive, and not all using them, wouldn't we still have the problems described by
johnk: This is a social problem. Not
sure we can solve this. All of the institutions and agreements go
away.
... Not sure this is web architecture
timbl: We need to kick it from the technical into the social
<Zakim> ht, you wanted to mention transparency
<masinter> points to http://www.lockss.org/lockss/Home
johnk: There's no technical solution here
<DanC_> yes, lockss is great work in this space
<noah> Heads up: before Dan goes, I want to remind everyone that we should switch to generic resources within 5+ mins
ht: Footnote: The motivation for
things like tdb: and wpn: was transparency, so that you can tell by
looking at a URI that it named a non-information-resource (not sure
i still believe that)
... One component is a board of trustees with the power to wind it
all up (e.g. if there were no web, at some future time)
<masinter> points to http://larry.masinter.net/0603-archiving.pdf for long-term archiving also (and see references)
ht: The digital curation people worry about: Where do the resources come from to carry resources forward (e.g. archaic disks)
timbl: lots of ways for accessibility to fail
<Zakim> DanC_, you wanted to push back: why should IBM get "ibm.com" in perpetuity without giving back to the commons/community a persistence promise (e.g. re content of homepage) and to
ht: Aim for June?
<noah> suggest phrasing, "perhaps in June"
<DanC_> ACTION Henry to look into a workshop on persistence... perhaps the June 2010 timeframe
<trackbot> Created ACTION-351 - Look into a workshop on persistence... perhaps the June 2010 timeframe [on Henry S. Thompson - due 2009-12-16].
<Zakim> masinter, you wanted to ask who gets "att.com" when AT&T is broken up into baby bells, lucent, etc.
lm: recommends references in the long term archiving paper (see above)
<DanC_> ... esp the references
<noah> NM: To be clear, I think persistence of name assignment should be attacked (mostly) separately from encouraging providers of content to provide that content in perpetuity and/or to make it immutable.
<DanC_> action-312?
<trackbot> ACTION-312 -- Jonathan Rees to find a path thru the specs that I think contradicts Dan's reading of webarch -- due 2009-12-01 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/312
<DanC_> http://lists.w3.org/Archives/Public/www-tag/2009Dec/0061.html
JAR:The email I sent on Monday was sort of "camouflaged"
JAR: In a sense, some people are trying to say, 'I can prove I need URNs'
JAR: I was trying to set that down more rigorously.
JAR: I want to relate it to the formalism I've been building.
<DanC_> close action-312
<trackbot> ACTION-312 Find a path thru the specs that I think contradicts Dan's reading of webarch closed
<DanC_> action-121 due 15 Mar 2010
<trackbot> ACTION-121 HT to draft TAG input to review of draft ARK RFC due date now 15 Mar 2010
<DanC_> action-121 due 2 Mar 2010
<trackbot> ACTION-121 HT to draft TAG input to review of draft ARK RFC due date now 2 Mar 2010
<DanC_> action-33 due 20 Dec
<trackbot> ACTION-33 revise naming challenges story in response to Dec 2008 F2F discussion due date now 20 Dec
<noah> http://lists.w3.org/Archives/Public/www-tag/2009Nov/0069.html
masinter: I drafted replacement
text
... "how to use conneg" explanation for HTTPbis
<masinter> http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0763.html
danc: Don't see any text about how the representations relate to one another
<noah> BTW, the "problems" with the tag-weekly.html version of the agenda seem to be due to slow response by W3C servers. The tag-weekly.html version now appears to match the dated version.
<masinter> http://lists.w3.org/Archives/Public/www-tag/2009Nov/0077.html
masinter: sentence about server's purposes needs to be added. re-open action
danc: This is what the speaks_for
slide in the presentation is about... if representations
contradict, it's incoherent
... How about striking "for its purposes"
lm: "for the purposes of this communication"
<DanC_> +1
+1
noah: (making another point about
attribution)
... determining, for the purposes of this communication, which
representations...
<noah> Note that the supplier of representations (or choices) has the responsibility of determining, for purposes of this communication, which representations might be considered to be the "same".
<noah> I don't like "considered to be the same".
<DanC_> how about: considered to give the same information
noah: The spec already says entity
corresponds to resource
... Two representations each have the responsibility to correspond
to.
... so nothing else needs to be said.
<masinter> change "might be considered 'the same'" to "might be considered to represent the same information'
DanC: That's the bug we're trying to fix.
<noah> Not convinced.
noah: Saying "corresponds to" is enough
<masinter> the proposed text in http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0763.html uses "represent"
johnk: You're saying two things. Do we want to make the second statement, that the conneg reps have to sufficiently resemble one another (or something similar)?
<noah> There is already an obligation that each representation correspond. It will tend to be the case that multiple representations of a (an immutable) resource will tend to have interpretations that are in some ways similar, perhaps extremely similar, but the archicture should not rule out, e.g. a B&W gif and a color jpeg of very different resolution.
lm: Different ways to represent "the
same information" (quoting lm's email 763)
... I infelicitously said "same representations" when I should have
said "represent the same information"
noah: There are enough weasel
words
... good that we're talking about representing the same
information
<noah> I.e. to make me happy
lm: And the server has responsibility.
<DanC_> action-231?
<trackbot> ACTION-231 -- Larry Masinter to draft replacement for \"how to use conneg\" stuff in HTTP spec -- due 2009-11-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/231
<DanC_> action-231 due next week
<trackbot> ACTION-231 Draft replacement for \"how to use conneg\" stuff in HTTP spec due date now next week
(consensus around give or represent the same information)
?
break.
noah: Let's see if we can get
organized for a more comprehensive approach, or find a whole that's
greater than the sum of the parts
... The TOC is broader in the topic coverage than it might be
... maybe look at the form of our products in this area
ashok: From what we spoke about
yesterday, it seemed there were many differences between various
people think about web apps
... I thought: web app = you are working with several communicating
components
... but maybe some people thought it was an app running on a server
[with sessions]
<Zakim> DanC_, you wanted to project the web app product next to the outline, and to suggest (a) invited presentations or other get-togethers and (b) looking at relevant wikipedia pages
ashok: In the first case, authorization etc are big issues. In 2nd case, security issues go away
danc: I was looking at PhoneGap and
Native Client [see previous action]
... Inviting any of those folks to talk to us would be a good
thing
... Let's look at wikipedia pages related to security, web apps,
widgets, etc
... The idea is to inform the developer community; a lot of people
end up at wikipedia
... Maybe contributing to wp might be a way to help
... (brainstorming)
<Zakim> jar, you wanted to ask for / suggest criteria etc
JAR: I agree with Ashok's comment about Web applications, and assumed we were talking about the distributed case.
JAR: I assumed it involved The Common Man in the Street (TCMITS).
JAR: Regarding the TOC, it was a brain dump, first developed by the group together, and then refined by me. What I'm missing are criteria. Some sort of structure or philosophy that would guide us.
<noahm> NM muses: maybe the criteria include: 1) architectural issues you would not get right based on what's been set out for the Web of documents and 2) clarifying points of confusion Goal: show that it's, in the end, one consistent, scalable architecture integrating documents and apps.
JAR: Consider, e.g., why a specific programming language wasn't chosen for the Web. It was deemed desirable to have competition there. Maybe there's a winner now (Javascript.) Anyway, what do we want to make the same, and what different?
noah: We don't talk about how you use oracle, that's an implementation detail
<DanC_> (I dunno how conscious it was that javascript happened when it happened... there was talk of active content back in 1990. tcl and such. not to mention display postscript.)
<johnk> well, and you have XSLT with XML and CSS too I guess
noah: Things like cross-origin
security, how to use URIs right - those things are in scope
... What happens inside server is not in scope
... typed possible criteria into IRC (above)
... clarify confusion around e.g. AJAX, or say how to apply old
story in new situations
... to what extent is google maps one application, vs. a very large
number of maps? ... more than just a document
<Zakim> noahm, you wanted to respond to ashok
timbl: Even though mapping software allows you to display many overlays, this is always done in code. But with calendars - you can control calendar view, how they're stacked / displayed - that's richer than what you can do with maps
<DanC_> (hmm... I wonder if KML is sufficient.)
<noahm> I think that talking about proper use of URIs when you're composing layers might be interesting
<DanC_> (... to get maps to work, like calendars, in various clients)
<noahm> Ah, when Tim says music, he's thinking more iTunes than Sibelius
<noahm> http://www.sibelius.com/home/index_flash.html
timbl: Music: iTunes maybe - other applications - multidimensional access / view. Key point is you're looking at more than one document at a time
timbl: When you pull in the data you have to be clever. E.g. you're looking for photos tagged x. Client would do a query to get the photos of interest
<DanC_> (it's really a drag that the Zakim queue isn't a UI feature, e.g. integrated with the list of names in the channel. So many times I'm this close >< to writing an ajax-based front end to Zakim/tracker/rrsagent)
[?]
<Zakim> johnk, you wanted to say that it was part of web arch in 1990
johnk: Want to push back on jar's
idea that webarch didn't address programming / application
layer
... For last TAG meeting I tried to draw a parallel between local
web browser vs. javascript ... original web arch did deal with
this...
timbl: For example, you could have
faceted browsing using forms
... javascript model just moves data/code onto the client
johnk: Phone's IP address isn't
public, but a server [once it knows address] can call back to the
phone to perform actions
... would like to address that applications are distributed in some
way [holds up piece of paper]
johnk: Here are some models. 1.
server & client, server assembles a widget, client GETs widget,
does a software install
... interesting thing is 2 trust decisions. 1. Install? 2.
Run?
... side case: What is difference between this and native client,
or plugin?
... again you have 2 trust decisions, except that (maybe) app is
given more power
ashok: Model: app stays on server ---
johnk: I'm not done. Case 2. For
example, in iGoogle (?), Google says all this content is sanctioned
by Google
... Client does a GET, trust decision is: Install + run? (as one
decision)
... ashok: How different from widget case?
... Both in one step.
noah: (something about cookies vs.
user ids)
... Reserve the word "install" for ...
johnk: Case 3: Site A has a document,
with content that calls out to site B (Fedex and airline)
... Fedex has document that calls out to airline
... (2nd example) Amazon is in control, compiles the content
... Cross-site case. there are trust decisions in both
directions
danc: Line from amazon to fedex - ?
johnk: Not saying this is deployed in a reasonable way, just observing
Case 4: Client accesses both Amazon and Fedex
scribe: the client does the mashup
danc: e.g. tabulator
... We're trying to get a feel for case 4
timbl: Tabulator is a browser extension
danc: What's a good example?
timbl: If you look up me, it pulls up information from wikipedia
danc: No, where the *user* chose both sites?
timbl: What people have we seen?
danc: The interesting difference is that in case 4, the user chooses the sources to be combined. It's not one server referring the user to another.
timbl: Consider two people on twitter, each with a bunch of tweets.
<DanC_> (might have been nice if tim had drawn a separate thingy rather than erasing 4. oh well.)
timbl: Storage of the data is
separate from the...
... Suppose tweets are to be readable by my friends
... when someone pulls in tweets, it's because they're in the
group
... tabulator code is completely trusted by C. Runs with user's
identity
<DanC_> (hmm... this speaks_for exercise might be an interesting way to look closely at OpenID phishing risks... and to explore my intuition that OAuth is sorta kerberos-shaped)
johnk: The user has to decide to download the twitter app, and ...?
timbl: No, it's in the cloud
(scribe not quite getting it)
timbl: Separate decisions about where to store their data, vs. [something about the app]
johnk: (End of 4 cases as diagrammed on piece of paper and then on the whiteboard)
johnk: web server provider / consumer issues coming out of SOAP work
ashok: There are several trust decisions... made by the *user* explicitly
johnk: brainstorming...
... The site is also making some decisions for you
<DanC_> . ACTION: John integrate whiteboard drawings into a prose document about ways to distribute applications
ashok: In case 2, where igoogle pulls in stuff for you, there's the question of state
johnk: Yes, in all 4 cases
<DanC_> ACTION: John integrate whiteboard drawings into a prose document about ways to distribute applications [recorded in http://www.w3.org/2001/tag/2009/12/09-minutes.html#action04]
<trackbot> Created ACTION-352 - Integrate whiteboard drawings into a prose document about ways to distribute applications [on John Kemp - due 2009-12-16].
<Zakim> noahm, you wanted to ask about use of core mechanisms like URIs in the Tim use case
noah: Tim's use case was about making maps much better. You go out and say 'tell me about this area'
<Zakim> DanC_, you wanted to look at the list of install-time capabilities/permissions in the W3C widgets spec and to note http://www.w3.org/TR/widgets/#feature seems to have no
(timbl recessing himself)
danc: List of install capabilities in
widget spec - seems dangerous to standardize this
... "This is xxx and it wants to look at your contacts list"
(timbl back)
danc: Can't find an actual starter
list of particular permissions / capabilities - seems good to not
standardize, but seems bad because not tested
... Lets you sprinkle open dust on your distributed system
noah: We're no worse off. Let the market deal with it
johnk: Symbian has a specific list of caps that the OS gives you
<DanC_> I'm fairly satisfied with using URI space as a marketplace of features, if it works out that way
masinter: Issue of versioning APIs,
registries comes up repeatedly
... the problem becomes much worse regarding what might be
available on the device
<DanC_> but yeah... if everybody pretends to support hundred-pound-gorrila.com/featurex , then that sucks
masinter: "are you a Symbian phone"? is the wrong question. "do you support geolocation?"
noah: If you have an ordinary web
page, it asks, can I call the geoloc API?
... or, in the install process, the question gets asked at install
time
... phonegap either does or doesn't give you a good answer
danc: The premise of the w3c widget
spec is that you could have a w3c widget store
... The 100-pound gorilla phenomenon is still a risk
... ... little guys will be disenfranchised
<Zakim> noahm, you wanted to ask about use of core mechanisms like URIs in the Tim use case
lm: If you want to name it with the name of the implementation, it's hard to extend, or you run into trademark problems
danc: It's in CR (widget packaging & config)
noah: If they want to write a great iphone app this is a dumb way to do it
lm: The failure hasn't happened because the 2 years haven't passed (you name a capability by the implementation, and there's no extensibility story, then within 2 years you'll have kludges)
jar: +1 to LM
<noahm> I'm not convinced we're seeing that problem is happening. Yet.
danc: The spec says, URIs go here
<noahm> I'm sympathetic to watching for this trouble happening; I'm unenthusiastic about getting the TAG all geared up about this until we see trouble brewing.
danc: The install time ritual says, this app wants to look at x, y, z
<johnk> +1 to Noah
danc: The spec only says put URIs
here
... Maybe there will be a marketplace... but maybe the gorilla gets
in there, and everyone else has to pretend to be the gorilla
noah: It's not the user-agent string case
danc: No, not interestingly different
<noahm> I'm not convinced it's underspecified.
lm: If there's part of a spec that's underspecified, and that part need specifications for interoperability, we (TAG) could say so
<johnk> I think the basis for the widget spec is exactly _for_ interoperability
timbl: Expecting that probably , there will be the equivalent of a mime type registry
<noahm> I think there will be much more diversity here than for mime types.
timbl: current frame, focal length, lots of profiles to talk about... w3c may get involved
noah: The tough thing is there's lots
of innovation going on... would have been bad for standardization
to rule out multitouch
... the fact that it's a URI is good
<DanC_> (given that the players in this space seem to be acting in good faith, I'm ok to accept the 100-pound-gorrilla name-mangling risk; I'm OK to hope for a healthy market)
lm: I don't want a solution, I just want to ask the question: What is the migration path e.g. from one pointer to two?
danc: Maybe people will come to W3C to get a URI?
lm: We'd like to see, if they have a solution, let's get it documented better. If not, let's work on one.
<DanC_> Larry, if you want an action, you can pretty much always assign yourself one. or you can nominate somebody.
<Zakim> noahm, you wanted to ask about use of core mechanisms like URIs in the Tim use case and to talk about innovation vs. standardizatoin in this space and to ask about use of core
lm: Not sure I want to engage widget folks again
noah: The maps could be more
sophisticated... (that's what Tim was saying...) telling a story
about naming and identity is important. Is there agreement on when to
mint a URI, how much client/server AJAX flexibility is, who knows
what the URIs are. Very interesting area to work.
... TAG story: identity, interaction, formats
danc: Identity per noah is a big story
(scribe hears "semantics" when noah says "identity")
noah: Portals ...
<DanC_> DanC: it's interesting to me in that it includes/subsumes the concern I have about "proposal to make ajax crawlable". If success can be less than the whole thing, I'm all for it.
<Zakim> timbl, you wanted to say that for that class of application (map, iTune, document mgt, iPhoto, calendar, timelines, etc) there typically are *not* URIs for the total view.
<noahm> Are not and should not be, or are not but there should be?
timbl: Noah asked, do people make up
URIs for the views?
... Not in general.
... If so, the URIs get big.
... Tabulator students took a sparql query to encode a view.
... When URIs get too big, they invent a data format.
(jar promises to be brief)
<Zakim> jar, you wanted to talk about the US civil war and to talk about sparql-over-GET + tinyurl
JAR: In nearly every part of this discussion, I see us dancing around, meaning, inference, and contracts.
JAR: Want to encourage people to look at OWL, which is the W3C technology in the inference space (and it's very nice)
DC: there's a consortium of URL shortening companies
noah: I said, identification is something we could profitably work on
jar: 'Identification' is meaningless without meaning / inference
(discussion of agenda)
jar: re OWL, e.g. a specification induces a class of conforming entities. that's DL. one of many possible applications.
<noahm> . ACTION: Noah to do just a bit of work framing some issues around identification for Ajax apps (remembering the merged maps use case) Due 20 January 2009
johnk: Approach of starting with 3 pillars of webarch is good
<noahm> ACTION: Noah to do just a bit of work framing some issues around identification for Ajax apps (remembering the merged maps use case) Due 20 January 2009 [recorded in http://www.w3.org/2001/tag/2009/12/09-minutes.html#action05]
<trackbot> Created ACTION-353 - Do just a bit of work framing some issues around identification for Ajax apps (remembering the merged maps use case) Due 20 January 2009 [on Noah Mendelsohn - due 2009-12-16].
jar: spec / interface naming /v ersioning is one good focus, security is another
danc: Minions, please check client side storage design and look for architectural issues
ashok: web databases?
danc: yes
<DanC_> . ACTION ashok review client side storage apis (web simple storage etc.), looking for architectural issues or other critical problems... or interesting design features the TAG should know about
<DanC_> ACTION ashok review client side storage apis (web simple storage etc.), looking for architectural issues or other critical problems... or interesting design features the TAG should know about
<trackbot> Created ACTION-354 - Review client side storage apis (web simple storage etc.), looking for architectural issues or other critical problems... or interesting design features the TAG should know about [on Ashok Malhotra - due 2009-12-16].
johnk: I could try to map AWWW section on interaction to parts of webapps TOC that seem related
noah: Interesting, but how about look at interaction story in webapp & findings, and ask: could I tell the Ajax story?
johnk: Yes, I was trying to be more specific, but that's the idea
<noahm> . ACTION john to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications
<noahm> ACTION john to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications due: 2 Feb 2010
<trackbot> Created ACTION-355 - Explore the degree to which AWWW and associated findings tell the interaction story for Web Applications due: 2 Feb 2010 [on John Kemp - due 2009-12-16].
<noahm> ACTION-355 = john to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications
<noahm> ACTION-355: john to explore the degree to which AWWW and associated findings tell the interaction story for Web Applications
<trackbot> ACTION-355 Explore the degree to which AWWW and associated findings tell the interaction story for Web Applications due: 2 Feb 2010 notes added
<DanC_> action-355 due 2 feb 2010
<trackbot> ACTION-355 Explore the degree to which AWWW and associated findings tell the interaction story for Web Applications due: 2 Feb 2010 due date now 2 feb 2010
lm: Do we have an exit strategy for
ISSUE-50?
... The goal of Henry's action is to close the issue, right?
all: yes
Adjourned until 0900 2009-12-10