/irc-logs / w3c / #html-wg / 2010-02-12 / end

Options:

  1. # Session Start: Fri Feb 12 00:00:00 2010
  2. # Session Ident: #html-wg
  3. # [00:35] * Quits: plh (plh@128.30.52.28) (Quit: always accept cookies)
  4. # [00:38] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  5. # [01:01] * Joins: miketaylr (miketaylr@204.145.67.146)
  6. # [01:06] * Quits: Julian (chatzilla@217.91.35.233) (Ping timeout)
  7. # [01:07] * Joins: Julian (chatzilla@217.91.35.233)
  8. # [01:26] * Quits: tlr-bbl (tlr@128.30.52.169) (Quit: tlr-bbl)
  9. # [02:27] * Quits: miketaylr (miketaylr@204.145.67.146) (Quit: Leaving...)
  10. # [03:49] * MikeSmithX is now known as MikeSmith
  11. # [04:30] * Quits: drunknbass_work (aaron@71.106.110.90) (Ping timeout)
  12. # [04:43] * Joins: J_Voracek (irchon@166.205.11.208)
  13. # [04:44] * Quits: J_Voracek (irchon@166.205.11.208) (Client exited)
  14. # [05:18] * Quits: MikeSmith (MikeSmith@114.48.55.145) (Ping timeout)
  15. # [05:24] * Joins: MikeSmith (MikeSmith@114.48.128.185)
  16. # [05:42] * Joins: miketaylr (miketaylr@24.42.95.234)
  17. # [05:53] * Joins: drunknbass_work (aaron@76.173.195.145)
  18. # [06:33] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
  19. # [06:52] * Quits: drunknbass_work (aaron@76.173.195.145) (Quit: Leaving...)
  20. # [08:06] * Quits: masinter` (user@98.207.107.29) (Client exited)
  21. # [08:42] * Joins: drunknbass_work (aaron@76.173.195.145)
  22. # [09:20] * Quits: Yudai (Yudai@61.120.190.89) (Quit: SIGTERM received; exit)
  23. # [09:20] * Joins: Yudai (Yudai@61.120.190.89)
  24. # [09:26] * Lachy_ is now known as Lachy
  25. # [09:54] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  26. # [10:14] * Joins: Lachy (Lachlan@88.131.66.80)
  27. # [10:25] * Joins: tlr (tlr@128.30.52.169)
  28. # [10:41] * Joins: ROBOd (robod@89.122.216.38)
  29. # [10:52] <Julian> hixie: bs
  30. # [10:53] <Julian> Larry didn't object to the publication of HTML5.
  31. # [10:55] * mjs wonders what Julian is responding to
  32. # [10:56] <Hixie> he didn't object to what you call HTML5
  33. # [10:56] <Hixie> he objected to what everyone outside the w3c calls HTML5
  34. # [10:56] <Julian> the blog at http://ln.hixie.ch/
  35. # [10:57] <Julian> that's what I said "bs". Stop spreading confusion about what HTML5 is.
  36. # [10:57] <Hixie> i think it's the w3c doing the confusing part of this :-)
  37. # [10:57] <Hixie> you preach consensus right?
  38. # [10:57] <Julian> In WhatWG, you can publish whatever you want, and Larry's objections do not apply to that.
  39. # [10:58] <Hixie> this really has nothing to do with the whatwg
  40. # [10:58] <Julian> In the W3C WG we have *one* spec that is called "HTML5", and as far as I can tell, there are no objections to publish that
  41. # [10:58] <mjs> There was an objection in Member-only space to 3 of the 6 currently proposed publications, before even the Call for Consensus
  42. # [10:59] <Hixie> Julian: yeah, but the w3c spec called "html5" is only a subset of what the web calls html5, so if you care about consensus, you should be arguing that we should be renaming it to match what the bulk of people think it means
  43. # [10:59] <Julian> So is there an objection to publish a new HTML5 draft? If there is, I apologize, because I don't have access to that information in member space.
  44. # [11:00] <Julian> I care about the consensus in *this* WG
  45. # [11:00] <Hixie> uh
  46. # [11:00] <Hixie> wait
  47. # [11:00] <Hixie> what?
  48. # [11:00] <mjs> however the Chairs are unlikely to seek publication of only half of the proposed documents
  49. # [11:00] <Julian> As far as I can tell it's you causing the confusion by calling things "HTML5" which aren't.
  50. # [11:00] <Hixie> you don't care about consensus of the broader web community?
  51. # [11:01] <mjs> thus, the Member-only objection, if not sufficiently resolved by the time we request publication, will effectively block publication of HTML5
  52. # [11:01] <Julian> I don't know how to measure that consensus
  53. # [11:01] <Hixie> but you do know how to measure the consensus of a group of 300+ people?
  54. # [11:01] <Julian> Maciej, but that's the chair's choice, right?
  55. # [11:01] <mjs> when some people say HTML5 they include even things that were never in any document that called itself HTML5
  56. # [11:02] <Julian> Yes, that's a problem.
  57. # [11:02] <Hixie> geolocation is in "html5" according to the wider web definition of html5
  58. # [11:02] <Julian> Yes, that's a problem
  59. # [11:02] <Hixie> (whatwg has given up on the term "html5", btw, so don't blame the whatwg for this)
  60. # [11:02] <hsivonen> SVG is a part of the HTML5 family of technologies
  61. # [11:02] <mjs> straightening that out does not really seem possible at this point
  62. # [11:02] <Hixie> but man, i didn't realise you really only cared about consensus of a small group of people
  63. # [11:02] <mjs> HTML5 has become a buzzword for the new generation of Web technologies
  64. # [11:02] <Julian> Anyway, again:
  65. # [11:02] <Hixie> that makes consensus an even more ridiculous persuit
  66. # [11:03] <Julian> As far as I can tell, there was no objection to publish a new HTML5 draft. Claiming so clearly is BS.
  67. # [11:03] <mjs> I would prefer if people used the term with more precision, but I think changing it is hopeless
  68. # [11:03] <Hixie> microdata is part of html5, and adobe objected to publishing it. i stand by my statement without any reluctance.
  69. # [11:04] <mjs> it's pretty clear that even when Adobe refers to "HTML5" they refer to something broader than the HTML5 draft proper
  70. # [11:04] <Hixie> indeed
  71. # [11:04] <Julian> Hixie, unrelated:
  72. # [11:04] <mjs> at least, from reading many of the blog posts saying how much they are going to support it in tools and all
  73. # [11:05] <Julian> repeating what RFC 2616 says about following redirects is problematic.
  74. # [11:05] <Julian> There's an approved erratum about this
  75. # [11:05] <Julian> which clarifies that it's not specific to GET and HEAD, but to safe methods
  76. # [11:05] <Julian> copying the bug into the HTML5 spec isn't helpful
  77. # [11:05] <Hixie> well, the browsers don't implement that in practice anyway
  78. # [11:06] <Hixie> they redirect POSTs without prompting, for instance
  79. # [11:06] <Hixie> see the recent whatwg thread
  80. # [11:06] <anne> but they turn it into GET iirc
  81. # [11:06] <anne> though maybe not for 307?
  82. # [11:06] <anne> hmm
  83. # [11:06] <Hixie> not always
  84. # [11:06] <Hixie> it's kinda complicated
  85. # [11:06] <Hixie> i figure either html5 or http needs to define it
  86. # [11:07] <Hixie> i expect it'll have to be html5 since i doubt http will want to do browser-specific stuff here, since they wouldn't even drop Content-Location, but maybe Julian knows otherwise?
  87. # [11:07] <mjs> I should probably object to the requirement to prompt the user when redirecting an unsafe method
  88. # [11:07] <mjs> since it's inappropriate to have user interface requirements in a protocol spec
  89. # [11:07] <Julian> The problem with Content-Location has been fixed for some time now.
  90. # [11:08] <Julian> It can't be removed, because it's in use. We told you that lots of times.
  91. # [11:08] <Hixie> really?
  92. # [11:08] <Hixie> oh
  93. # [11:08] <Hixie> so when you say "fixed" you mean "not fixed"
  94. # [11:08] <Hixie> ok
  95. # [11:08] <Julian> The issue with redirects has a associated bug
  96. # [11:08] <Julian> What I mean is that we dropped the base-setting requirement.
  97. # [11:09] <Julian> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
  98. # [11:09] <mjs> Julian: which HTTPbis draft did the definition of status codes (specifically the 3xx codes) end up in?
  99. # [11:09] <Hixie> so what UA requirements remain?
  100. # [11:09] <Hixie> for content-location?
  101. # [11:09] <Julian> Maciej: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html
  102. # [11:10] <Julian> Maciej, earlier on you said "6 drafts". I only see 5 in the CfC.
  103. # [11:11] <mjs> Julian: diffs is the 6th
  104. # [11:11] <mjs> Sam mentioned it in a slightly different way
  105. # [11:11] <Julian> Ah, I see
  106. # [11:12] <Julian> Hixie, as far as I can tell there's no UA requirement here; it can ignore the header (which doesn't mean it's useless)
  107. # [11:13] <Hixie> ah
  108. # [11:13] <Hixie> so how is it useful?
  109. # [11:14] <Julian> it is useful for conneg
  110. # [11:14] <anne> i guess about as useful as <a media>
  111. # [11:14] <anne> oh, maybe less :)
  112. # [11:14] <Hixie> how does it help with content negotiation?
  113. # [11:14] <Hixie> i don't understand
  114. # [11:15] <Julian> I see you don't. For some reason, I'm not in the mood for doing HTTP lectures right now. It's in the spec. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-latest.html#rfc.section.5.7
  115. # [11:16] * Joins: MikeSmithX (MikeSmith@114.48.81.236)
  116. # [11:18] * anne doesn't really get the spec
  117. # [11:18] * Quits: MikeSmith (MikeSmith@114.48.128.185) (Ping timeout)
  118. # [11:19] <Hixie> so it means "there's another copy of this over there"?
  119. # [11:20] <Hixie> i wonder what problem that solves
  120. # [11:20] <Julian> it means "here is more specific URI"
  121. # [11:20] <Hixie> it seems like as metadata goes, it'll be pretty unreliable given the numerous servers that return bogus values
  122. # [11:20] <Hixie> i guess it's a bit like rel=bookmark
  123. # [11:21] <Hixie> (though less likely to be used by UAs)
  124. # [11:21] <Julian> It's mainly useful for authoring, in which case the servers are probably better in returning correct values
  125. # [11:22] <Hixie> wouldn't a Link: with rel=bookmark be better?
  126. # [11:23] <Hixie> anyway, glad to know you dropped that header for all intents and purposes
  127. # [11:23] <Hixie> excellent news
  128. # [11:23] <Hixie> please make the redirect stuff mentioned earlier rational too :-)
  129. # [11:23] <Julian> It's clear that you see this from the browser point of view. thus you miss part of the story. Just do not pretend you do.
  130. # [11:26] <hsivonen> Julian: what would be an scenario with software today where Content-Location is processed in a useful way?
  131. # [11:27] <Hixie> i miss part of the story but do not pretend i do? what?
  132. # [11:27] <Julian> PUT to a content-negotiated resource.
  133. # [11:28] <Julian> Interpreting POST response bodies (http://greenbytes.de/tech/webdav/rfc5023.html#rfc.section.9.2)
  134. # [11:29] <Julian> Intepreting PATCH response bodies (http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-16.html#rfc.section.2.p.7)
  135. # [11:32] <hsivonen> Julian: why would the HTTP client POST or PATCH to a conneg URI with Content-Location instead of doing the POST or PATCH to the URI that would be given by Content-Location in the other scenario?
  136. # [11:33] <Julian> these were different examples
  137. # [11:33] <Julian> the first one was about finding the URI you can author
  138. # [11:33] <Julian> the other two cases were about something else
  139. # [11:40] * Joins: myakura (myakura@123.224.228.213)
  140. # [11:50] * Joins: Michelangelo (Michelange@93.42.98.120)
  141. # [13:00] * Quits: drunknbass_work (aaron@76.173.195.145) (Quit: Leaving...)
  142. # [13:10] * Quits: Julian (chatzilla@217.91.35.233) (Ping timeout)
  143. # [13:10] * Joins: Julian (chatzilla@217.91.35.233)
  144. # [13:28] * anne wonders what a server ought to do if a client does a PUT request that includes a content-location header
  145. # [13:31] * Julian replies: just read the spec (in this case: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-08.html#rfc.section.5.7.p.8)
  146. # [13:31] <Philip> "The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases." ?
  147. # [13:31] <anne> did you read the section on PUT Julian?
  148. # [13:32] <Julian> which? P2?
  149. # [13:32] <anne> the part that says "The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases."
  150. # [13:33] <Julian> open issue, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/79
  151. # [13:34] <mjs> that issue seems to cover Content-Language, not Content-Location
  152. # [13:34] <Julian> btw: I appreciate this; HTTPbis is work-in-progress, and the more review, the better
  153. # [13:34] <Julian> "Content-* vs. PUT"
  154. # [13:34] <Julian> Content-Language is mentioned as an example
  155. # [13:35] <mjs> I would add a comment saying the same issue applies to Content-Location if I had an account on that trac server or knew how to get one
  156. # [13:36] <mjs> though mnot's suggested solution would equally address Content-Location in any case
  157. # [13:37] <Julian> yes, the authors are fully aware that this is not specific to Content-Language, thus the title
  158. # [13:39] <mjs> is it possible for arbitrary people (or at least arbitrary HTTPbis WG participants) to comment on a ticket?
  159. # [13:39] <mjs> or is it just a reminder tool for editors or something?
  160. # [13:40] <mjs> I am not familiar with standard IETF practice on this
  161. # [13:41] <Julian> there's no IETF standard practice for that
  162. # [13:41] <Julian> in httpbis, we use the tracker only internally among the authors
  163. # [13:41] <Julian> new issues and comments should be sent to the mailing list
  164. # [13:41] <mjs> ok
  165. # [13:42] <Julian> we want to avoid that discussions move from the mailing list into the bug tracker
  166. # [13:42] * Quits: arronei (arronei@131.107.0.74) (Ping timeout)
  167. # [13:42] <Julian> in which case we would need to send change notifications to the mailing list
  168. # [13:43] <Julian> that being said: I'm happy to add comments if you think something needs to be added
  169. # [13:43] <mjs> I don't care much about this one, was just wondering about the general question
  170. # [13:43] <mjs> I should ask someone the analogous question about http-state
  171. # [13:43] <Julian> in which case please send to the mailing list, incl the issue number, and the proposed text
  172. # [13:44] <Julian> I do agree this may be confusing
  173. # [13:44] <mjs> I usually prefer to submit comments via a tracking system when I can, because it's easier for me to track what feedback I have that is pending a response
  174. # [13:44] <mjs> but I am also fine with using mailing lists to comment
  175. # [13:45] <Julian> it would be nice if we could interface Trac to the mailing list in a similar way the W3C Tracker does
  176. # [13:48] * Joins: arronei (arronei@131.107.0.69)
  177. # [14:02] <Julian> Anne, note "[Note that this file is a concatenation of more than one RFC.]"
  178. # [14:09] <anne> very confusing
  179. # [14:12] <Julian> the default publication format doesn't help reducing the confusion
  180. # [14:42] * tlr is now known as tlr-bbiab
  181. # [14:55] * Joins: aroben (aroben@71.58.77.15)
  182. # [14:58] * Quits: Michelangelo (Michelange@93.42.98.120) (Client exited)
  183. # [15:28] * Joins: plh (plh@128.30.52.28)
  184. # [15:34] * Joins: aroben_ (aroben@71.58.77.15)
  185. # [15:34] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  186. # [15:44] * Joins: miketaylr (miketaylr@38.117.156.163)
  187. # [16:03] * Quits: Yudai (Yudai@61.120.190.89) (Quit: SIGTERM received; exit)
  188. # [16:04] * Joins: Yudai (Yudai@61.120.190.89)
  189. # [16:09] * tlr-bbiab is now known as tlr
  190. # [17:18] * Quits: MikeSmithX (MikeSmith@114.48.81.236) (Ping timeout)
  191. # [17:25] * Joins: MikeSmithX (MikeSmith@114.48.60.105)
  192. # [17:58] * Quits: myakura (myakura@123.224.228.213) (Quit: Leaving...)
  193. # [18:23] * Joins: Michelangelo (Michelange@93.42.98.120)
  194. # [18:31] * Joins: J_Voracek (irchon@166.205.9.112)
  195. # [18:31] * Quits: J_Voracek (irchon@166.205.9.112) (Client exited)
  196. # [19:24] * tlr is now known as tlr-bbl
  197. # [19:34] * Quits: tH (Rob@82.4.89.172) (Ping timeout)
  198. # [19:49] * Joins: drunknbass_work (aaron@71.106.110.90)
  199. # [19:49] * Quits: drunknbass_work (aaron@71.106.110.90) (Quit: drunknbass_work)
  200. # [19:50] * Joins: drunknbass_work (aaron@71.106.110.90)
  201. # [19:51] * Joins: tH (Rob@82.4.89.172)
  202. # [20:52] * Joins: rubys (rubys@98.27.53.108)
  203. # [21:36] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
  204. # [21:41] * Parts: rubys (rubys@98.27.53.108)
  205. # [21:44] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  206. # [22:14] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  207. # [22:25] * Joins: Lachy (Lachlan@81.170.212.11)
  208. # [22:29] * Quits: Lachy (Lachlan@81.170.212.11) (Quit: Leaving)
  209. # [22:29] * Joins: Lachy (Lachlan@81.170.212.11)
  210. # [22:29] * Joins: mjs (mjs@17.246.17.80)
  211. # [22:36] * Quits: Lachy (Lachlan@81.170.212.11) (Quit: Leaving)
  212. # [22:48] * Joins: Lachy (Lachlan@83.170.95.133)
  213. # [22:57] * Quits: tH (Rob@82.4.89.172) (Ping timeout)
  214. # [23:09] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
  215. # [23:14] * Joins: tH (Rob@82.4.89.172)
  216. # [23:18] * Quits: MikeSmithX (MikeSmith@114.48.60.105) (Ping timeout)
  217. # [23:58] * Joins: MikeSmith (MikeSmith@114.48.150.191)
  218. # [23:59] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
  219. # Session Close: Sat Feb 13 00:00:00 2010

The end :)