IETF
wpack@jabber.ietf.org
Monday, July 26, 2021< ^ >
Jeffrey Yasskin has set the subject to: WPACK https://codimd.ietf.org/notes-ietf-110-wpack
Room Configuration
Room Occupants

GMT+0
[21:05:42] Meetecho joins the room
[21:12:38] Meetecho-alex joins the room
[21:15:03] Alessandro Toppi_web_157 joins the room
[21:15:03] Eric Kinnear_web_601 joins the room
[21:15:18] Sean Turner_web_325 joins the room
[21:17:15] Phillip Hallam-Baker_web_481 joins the room
[21:19:02] Alessandro Amirante_web_710 joins the room
[21:21:39] Takanori Fumeno_web_626 joins the room
[21:21:42] markmcfadden joins the room
[21:22:17] Mark McFadden_web_685 joins the room
[21:22:41] markmcfadden leaves the room
[21:22:41] Rick Taylor_web_455 joins the room
[21:24:04] Bron Gondwana_web_891 joins the room
[21:24:23] Takahiro Nemoto_web_925 joins the room
[21:24:44] Thom Wiggers_web_261 joins the room
[21:25:05] Justin Richer_web_319 joins the room
[21:25:55] Martin Thomson_web_403 joins the room
[21:26:00] Thom Wiggers_web_261 leaves the room
[21:26:04] Thom Wiggers_web_294 joins the room
[21:26:10] කෙසර රත්නායක_web_413 joins the room
[21:26:18] Francesca Palombini_web_635 joins the room
[21:26:33] Ted Hardie_web_525 joins the room
[21:26:40] Thom Wiggers_web_294 leaves the room
[21:26:45] David Lawrence_web_812 joins the room
[21:26:54] francesca joins the room
[21:27:22] Felipe Erias_web_988 joins the room
[21:27:25] Stephan Emile_web_371 joins the room
[21:28:39] <Martin Thomson_web_403> meetecho isn't aware of any slides being available
[21:28:41] Ahmed Aldabbagh_web_526 joins the room
[21:29:13] Jeffrey Yasskin_web_499 joins the room
[21:29:16] <Meetecho> Martin: do you mean the preloaded slides?
[21:29:18] Chi-Jiun Su_web_244 joins the room
[21:29:20] David Oliver_web_813 joins the room
[21:29:24] Chris Lemmons_web_425 joins the room
[21:29:26] David Oliver_web_813 leaves the room
[21:29:27] tale joins the room
[21:29:29] <Meetecho> Chairs need to import them from the settings, to make them available to participants
[21:29:31] Watson Ladd_web_568 joins the room
[21:29:32] Daisuke Enomoto_web_895 joins the room
[21:29:35] <tale > /title IETF 111
[21:29:45] <tale > Well that was effective.
[21:29:50] <Meetecho> Settings (top-right corner) -- Manage Slides
[21:30:02] Xavier de Foy_web_380 joins the room
[21:30:05] Daniel Gillmor_web_891 joins the room
[21:30:05] Meetecho-alex has set the subject to: IETF 111
[21:30:09] Carrick_web_727 joins the room
[21:30:20] Marcus Ihlar_web_904 joins the room
[21:30:22] Darrel Miller_web_524 joins the room
[21:30:22] Devin Mullins_web_308 joins the room
[21:30:23] Philipp Tiesel_web_311 joins the room
[21:30:32] dkg joins the room
[21:30:38] Vasilis_web_296 joins the room
[21:30:39] <Martin Thomson_web_403> oops, I apologize for invoking the m e e t e c h o, that was accidental
[21:30:52] Hayato Ito_web_775 joins the room
[21:30:54] <Bron Gondwana_web_891> sure
[21:31:01] <Martin Thomson_web_403> I've started taking notes, but I'm going to be speaking, I think
[21:31:04] Stephan Emile_web_371 leaves the room
[21:31:06] <Bron Gondwana_web_891> yes, I'll take notes
[21:31:08] Stephan Emile_web_394 joins the room
[21:31:21] Dan Druta_web_350 joins the room
[21:31:25] Dan Druta_web_350 leaves the room
[21:31:39] Kenneth Murchison_web_921 joins the room
[21:31:45] Hiroyuki Goto_web_673 joins the room
[21:31:46] Jonathan Lennox_web_498 joins the room
[21:32:31] Carrick_web_727 leaves the room
[21:32:41] Dan Druta_web_558 joins the room
[21:33:14] Justin Richer_web_319 leaves the room
[21:33:24] jyasskin@jabber.today joins the room
[21:33:28] <Jeffrey Yasskin_web_499> Nope, Felipe's got it.
[21:33:39] Alexey Melnikov_web_529 joins the room
[21:34:49] Youngkwon Lim_web_928 joins the room
[21:34:52] <Alexey Melnikov_web_529> Adopt, but not publish?
[21:35:06] Harald Alvestrand_web_880 joins the room
[21:35:07] <Martin Thomson_web_403> +1 to dropping it
[21:35:12] <Jeffrey Yasskin_web_499> I explicitly have no objection. :)
[21:35:23] ROY Sourav_web_708 joins the room
[21:35:24] Youngkwon Lim_web_928 leaves the room
[21:35:31] <Ted Hardie_web_525> I agree with Alexey; something that indicates it was the view of the wg, but no publication.
[21:35:32] ROY Sourav_web_708 leaves the room
[21:35:56] Daniel Ehrenberg_web_394 joins the room
[21:36:16] <dkg> seems like wpack has gone back and forth over several different possible use cases over the years
[21:36:32] Mike Bishop_web_293 joins the room
[21:36:36] Samer Darras_web_276 joins the room
[21:37:09] <dkg> in the initial proposals there were several use cases that don't seem like they're contemplating any longer.  the complement of the expected use cases (that is, what webpack *doesn't* cover) is also interesting information
[21:37:29] Justin Richer_web_908 joins the room
[21:37:31] <Ted Hardie_web_525> (And then cut before publication?  Or kept in?)
[21:37:57] <Jeffrey Yasskin_web_499> dkg: Want me to say something about that at the mic?
[21:38:10] <francesca> it was not meant to be published
[21:39:03] David Oliver_web_669 joins the room
[21:39:37] <Alexey Melnikov_web_529> +1 to what DKG said.
[21:39:39] <francesca> not having consensus on the use cases - does that not have a consequence on the protocol itself?
[21:39:44] Samer Darras_web_276 leaves the room
[21:40:04] <francesca> basically what dkg said
[21:41:08] <Alexey Melnikov_web_529> +1 to Ted
[21:41:34] Dragana Damjanovic_web_120 joins the room
[21:42:54] <Mike Bishop_web_293> Does that suggest splitting the document, and moving text over as it reaches consensus?
[21:43:00] <dkg> MT: all the more reason to make a short use cases document that identifies the high priority use case.
[21:43:03] <Jeffrey Yasskin_web_499> Mike: That's also fine with me.
[21:43:07] <Ted Hardie_web_525> I don't think it does force them; the choice of when to take up the issues is a chair/timeline issue.  But that's just obviously my personal opinion.
[21:43:42] <Ted Hardie_web_525> I'm also fine with the "shorten this" theory to limit to the ones that have consensus.
[21:43:52] <Martin Thomson_web_403> adopting this says "the IETF thinks that all of these things are relevant", at least to some people, and some of this things are actively harmful
[21:44:41] Carlos Silva_web_383 joins the room
[21:45:03] <Ted Hardie_web_525> @Martin are those people who will think the same for any individual draft?  Or is there a class for whom the wg adoption is a big enough signal, even though should then know that it can and would likely change?
[21:45:04] <dkg> i'm fine with an appendix that says "other folks might be interested in these use cases, but we're not aiming for them, and the protocol might not solve these problems"
[21:45:23] <Martin Thomson_web_403> I don't have a problem with an appendix
[21:45:34] <Ted Hardie_web_525> I think that's fine.
[21:45:39] <Alexey Melnikov_web_529> Sure
[21:45:41] <Daniel Ehrenberg_web_394> an appendix in the format document, or the use cases document?
[21:45:44] <Jeffrey Yasskin_web_499> Thanks!
[21:45:50] <Jeffrey Yasskin_web_499> Daniel: In the use cases document.
[21:45:53] <dkg> appendix in the use cases document
[21:45:55] <Daniel Ehrenberg_web_394> Did we agree on which use cases are the main ones and which are the appendix ones?
[21:46:01] <Mike Bishop_web_293> Fine, with reasonable text on the appendix that disclaims them as target use cases.
[21:46:04] <dkg> Daniel Ehrenberg_web_394: no, of course not, that would be hard :)
[21:46:12] <Martin Thomson_web_403> We have not yet agreed, but I think that Jeffrey has a fair idea of what is in bounds.
[21:46:13] <Jeffrey Yasskin_web_499> Daniel: I think we have a decent sense. We'll find out for sure with the call for adoption.
[21:46:26] Carlos Silva_web_383 leaves the room
[21:46:31] <Martin Thomson_web_403> We will get a chance to see if he is wrong before we adopt, I hope.
[21:46:40] Larry Masinter_web_436 joins the room
[21:46:42] <Sean Turner_web_325> https://datatracker.ietf.org/meeting/111/materials/slides-111-wpack-web-bundles-00
[21:46:55] <Jeffrey Yasskin_web_499> This'll be Felipe.
[21:48:16] <Watson Ladd_web_568> at least we aren't the WebRTG wg
[21:48:26] <Jeffrey Yasskin_web_499> When in doubt, blame Sean. :grinning_face_with_one_large_and_one_small_eye:
[21:48:41] <Sean Turner_web_325> I will be back - turns out my other presentation is going to happen faster than I thought
[21:48:43] Stephan Emile_web_394 leaves the room
[21:48:47] Stephan Emile_web_826 joins the room
[21:48:50] Sean Turner_web_325 leaves the room
[21:49:09] Philipp Tiesel_web_311 leaves the room
[21:49:15] Philipp Tiesel_web_876 joins the room
[21:51:06] <Daniel Ehrenberg_web_394> the idea is that the primary URL could be added in a section in a separate/follow-on specification, based on the bundle format's extensible architecture
[21:51:35] <Martin Thomson_web_403> Isn't the advantage of Jeffrey's design that content negotiation is essentially free?
[21:52:03] <Daniel Ehrenberg_web_394> What do you mean by free, MT?
[21:52:42] <Martin Thomson_web_403> If you model things as HTTP requests and responses and the client supports variants, you get conneg.  But I guess you need to have duplicate "responses" for the same resource to get it, so maybe it isn't free.
[21:53:13] <Jeffrey Yasskin_web_499> Yeah, having content negotiation adds complexity, and using it adds bytes, so it's not obvious we should keep it.
[21:53:17] <Daniel Ehrenberg_web_394> well, the encoding was kinda specialized, it didn't just fall out or anything
[21:53:45] <Jeffrey Yasskin_web_499> Just having it adds about 1 byte per response, which is probably fine, so the complexity is the main objection.
[21:53:51] <Daniel Ehrenberg_web_394> +1
[21:54:01] <Martin Thomson_web_403> right, complexity is the true enemy
[21:54:54] <Martin Thomson_web_403> so I don't think that we need to discuss the addition of additional markdown files to a repository.  That's not something the WG needs to have an opinion on.
[21:55:52] <Jonathan Lennox_web_498> I think the question is not "should we add a markdown file" but "should there be a summary of the format." But I think that's still editorial.
[21:55:56] <Daniel Ehrenberg_web_394> I think overloading the redirect-on-failure with the primary URL cases is a bit broken
[21:56:09] <Martin Thomson_web_403> The specification should contain a summary of the format.
[21:56:33] <Martin Thomson_web_403> Daniel: I agree about this.  I thought that the version negotiation and fallback mechanism was overwrought.
[21:56:51] <Daniel Ehrenberg_web_394> Martin, that's good advice, I guess we should move bundle-format.md into the specification then
[21:57:32] <Daniel Ehrenberg_web_394> I still think content negotiation makes sense with bundle fetching, but it should be about the client sending the right headers to the server, not negotiating locally.
[21:57:34] <Ted Hardie_web_525> This really seems like the offline/p2p use cases all move into extensions.
[21:57:46] <Mike Bishop_web_293> Rick, it's "content negotiation" because that's the HTTP feature name.
[21:57:52] <dkg> it's the closest thing you can have to negotiation in a store-and-forward framework
[21:58:01] <Jeffrey Yasskin_web_499> @Ted: yes.
[21:58:05] <Bron Gondwana_web_891> sounds like multipart/alternative :p
[21:58:09] Ahmed Aldabbagh_web_526 leaves the room
[21:58:23] <Rick Taylor_web_455> +1 Bron - it's multipart/alternative *not* negotiation
[21:59:39] <Jeffrey Yasskin_web_499> +1 Martin, that we should merge bundle-format.md into the spec, to the extent that things are missing from the spec.
[21:59:50] <dkg> nope, i'm good ☺
[21:59:56] Takanori Fumeno_web_626 leaves the room
[21:59:59] <Jeffrey Yasskin_web_499> EWRONGDANIEL
[22:00:05] Takanori Fumeno_web_239 joins the room
[22:00:05] <dkg> story of my life
[22:00:08] <Ted Hardie_web_525> @Jeffrey. Doing that in a different doc is okay, though I would be really sorry to see it go completely.
[22:00:26] <Jeffrey Yasskin_web_499> @Ted: +1
[22:00:32] <Watson Ladd_web_568> Bundle format comes with a host of complications if we want a format for self contained documents
[22:00:52] <Alexey Melnikov_web_529> I like the idea of some mandatory-to-support-for-some-use-cases extension in a separate document to exercise extensibility
[22:02:03] <Daniel Ehrenberg_web_394> @Watson: +1
[22:02:16] <Martin Thomson_web_403> a lot of the offline use cases hit the same sorts of questions that Watson raised
[22:03:12] <Martin Thomson_web_403> is JPEG-XL a valid choice for image formats?  webp?  what dpi?
[22:03:27] Eric Rescorla_web_499 joins the room
[22:03:29] <Martin Thomson_web_403> I think that we can get sufficient flexibility into the core specification that almost anything can be achieved
[22:03:42] Sean Turner_web_537 joins the room
[22:03:48] <Jeffrey Yasskin_web_499> (Also, hooray that DTN folks have found us.)
[22:03:48] <Martin Thomson_web_403> as long as bundles and resources have extension metadata, we don't close off any future use cases
[22:04:15] <Sean Turner_web_537> back
[22:04:34] <Rick Taylor_web_455> There is a conceptual difference to me between a "batched response" (a response that contain resources + sub-resources) and a "bundled response" (a bundle feels like I can write it to disk, or forward it as an attachment, etc.) - Which use-case is in scope?
[22:04:37] Eric Rescorla_web_499 leaves the room
[22:05:04] <Daniel Ehrenberg_web_394> So, we can land the PRs then?
[22:05:16] <tale > Looks like it
[22:05:17] <Ted Hardie_web_525> @Daniel after confirmation on the list, no?
[22:05:29] <Martin Thomson_web_403> The bundle-format.md PR wasn't in the agenda, so I didn't review it
[22:05:34] <Martin Thomson_web_403> the others are fine
[22:05:34] <Daniel Ehrenberg_web_394> we already told the list about this; what more confirmation is needed?
[22:05:41] <Daniel Ehrenberg_web_394> as others noted, the bundle-format.md PR is editorial
[22:05:46] <Rick Taylor_web_455> @Jeffrey - us DTN folk were delyaed (and a little disruptive)
[22:06:06] <Watson Ladd_web_568> how much delay is DTN interested in? hours?
[22:06:40] <Rick Taylor_web_455> RTT to pluto is 8 hours...
[22:06:53] <Jeffrey Yasskin_web_499> @Rick: That's the distinction between the use-cases-with-consensus and the use-cases-without-consensus. Felipe's focusing the core document on "batched", but Ted and I want to make sure that "bundled" remains in scope to support people with difficult internet.
[22:07:13] <Ted Hardie_web_525> @Daniel the IETF generally makes the final decision on the list, though the question could be "the meeting consensus was $FOO, pleae review the minutes and if you disagree, speak by $DATE.  It's a process point; sorry for process wonkery, but it is the way things are meant to work.
[22:07:39] <Daniel Ehrenberg_web_394> Ted, thanks for explaining the process, that's what I was asking
[22:07:45] <Rick Taylor_web_455> @Jeffrey - thanks, got it now
[22:07:56] Takahiro Nemoto_web_925 leaves the room
[22:08:25] <tale > Right and the result is ultimately still back out to the list, and someone is still free to object after $DATE.
[22:08:44] Takahiro Nemoto_web_589 joins the room
[22:08:56] <Rick Taylor_web_455> @Jeffrey - when you want to do true "bundles" DTN have the transport protocol for you
[22:09:36] <Martin Thomson_web_403> This business about matching resources is not achievable, in practice or in theory.
[22:10:11] <Rick Taylor_web_455> Side question:  Is the "browsing into bundles" a contentious use-case because it is more than simple batched responses?
[22:10:16] <Bron Gondwana_web_891> how much do proxies do smarts in this?  Proxy has more cached, requests just what it doesn't have, creates a bundle with the bits
[22:10:25] <Martin Thomson_web_403> Different resources are different.  If they serve the same content, that is their business, but their reasons for doing so is not something a specification can control in this way.
[22:10:45] <Martin Thomson_web_403> Rick: browsing into a bundle is not controversial, at least from my perspective.
[22:10:57] <dkg> what does "cheap rotation of URLs" mean?
[22:11:03] <Watson Ladd_web_568> content blocking by whom?
[22:11:14] <Daniel Ehrenberg_web_394> content blocking by browsers with ad blockers
[22:11:56] <Daniel Ehrenberg_web_394> @Bron: We were thinking about marking bundle responses as `Cache-Control: private, bundled`, so that old proxies don't cache the bundle responses, and new proxies can understand that they are allowed to decompose and cache individual parts
[22:12:14] Larry Masinter_web_436 leaves the room
[22:12:17] <Bron Gondwana_web_891> that makes sense
[22:13:18] <Martin Thomson_web_403> Daniel, that doesn't quite work
[22:13:22] <Daniel Ehrenberg_web_394> the content blocking concerns are along the lines raised in https://brave.com/webbundles-harmful-to-content-blocking-security-tools-and-the-open-web/ . The "defense" proposed, through verifying, is optional to implement and can be seen as analogous to other custom things that content blockers do. That said, we think that bundle subset loading is mostly useful for static content anyway, as bundlers are used today.
[22:13:24] <Martin Thomson_web_403> you need to use no-store
[22:14:13] <Daniel Ehrenberg_web_394> oh, oops, I was probably remembering wrong. This was designed by my coworker Cam Tenny, who's currently on leave so unable to attend this call. Do you think `Cache-Control: no-store, bundled` would work?
[22:14:37] <Martin Thomson_web_403> If bundles can't speak for other resources, you don't need to solve these problems.  You can have bundle-aware caches break things out, but that needs to be in some subsiduary namespace.
[22:15:38] Vasilis_web_296 leaves the room
[22:15:45] Vasilis_web_144 joins the room
[22:16:01] <Daniel Ehrenberg_web_394> ad blockers right now are based on URL-identified resources; the consistent feedback we have gotten from ad blockers is that they *would* like bundles to have their components addressed by URLs, so they can apply filters to them.
[22:17:06] <dkg> MT: does "URL X is a subsidiary namespace of URL Y" just mean "Y is a prefix of X" ?
[22:17:57] <Martin Thomson_web_403> dkg: I don't think that prefixes work in practice, but you can turn things into tuples, I guess
[22:17:58] <Jeffrey Yasskin_web_499> dkg: I think it's https://mailarchive.ietf.org/arch/msg/wpack/XS9f1lc8VcpihQ04L_DwKKwhwe8/, but that's complicated. :)
[22:18:19] <Jeffrey Yasskin_web_499> Martin: you're up.
[22:18:57] <Martin Thomson_web_403> I wasn't prepared for this at all
[22:19:00] <Martin Thomson_web_403> it wasn't on the agenda
[22:19:09] <Martin Thomson_web_403> So I haven't prepared any comments at all.
[22:20:15] <Philipp Tiesel_web_876> This proposal looks much narrower than all the caching/offline use cases I was expecting to see… why not just request the server to push the ressources?
[22:21:16] <Martin Thomson_web_403> Watson's right, the goal here is to try to find a way to have cake and also eat it when it comes to the combination of cache granularity and bundling.
[22:22:10] <Bron Gondwana_web_891> you could list all the etags in the bundle content information
[22:22:25] <Rick Taylor_web_455> Are we in danger of re-inventing tar, but with http headers as file metadata - or is that the idea?
[22:22:27] <Bron Gondwana_web_891> at which point we're kind of doing DAV sync-collection
[22:22:28] <Martin Thomson_web_403> This is a somewhat large increase in the scope of the work for this group if you are talking about revising how HTTP works in the described way.
[22:23:11] <Jeffrey Yasskin_web_499> @Rick: I'd call it reinventing ZIP.
[22:23:23] <Justin Richer_web_908> q+ for a last-minute note if I may?
[22:23:24] <Rick Taylor_web_455> But without compression ;)
[22:23:26] <Bron Gondwana_web_891> you're welcome
[22:24:17] <Daniel Ehrenberg_web_394> Sorry, I wasn't trying to expand the scope of this WG; we're developing the loading proposal in https://github.com/WICG/resource-bundles
[22:24:24] Devin Mullins_web_308 leaves the room
[22:24:29] Devin Mullins_web_900 joins the room
[22:24:31] <Daniel Ehrenberg_web_394> I do think that this work is relevant to what we're doing here, though
[22:24:38] Mark McFadden_web_685 leaves the room
[22:24:39] <francesca> Thanks Dave and Sean!
[22:24:40] Sean Turner_web_537 leaves the room
[22:24:42] <Justin Richer_web_908> if we were in person I'd grab half of you into th ebar to talk :)
[22:24:43] Chi-Jiun Su_web_244 leaves the room
[22:24:43] <Daniel Ehrenberg_web_394> thanks!
[22:24:43] Mike Bishop_web_293 leaves the room
[22:24:43] Devin Mullins_web_900 leaves the room
[22:24:43] <Bron Gondwana_web_891> Thanks chairs!
[22:24:43] Ted Hardie_web_525 leaves the room
[22:24:44] Chris Lemmons_web_425 leaves the room
[22:24:46] Martin Thomson_web_403 leaves the room
[22:24:46] <Justin Richer_web_908> thanks all!
[22:24:47] David Oliver_web_669 leaves the room
[22:24:47] Watson Ladd_web_568 leaves the room
[22:24:49] Harald Alvestrand_web_880 leaves the room
[22:24:49] <Felipe Erias_web_988> thank you!
[22:24:49] කෙසර රත්නායක_web_413 leaves the room
[22:24:51] Bron Gondwana_web_891 leaves the room
[22:24:52] Hiroyuki Goto_web_673 leaves the room
[22:24:55] Francesca Palombini_web_635 leaves the room
[22:24:56] Darrel Miller_web_524 leaves the room
[22:24:56] Justin Richer_web_908 leaves the room
[22:24:58] Xavier de Foy_web_380 leaves the room
[22:24:59] Dan Druta_web_558 leaves the room
[22:25:03] Jonathan Lennox_web_498 leaves the room
[22:25:10] Philipp Tiesel_web_876 leaves the room
[22:25:14] Vasilis_web_144 leaves the room
[22:25:15] Daisuke Enomoto_web_895 leaves the room
[22:25:15] Dragana Damjanovic_web_120 leaves the room
[22:25:18] francesca leaves the room
[22:25:22] Kenneth Murchison_web_921 leaves the room
[22:25:31] Phillip Hallam-Baker_web_481 leaves the room
[22:25:31] Alessandro Amirante_web_710 leaves the room
[22:25:31] Rick Taylor_web_455 leaves the room
[22:25:31] David Lawrence_web_812 leaves the room
[22:25:31] Felipe Erias_web_988 leaves the room
[22:25:31] Daniel Gillmor_web_891 leaves the room
[22:25:31] Marcus Ihlar_web_904 leaves the room
[22:25:31] Alessandro Toppi_web_157 leaves the room
[22:25:31] Jeffrey Yasskin_web_499 leaves the room
[22:25:31] Hayato Ito_web_775 leaves the room
[22:25:31] Daniel Ehrenberg_web_394 leaves the room
[22:25:31] Takanori Fumeno_web_239 leaves the room
[22:25:31] Stephan Emile_web_826 leaves the room
[22:25:31] Takahiro Nemoto_web_589 leaves the room
[22:25:31] Eric Kinnear_web_601 leaves the room
[22:25:31] Alexey Melnikov_web_529 leaves the room
[22:36:07] Meetecho leaves the room
[22:43:38] dkg leaves the room
[22:52:49] Meetecho-alex leaves the room
[23:07:57] jyasskin@jabber.today leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!