See also: IRC log
<RjS> RjS is on the bridge via skype-out
<scribe> scribe: plh
Peter: we had a coordination call on Tuesday, this is being kicked off again
... several steps before the Beijing meeting
... Martin and Larry would be more active
... talked to Adam and Ian a couple of weeks ago to discuss where Adam's work should be done
... he is planning to submit an internet draft
... on how browsers should handle IRI/URI/URL
Alexey: we have a new editor for the protocol document, Ian Fette. they made quite a good progress on the mailing list. new version has been published.
... the wg is making progress now
Alexey: talked to candidates for co-chairing. Andy and Alfred are likely to chair
... Andrew Newton
Tlr: you asked in the past with a candidate with w3c experience, what was your motivation?
Alexey: when I asked I didn't know if we would get candidates to chair. this has been resolved. updates to various urn related specs, motly things used by libraries. at some point, the wg would recharter to do some resolution protocol, work on something new, but that's far away at this moment
tlr: ok, something to be aware of then. would bring this back to the table.
John: near term issue is the group is focusing on applications and urns, and on they're being used.
Alexey: draft from Huawei
... reviewing how streaming is done in the wild
... asked to have a mailing list
... was trying to push for a BOF in Beijing, but they don't seem to be ready
... so no BOF there
... we agreed to allow the creation of new mailing list
... this doesn't mean that it would become a working group
<tlr> plh: want to mention that we've been invited to join the mailing list, by Huawei
tlr: some noise in the background about Apple draft. how does it relate?
Alexey: it's in scope. they're trying to figure what they want to do.
<tlr> gonzalo: Apple and Huawei discussing with each other now
Alexey: two sets of documents, one from Apple and one from Huawei
<tlr> plh: see something in my inbox from W3C members interested in this work, pointed Huawei out to them.
<tlr> alexey: specific set of people?
<tlr> plh: samsung, others -- need to look up in inbox
<tlr> ACTION: plh to coordinate with Alexey and Gonzalo re W3C members interested in HTTP streaming work. [recorded in http://www.w3.org/2010/09/16-ietf-irc]
tlr: Harald and Cullen are putting a workshop about how RT and browsers should interact
[...]
<tlr> plh: started out of HTML WG
<tlr> ... there is the <link> element in HTML
<tlr> ... needs to have relations, and the draft is pointing to WhatWG wiki page
<tlr> ... for how to register new link relations
<tlr> ... these are also used at the HTTP layer; Mark has been working on that
<tlr> ... issue was raised that we need to have more stable registry than a wikipedia page
<tlr> ... Mark Nottingham and Julian Reschke worked in IETF to set up IANA registry
<tlr> ... Hixie tested registry, didn't manage to get request registered
<tlr> ... within HTML WG, status is that we have proposal from IETF re registry
<tlr> ... chairs are looking into counter-proposal: "if IETF registry doesn't work, what do we do"
<tlr> mnot: hardly know where to start
<tlr> ... confused by definition of "what doesn't work"
<tlr> ... most of Hixie's registrations were registered because W3C asked us not to register
<tlr> ... he was registering on behalf of WhatWG
<tlr> ... we refused a couple other ones because of personal web site, not stable reference
<tlr> ... said in subsequent discussion that microformats.org or whatwg.org were fine places
<tlr> ... Mike Smith tasked with another test; lots of registrations, some questions about inconsistencies
<tlr> ... Mike was to check back with the WG; think the questions were reasonable
<tlr> ... some frustration here, sought broad input into the registration early on
<tlr> plh: one of the things we'd like to know is -- some of Mike's registrations were accepted
<tlr> ... what's the status?
<tlr> mnot: not accepted. Said preliminarily "these look good". Mike was to make these changes, we're waiting for confirmation
<tlr> ... don't think it's a problem.
<tlr> plh: one batch or one at a time?
<tlr> mnot: large number of e-mails
<tlr> plh: in that case some could move ahead
<tlr> mnot: requested text changes that affect all of them
<tlr> ... also, figuring out how to get the registry working
<tlr> ... we need the community to tell us how they want this to work
<tlr> plh: one of the problems we're facing is that we're asking about stable references
<tlr> ... while they try to run as fast as they can
<tlr> ... frustrations with media type registry in the past
<tlr> mnot: some of the discussion about the parameters is whether there will be a stable document
<tlr> alexey: ownership of certain registrations came up as well
<tlr> plh: clear-cut
<tlr> ... that's why MikeS resubmitted those
<tlr> mnot: he resubmitted. We haven't heard back from him.
<tlr> ... perhaps need to work on process so he knows about status of his registrations.
<tlr> ... can probably work through this
<tlr> plh: will get back to Mike
<tlr> ACTION: plh to get back to MikeS about re-submitted link rel registrations [recorded in http://www.w3.org/2010/09/16-ietf-irc]
<tlr> mnot: note that this is starting up, and we're having another discussion with IANA about publication format.
Alexey: security area draft that was referencing image/svg+xml
... I checked the status and discovered it wasn't registered
... talked to Chris and sent some comments
... one thing that looked not quite right was the multiple file extensions with different transfer encoding of the same mime type. I have the feeling it's against the intent of the mime specs
... I asked opinions at last IETF conference.
... and people raised similar concerns about the registrations
... one additional concern: should be image/svg+xml+gzip or something like that
... there is disagreement about different representations of the same mime type and how it maps to different representations
tlr: on how it maps to content encoding
<ChrisL> http://www.w3.org/2001/tag/2002/0129-mime
Chris: trying to register this media type has been difficult. the TAG has published document that contradicts RFC3023
... we started a revision for RFC3023bis
... meanwhile I tried to register the media type without the charset
... but got rejected pending update on 3023
... update on 3023 is pending due to deprecation of text/xml
... no fix seems possible with the current HTTP spec.
... it's going to take a revision to allow RFC3023bis to work
Alexey: one recent post from co-author of mime type said that it should be revised to deal with the charset situation
chris: that would be helpful indeed. would like to be in the loop.
john: charset issue might get tied into some of our i18n issues
... might be complex
mnot: and we have an open issue on charset in HTTPbis
Chris: other aspect is we registered two file extensions. early on between transfer encoding and content encoding wasn't understood
... different opinion even around gzip
... because of this mess, we created a separate media type with content encoding
... it's not easy for people to configure a server to do transfer encoding
... we introduced the svg way in order to ableviate that
... there is now a lot of deployed implementations using it
... so it's difficult to change. also not convinced that it's wrong from a technical point of view.
<ChrisL> http://www.w3.org/TR/SVGTiny12/conform.html#ConformingSVGServers
mnot: the language around media type makes a lot of sense but not well written from HTTP perspective and raised eyebrows.
chris: I'm aware that there was a mistake in the actual registration. this got fixed.
... Yves Lafon reviewed the new wording and agreed with it.
tlr: quick clarifying question: for a resource of media type image/svg+xml, the file name that shows up in the URI is .svg
... with transfer encoding gzip?
chris: no, with content encoding since it wasn't gzip on the fly
<stpeter> I like that: "the dawn of mime" :)
John: this set of problems goes back far, into original mime content/transfer encoding distinction
Chris: agreed
Alexey: so, is the registration ok as written and do we need to update the registration rules?
John: you can clarify them, as well as HTTP. we create this bizarre .../...+xml as well. don't kinow how to untangle those two things
<ChrisL> rough consensus and running code, right?
tlr: I would suggest an other review of the draft and if ok, the registration goes through...
john: it's worth the try as a description of existing practices. worried about setting up a precedence
tlr: don't think we should put this into the critical path for something already deployed.
john: don't think we're creating a major issue yet but we're digging ourselves deeper
<tlr> ACTION: ChrisL to resubmit image/svg+xml registration request [recorded in http://www.w3.org/2010/09/16-ietf-irc]
<scribe> ACTION: Chris to resubmit image/svg+xml with updated text [recorded in http://www.w3.org/2010/09/16-ietf-irc]
tlr: and expectation would be to get it approve understanding it's current practices
Alexey: I want to know how to act next time I see one of those however. might need a group to look into this.
<ChrisL> I agree that more clearly disambiguating email and http is good - that would affect the mime registration template, I think
<tlr> ACTION: ChrisL and Alexey to discuss future directions for +xml media types, encodings, etc [recorded in http://www.w3.org/2010/09/16-ietf-irc]
Alexey: I'll follow up on the charset issue as well
<tlr> ACTION: Alexey to discuss charset on +xml media types with NedF, JohnK [recorded in http://www.w3.org/2010/09/16-ietf-irc]
<ChrisL> I think math had display and semantic mathmls distinctions
<John_C_Klensin> @plh: What it tried to say was that, while one can try to clarify, we have fundamental problems that result from (1) the clear definition of the Content-type/ Content-transfer-encoding for email and the divergence of the latter into Content-encoding and Transfer-encoding on the web side. (2) the notion that xxx/...+xml was a reasonable, quick, patch that we knew wouldn't work well if...
<John_C_Klensin> ...things got complex... and they have just gotten complex. In retrospect it might have been better to take the time to do XML/... correctly, but we didn't want to spend the time then. Worse, anything we try to do about revising the handling of "charset" will interact with a whole bunch of i18n issues in the IETF and tuning MIME may interact with "the YAM mess". I think that patches to...
<John_C_Klensin> ...get the current outstanding types registered are fine, but we better worry about the longer term and whether the precedents we are setting will make things even worse the next time.
tlr: DAP is working on a device api for calendaring. started to talk to interested parties. some overlap with json serialization.
... it involved cal connect as well
... coordination is happening
tlr: also DAP and JS API. interesting multi-party problem. OMA, W3C, IETF, portable contacts
... there is discussion between portable contacts and vcard folks
... OMA has a spec, asked for review of that spec by IETF and W3C.
... we'll look to see if there is actual convergence
... if there is other parties to pull in, please let me know
Peter: seems like we have enough. vcard 4 is far along. might be helpful for OMA to look at it as well.
... I'll follow that up separately.
tlr: simple solution for us is to have a single format for our API mapping
tlr: there is ongoing discussion in this space for coordination.
tlr: who? started working on privacy guidelines for specifications. Call for participation should go out early next week
<ChrisL> more guidance on security sections would be very welcome
<tlr> there's an RFC on that as well
Alexey: ietf-types will be migrated to ietf site. old address will still work. short period of instability. let ne know if there are issues.
... hope this will get finished later this week
tlr: next IETF meeting is week after TPAC
Alexey: I'll be at TPAC
tlr: so looking for the week before TPAC?
... if enough of us will be in Lyons, we could cancel
mnot: i'll be happy to chair if we make it a little earlier
[adjourned]
<stpeter> tlr: thanks for being such a good host!