See also: IRC log
<scribe> scribe: johnk
noah: any regrets?
ht: might not be here next week
<timbl> Regrets for May 21
ht: definite regrets for next week
noah: Jonathan can scribe
noah: cannot approve minutes of 2nd
... propose to approve 23rd minutes
RESOLUTION: approve minutes of 23rd April
noah: reminds he has sent a summary of matreial
noah: gives background regarding Norm's draft
... Norm prefers not to drop entirely
<jar> it's short!
noah: resolve this issue in email
timbl: don't want to drop this either
<ht> +1 to publishing as a REC
noah: in addition to not dropping, do we want to have people invest time in this issue?
lmm: does XML Core WG have an opinion on this issue?
<ht> I have scanned 2009/04/02-minutes.html, and am happy with them
noah: suggest we solicit feedback on this issue in email
<ht> [Larry, a minor point -- I find the timestamps very distracting, can you turn them off next time, please?]
lmm: suggest an action to contact XML Core WG
ht: agree would be a good idea to contact them
lmm: if XML Core wants us to work on this, then we should, if not, then we shouldn't
noah: suggest email discussion to be followed by a future agenda item
... will anyone take this action?
noah: (gives background)
... significant concern was that 5 drafts were in roughly the same space
... ht took an action to review these drafts and find their relation
ht: action is pending review
<trackbot> ACTION-263 -- Henry S. Thompson to summarize LEIRIs and "4 specs" in mail to www-tag -- due 2009-04-28 -- PENDINGREVIEW
noah: tracking this now under IRIEverywhere-27
lmm: I will be the shepherd
noah: Henry - would you like to lead this?
<DanC> (I did more formatting work this AM, fwiw. )
<noah> Dan, formatting on your draft with MSM?
ht: (talks about recent Connolly/Sperberg-McQueen draft)
<DanC> (Internet Draft ~= WD; Proposed Standard ~= Candidate Rec; Draft Standard ~= Proposed Rec; Standard ~= Rec)
ht: asked Martin Duerst to clarify where we stand with IRIbis
... so far he hasn't
... what to do next?
<ht> So where on that list does having an RFC number come in?
<Zakim> DanC, you wanted to look at Martin's response http://lists.w3.org/Archives/Public/www-tag/2009May/0001.html
<timbl> The .xml gives me "This XML file does not appear to have any style information associated with it. The document tree is shown below."
<timbl> by the way
<DanC> as designed
timbl: idea that if you find something hex encoded is actually UTF-8 is actually wrong
<noah> Dan: requirement is about non-Western search service, but I don't understand it very well. Tim do, you know about URIs from Baidu.com.
<noah> Tim: HTML meeting at TPAC. The machinery for HTMl URLs can generate things that look like encoded IRIs but are not. So, you cannot assume that anything hex encoded is UTF-8 is not true.
<timbl> This is because the HTML system has its own way of encoding params from HTML forms into URIs
<noah> Tim: HTML meeting at TPAC. The machinery for HTMl URLs can generate things that look like encoded IRIs but are not. So, the assumption that anything hex encoded is UTF-8 is not true.
<ht> DanC, draft-ietf.html looks better, but still two major problems: 1) it's not well-formed (try ,validate); 2) the scope of ed-notes is still unclear
DanC: Martin's reply is more coherent
<noah> Can we copy the quote just read into our minutes here?
<noah> Well, the problem is that when a server gets data (in a path component,
<noah> and even more in a query part), they need to know what encoding it is to
<noah> make sense of it and provide a reasonable answer. The reason why you are
<noah> calling this the "search engine" problem may be that this problem is
<noah> most prominent with search engines, because everybody agrees that people
<noah> want to search in their language, not limited to US-ASCII.
<noah> But it applies to any kind of query parts.
<noah> Some search engines have their own way to passing encoding information,
<noah> as an example, in
<noah> "ie" indicates input encoding (i.e. what's sent to the server, and "oe"
<noah> indicates output encoding (what should be sent back).
<timbl> The HTML form convention is that the text in the text input field is in the same chset as the page istelf, and when the parameters is encoded in a URI, the same encoding as te HTML page is used.
DanC: firefox implemented it per IRI spec
<DanC> (the best way to slow down is to make test cases. here's hoping I find time)
DanC: two paths in their code.
<DanC> Martin's "Currently..." para bears out my experience with flags in mozilla
noah: when you say implement the IRI spec - assume that this is independent of content-type used to encode form
Danc: href youre looking at is inside a doc
with some encoding
noah: it's not any old anchor, it's on a form
timbl: you have to encode what someone types in, in the language in which they're typing
... local encoding is used
danc: then someone bookmarks the URL
timbl: if someone follows bookmark, browser assumes UTF-8 and gets garbage
danc: HTML5 says don't do that, use "Big5"
danc: baidu uses big5
... put in some chinese chars, go over wire percent-encoded
danc: one of the links on that page is then copied into some other document
danc: href=... (encoded chinese)
danc: good question - think not
... that uri might get passed to a script
danc: even though script is in utf8, browser has to keep track of "big5" encoding
<Zakim> masinter`, you wanted to talk about IRI specs and normative behavior and to separate out: definition of protocol element(s) -- Web Address, LEIRI, IRI -- behavior of form
lmm: comment about distribution of guidelines across specs.
... some material might be misplaced
... moving the guideliens aroiund might make things clearer
lmm: URI document defines at least 3 protocol elements
<noah> Chair is starting to wonder what next steps are going to be after this discussion lurches to a local minimum.
lmm: gives some syntax, but there is a separate set of advice on how to ship around URIs
<DanC> (I count 2)
lmm: some of these things refer to full URI which allows a fragment, some to one without a frag
... you can send a path without a fragment or a full URI without a frag
... IRI doc could restrict itself to defining protocol elements
... other specs. could discuss behaviour
... how to take a form and data entered into a form
... if method is GET turn form submit URL into URI/IRI
... advice is more behavioural than protocol-related
noah: let's step back here
... we took note of DanC/Michael's document
... we noticed there were several specs. in this space
... view this discussion as fact-finding on baidu space
... noted Larry's comments
... should the TAG do more now?
DanC: interested to go around the table?
noah: what, if anything, should the TAG do in this space in the next few weeks?
don't feel sufficiently informed, so abstain
raman: don't know what the TAG should do over and above what Dan is already doing
... suggest 'nothing'
ht: only body which is in position to do more in this area is us!
... not sure how to make something happen here
... but something needs to happen
... we should have a meta-discussion
... what should happen here, and what can the TAG do?
lmm: getting better clarity around URIs on the Web is one of the more important areas of Web arch
... worried about it myself, and would be delighted to have fellow worriers
noah: we can schedule future discussion but is there anything more concrete?
lmm: willing to take an action to work with Dan to get a list of tech issues
danc: need this audience to checkpoint my work
... seems some people are involved, and would like to take away reasons for others who abstained
noah: schedule discussion for next week, or wait till next draft?
danc: Larry's action seems to be useful to me
noah: wait for progress on action
jonathan: not sure I can contribute, but if Dan writes something clear I would be happy to review
noah: hearing interested concensus
timbl: priority is to describe current situation
<DanC> (ah... yes... if LMM's action morphed to "work with ht and DanC on (a) some orientation paragraphs, (b) some issues/test cases" that would be optimal, I think)
timbl: henry suggested "how the world could be better"
... and how to get there, if possible
... tag set the expectation that IRIs and URIS could be interchanged, and now we have situation where they are not
... should describe this
ht: on the specific question of what should happen to make things better. I meant that there is only one spec. going forward and everyone agrees
timbl: that is one good area to tackle
<DanC> (when did the TAG set the expectation they could be interchanged? Some of us repeatedly said they could not all along.)
timbl: maybe we can draw the line on where we expect to have IRIs?
... if you have some things encoded, you can't use it in certain places?
... or all docs. use UTF-8?
... don't have hopes of any of these things right now
<noah> jk: i'll be happy to review what Dan produces
noah: my answer will be factored into my proposal
... I think I want to key on Larry, Dan and others to frame the technical issues
... heard input on what those issues were from timbl
... Dan said he finds this useful
... propose assign an action to Larry,. Dan to do the analysis
... any better/other suggestions?
<scribe> ACTION: DanC to work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire [recorded in http://www.w3.org/2009/05/07-tagmem-minutes.html#action01]
<trackbot> Created ACTION-265 - Work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire [on Dan Connolly - due 2009-05-14].
<DanC> action-265 due in 2 weeks
<trackbot> ACTION-265 Work with Larry, Henry to frame technical issues relating to the various overlapping specs. about URIs, IRIs and encoding on the wire due date now in 2 weeks
<trackbot> ACTION-265 -- Dan Connolly to work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire -- due 2009-05-14 -- OPEN
<trackbot> ISSUE-60 -- Web Application State Management -- OPEN
noah: we published a WG, so what should we do next?
... Ian reminded us about patent exclusion disclosures
... check with Ian/lawyers about patents as we are considered "invited experts"
<Zakim> DanC, you wanted to suggest aiming for Note
noah: understood group wants to move this draft to REC
raman: this is about coming up with best practices
raman: but w3c has nothing between 'note' and 'rec'
DanC: notes don't disappear
<timbl> Note sounds good to me
lmm: we might want to get some clarifications, but if you have nothing normative, then no "essential claim" possibilities
noah: question is still about whether we call this a rec
lmm: I defer to Dan on w3c process issues
do we need to make this decision now?
noah: some pressure to do patent disclosures if we go for 'rec'
timbl: what is a "TAG finding"?
... what's wrong with making this a finding?
noah: maybe nothing...
... we did discuss how to get more visibility, and 'rec' is one way to do that
... propose we take this to email
... would like to see more work in this area
I guess the question is "what level of interest is there in seeing this work pursued?"
ht: yes, but have no cycles
danc: html media type needs to be updated
... challenge is to get it reviewed by relevant audience: jquery, dojo et al
timbl: work is valuable, and would like to wrap it up
... we tell story in WWW + findings
... make it a finding
... then, what should we do to assembled what we've produced into a new arch doc?
noah: next f2f might be a place to discuss assemblage of findings into arch doc
see value to this work, should keep going
ashok: see value to this as note or finding
lmm: would like a more formal external review, ie. outside of TAG
... worth being a rec, but needs broader review, AC approval and so on
noah: sounds like a suggestion to go to REC
... important part of web arch
noah: hearing "yes, let's keep working on this"
raman: don't see the difference between doing this as a personal blog post and doing this as TAG finding
timbl: TAG findings have a role in Web community
noah: findings have a formal goal
raman: not seeing much momentum in this work
... (seeing this as perhaps a larger problem with recent findings)
noah: asking what is the next step, and if no-one is willing to help, then I can see how you would be frustrated?
raman: prepared to see what happens
noah: give this some thought - if you can figure out what next steps are, then lets discuss at f2f
lmm: let's send out a note saying we're going to review it, and would appreciate external comment
ashok: good idea
<scribe> ACTION: noah to send a note to www-tag pointing out that discussion is open on the WD for ISSUE-60 [recorded in http://www.w3.org/2009/05/07-tagmem-minutes.html#action02]
<trackbot> Created ACTION-266 - Send a note to www-tag pointing out that discussion is open on the WD for ISSUE-60 [on Noah Mendelsohn - due 2009-05-14].
lmm: summarize versioning work
... reviewed Dave's draft and wanted to reconcile work from there - wanted to see whether I was going in a "new" direction
noah: can you look at background reading in this agenda and modify it if necessary?
... propose to adjourn
<timbl> Thank you, Noah