Minutes of the 7th May TAG teleconference

With apologies for the delay due to my travel, the minutes from the  
7th May 2009 teleconference are available at
http://www.w3.org/2001/tag/2009/05/07-minutes.html

A text copy is included below:

Regards,

- johnk

  - DRAFT -
TAG Conference Call
07 May 2009

Agenda

See also: IRC log
Attendees

Present
     John_Kemp, T._V._Raman, Ashok_Malhotra, Henry_Thompson,  
Noah_Mendelsohn, Larry_Masinter, Dan_Connolly, Tim_Berners-Lee,  
Jonathan_Rees
Regrets
Chair
     noah
Scribe
     johnk

Contents

     * Topics
          1. Convene
          2. Minutes Approval
          3. Administration
          4. nameSpaceState-48
          5. Issue IRIEverywhere-27
          6. webApplicationState-60
     * Summary of Action Items

<scribe> scribe: johnk
Convene

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
Minutes Approval

noah: cannot approve minutes of 2nd
... propose to approve 23rd minutes

RESOLUTION: approve minutes of 23rd April
Administration

noah: reminds he has sent a summary of matreial
nameSpaceState-48

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?
issue IRIEverywhere-27

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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/263

noah: tracking this now under IRIEverywhere-27
... shepherd?

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?

<DanC> http://www.w3.org/html/wg/href/draft-ietf.xml and http://www.w3.org/html/wg/href/draft-ietf.html

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> http://www.google.com/search?q=%E9%9D%92%E5%B1%B1&ie=utf-8&oe=utf-8 
,

<noah> "ie" indicates input encoding (i.e. what's sent to the server,  
and "oe"

<noah> indicates output encoding (what should be sent back).

from: http://lists.w3.org/Archives/Public/www-tag/2009May/0001.html

<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

submit

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"

<timbl> "Big5"?

danc: baidu uses big5
... put in some chinese chars, go over wire percent-encoded

<jar> 香蕉

danc: one of the links on that page is then copied into some other  
document

<timbl> http://www.baidu.com/s?wd=%D3%DA%B0%D9%B6%C8+

danc: href=... (encoded chinese)

noah: hex-encoded?

danc: good question - think not
... that uri might get passed to a script

<timbl> http://www.baidu.com/

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

Big5: http://en.wikipedia.org/wiki/Big5

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.

<noah> Help?

lmm: gives some syntax, but there is a separate set of advice on how  
to ship around URIs

<DanC> (I count 2)

<DanC> ah.

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'

ashok: abstain

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

<jar> !

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

<DanC> action-265?

<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> http://www.w3.org/2001/tag/group/track/actions/265

<trackbot> ISSUE-60 -- Web Application State Management -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/issues/60
webApplicationState-60

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

<DanC> "disappear"?

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
... poll
... 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?"

noah:

yes

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

lmm: yes
... 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

(adjourned)

<timbl> Thank you, Noah
Summary of Action Items
[NEW] 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 
]
[NEW] 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 
]

[End of minutes]

Received on Friday, 15 May 2009 12:26:33 UTC