#whatwg on 2008-11-20

08:19	<hsivonen>	hmm. Perhaps Roy hasn't looked at what some of the 2000 Apache committers have been up to lately...
10:24	<Hixie>	danbri: (i ask merely because different people have said similar things but in each case meant something different)
11:02	<danbri>	and dropped in html5?
11:02	<Hixie>	nope
11:48	<mookid>	I'm not saying you dont understand I'm saying you can't tell
11:48	<Hixie>	so how could i get the perspective to tell?
11:48	<mookid>	by allowing both
11:48	<mookid>	and seeing what happens
11:48	<mookid>	why do you even want to make that call
11:48	<Hixie>	we can't both allow and disallow content negotiation
11:49	<mookid>	if someone makes a web app with HTTP conneg
11:49	<mookid>	and it's crap for users..
11:49	<Hixie>	they're mutually exclusive options
11:49	<mookid>	gues what
11:49	<mookid>	NO ONE WILL USE IT
11:49	<mookid>	that's how capitalism works
11:49	<Hixie>	right, indeed, nobody uses it
11:49	<mookid>	NO
11:49	<Hixie>	we've seen that already
11:49	<mookid>	that's wrong
11:49	<Hixie>	well, a few people do
11:49	<gsnedders>	hsivonen: I was discussing it with him in private, but the current draft hal CC: www-tag
11:49	<mookid>	nobody uses it because it's not provisioed for by existing technmologies
11:49	<Hixie>	w3c does for some resources
11:49	<mookid>	that's circular argument
11:49	<mookid>	and you know it
11:49	<Hixie>	though almost uniformly when they do, they screw things up
11:49	<mookid>	it's totally disingeous
11:49	<hsivonen>	"progression of a technologist" reminds me of TUITT (The Architect's Progress) :-)
11:49	<mookid>	no
11:49	<mookid>	go back
11:49	<hsivonen>	gsnedders: ah
11:49	<mookid>	just go back
11:49	<gsnedders>	*has
11:49	<mookid>	< Hixie> right, indeed, nobody uses it
11:49	<mookid>	< Hixie> right, indeed, nobody uses it
11:50	<mookid>	taht is nonsense
11:50	<mookid>	nobody has th oppotunity to use it
11:50	<mookid>	because you cant do it
11:50	<mookid>	there's no reason you can't provision for both HTTP and URI conneg
11:50	<Hixie>	how so? all the browsers support it, all the servers support it, why would people not use it if they wanted it?
11:50	<mookid>	they arent mututally exclusive
11:50	<mookid>	the browsers dont support it
11:50	<Hixie>	sure they do
11:50	<mookid>	no they dont
11:50	<Hixie>	they send Accept headers correctly
11:51	<mookid>	not dynamically there's no markup for it
11:51	<mookid>	that's my point.
11:51	<Hixie>	the markup idea doesn't do content _negotiation_, it does content _selection_, which is what URIs are _for_
11:51	<Hixie>	URIs are resource identifiers
11:51	<mookid>	URIs are USED THAT WAY AT THE MOMENT
11:51	<mookid>	BECAUSE OF THAT
11:52	<mookid>	you're looking at the relationship wrong
11:52	<Hixie>	right, that's the architecture of the web
11:52	<mookid>	the reason
11:52	<mookid>	URIs are used to do that
11:52	<mookid>	is because there's no other alternative
11:52	<mookid>	it's NOT PROVISIONED FOR
11:52	<Hixie>	why do we need an alternative?
11:52	<mookid>	why not?
11:52	<mookid>	it's another pattern
11:52	<gsnedders>	Bloat?
11:52	<Hixie>	because we don't need it
11:52	<hsivonen>	alternatives are expensive
11:52	<Hixie>	and it's expensive to implement, spec, test, and debug
11:52	<mookid>	if you can provision for it simply and withotu breaking existing methodologies
11:52	<mookid>	why would you not do that
11:52	<mookid>	the answer is that
11:52	<mookid>	you dont agree with that way of doing thigns
11:52	<Hixie>	surely we should be focusing on making sure we fit the web's architecture, anyway
11:52	<gsnedders>	Unless we need something, it just bloats the spec and makes implementing it more expensive
11:53	<mookid>	well you should'nt have the authority to do that
11:53	<Hixie>	which is that uris are identifiers for resources
11:53	<mookid>	what is a resource?
11:53	<hsivonen>	mookid: should you have the authority?
11:53	<mookid>	I have my definition
11:53	<mookid>	you have you
11:53	<mookid>	yorus
11:53	<mookid>	I'm saying
11:53	<mookid>	lets both do it our ways
11:53	<mookid>	and see which one wins
11:53	<mookid>	your saying
11:53	<Hixie>	"you're"
11:53	<mookid>	dont be a dick
11:54	<Hixie>	every time you misuse "your" i get really confused
11:54	<mookid>	seriously?
11:54	<mookid>	wow.
11:54	<jgraham>	mookid: AFAICT in your "arcitecture" you would still need to have unique URIs for unique content types so that you could do something like a HTML page with links to specific versions of the resource, which you have said would be the fallback for browsers that didn't support <a accept>
11:54	<Hixie>	yeah i'm like "my saying? what saying? what?"
11:54	<jgraham>	architecture*
11:54	<mookid>	it's funny why you've stopped the conversation
11:54	<mookid>	is taht becaue you're in a hole
11:55	<mookid>	perhaps?
11:55	<Hixie>	i'm still confused about how this accept attribute would work when you want to copy and paste the url
11:55	<mookid>	ABORT ABORT
11:55	<mookid>	it doesnt work - it depends on the default accept headers of the client
11:55	<Hixie>	but more importantly, we've explained that new features are expensive, and that we don't see an advantage to this proposal, as it doesn't introduce anything
11:55	<Hixie>	and we've explained how it breaks the web's architecture
11:55	<mookid>	that's how I want my application to behave..
11:55	<mookid>	yhou dont
11:55	<mookid>	that's fine
11:55	<mookid>	why cant we both have our way?
11:55	<wilhelm>	Even if this suggestion makes it into the spec, you would still have to convince browser vendors to actually implement it.
11:55	<mookid>	why do you have to restrict me
11:55	<mookid>	on the basis that you think you're right
11:56	<mookid>	well at least I have one step done
11:56	<mookid>	then I can do the next
11:56	<Hixie>	are you going to pay the engineers to implement this, to test it, to spec it, to write the tutorials, to debug their apps when it breaks, etc?
11:56	<hsivonen>	mookid: should we have as many ways of doing things as there are people in the world?
11:56	<mookid>	hsivonen: no, clearly not shut up
11:56	<jgraham>	mookid: be civil
11:56	<mookid>	no he's being annoying
11:57	<Hixie>	so are you but we're still being polite :-)
11:57	<mookid>	passive agressive is agressive
11:57	<mookid>	I just dont act like agirl
11:57	<mookid>	:)
11:57	<Hixie>	his point is well made, though, if five people want five different things, we obviously don't want to add five features to the language
11:57	<mookid>	Hixie: I dont have to pay anyone - developers that believed in doing it that way would od it
11:57	<Hixie>	we have to pick the right nes
11:57	<mookid>	the ones that didnt
11:57	<mookid>	wouldnt
11:57	<mookid>	funnily enough
11:57	<mookid>	but btoh can co-exist
11:58	<mookid>	there's not imcopatability
11:58	<Hixie>	mookid: ok, well, i am deciding not to do it
11:58	<mookid>	WHY?
11:58	<Hixie>	mookid: because you won't pay me to add it to the spec :-)
11:58	<mookid>	erm
11:58	<Hixie>	mookid: it costs me time to do it
11:58	<mookid>	aaaahhhhhhh
11:58	<Hixie>	mookid: and you aren't willing to pay the cost
11:58	<mookid>	here we are
11:58	<mookid>	why didnt you just say that?
11:58	<Hixie>	i did
11:58	<mookid>	no you didnt
11:58	<Hixie>	i said adding teh feature was expensive
11:58	<mookid>	that's the first time you've mentioned money
11:58	<mookid>	how much does it cost?
11:59	<krijnh>	-_-
11:59	<mookid>	If I buy you a boko on web architecture will you do it?
11:59	<hsivonen>	do we have a link to an explanation of opportunity cost from the FAQ yet?
11:59	<mookid>	I nkow what an opporunity cost is
11:59	<mookid>	cost forgone by chosing the next best alternative
12:00	<Hixie>	well there's the 15 minutes for me to write the spec, the day or two spent fixing the spec over the next few months, the month or so of writing test cases, then the browser vendors each have to implement it so that's a dozen times a few days, then there's the tutorial writers who will have to spend a few hours or days explaining it
12:00	<mookid>	just for one optional attribute?
12:00	<Hixie>	then there's the cost of all the people who try to understand it, probably 5 minutes to an hour each, times maybe 100 million people
12:00	<wilhelm>	Implementation, testing, debugging, regression testing on every nightly build with all used configurations-- even the smallest features takes a lot of resources.
12:00	<mookid>	wow your processes are SERIOUSLY broken
12:00	<Hixie>	then there's the cost of regression testing that wilhelm mentions
12:01	<mookid>	I can't honestly believe that one optional attribute can make that much difference in the grand scheme of things
12:01	<Hixie>	then there's the cost of actual debugging for people using this
12:01	<Hixie>	let's assume an hour or so for a million people...
12:01	<mookid>	thos arent costs to this project that's not a reasonable argument
12:02	<krijnh>	(Don't forget the hours spent on this in IRC :)
12:02	<mookid>	those will be incurred by the 'insane' people who want to use HTTP conneg
12:02	jgraham	will be expecting his cheque in the post :)
12:02	<mookid>	I meant.. what does it cost to get this in the spec
12:02	<mookid>	not - what are the projected costs to industry
12:02	<mookid>	if it's not worth it
12:03	<mookid>	indstry wont pay for it
12:03	<Hixie>	so let's see... assuming $20/hour, that would be... about a billion dollars total, if my calculations are correct.
12:03	<mookid>	for one attribute?
12:03	<Hixie>	yup
12:03	<mookid>	you're a joke.
12:03	<Hixie>	that's why we only add the minimum
12:03	<Hixie>	well the cost is spread over the entire human race
12:03	<mookid>	ilke VIDEOTAGS
12:03	<Hixie>	over many decades
12:03	<mookid>	we already have video tags
12:03	<mookid>	we can already embed sounds
12:03	<Hixie>	consider how much money google paid to buy youtube
12:03	<mookid>	why not just fix the tags that exist?
12:03	<mookid>	rather than creat your own gay new markup
12:03	<Hixie>	and then you'll see that a billion dollars for a feature like that doesn't sound like much anymore
12:04	<mookid>	that no user actually cares about
12:04	<mookid>	who reads html
12:04	<mookid>	seriously
12:04	<Hixie>	because that feature makes money :-)
12:04	<mookid>	no ti doesnt
12:04	<mookid>	video on teh web makes money
12:04	<mookid>	you can do that with the tags that exist
12:04	<Hixie>	right
12:04	<mookid>	they need fixing
12:04	<Hixie>	not without paying adobe
12:05	<wilhelm>	Porting Flash to new platforms along with a browser is a pain.
12:05	<mookid>	so it would cost whatwg how much to add this attribute?
12:05	<wilhelm>	I'd prefer not to do that again. (c:
12:05	<Hixie>	it would cost hte whatwg nothing at all, the whatwg has no money. it would cost the human race about a billion dollars spread over a few years.
12:05	<mookid>	investment
12:05	<Hixie>	with what return?
12:05	<mookid>	who knows
12:06	<mookid>	they arent going to pay up if there's no ROI
12:06	<Hixie>	exactly
12:06	<mookid>	why dont you let them decide that
12:06	<mookid>	WHY DONT
12:06	<mookid>	YOU LET
12:06	<mookid>	THEM DECIDE
12:06	<Hixie>	because i am paid to make these judgement calls
12:06	<mookid>	how difficult is it to understand that is the most efficient way to make that descision
12:06	<Hixie>	that's my job
12:06	<mookid>	it's how our economies work
12:06	<Hixie>	well
12:06	<Hixie>	yes
12:06	<annevk2>	who is "them"?
12:06	<krijnh>	Wb annevk2 :)
12:06	<Hixie>	sometimes, the browser vendors implement things without a spec
12:06	<mookid>	do you know Smith's "invisible hand" ?
12:06	<annevk2>	thx krijnh
12:06	<hsivonen>	wilhelm: did Opera port Flash to Wii?
12:07	<Hixie>	and that's when i know i made a mistake in saying "no"
12:07	<mookid>	erm
12:07	<Hixie>	and sometimes, the browser vendors don't implement something that i put in the spec
12:07	<mookid>	lol
12:07	<Hixie>	and that's when i know i made a mistake in saying "yes"
12:07	<mookid>	by not putting it in the spec you create an articificial barrier to entry
12:07	<Hixie>	but in this particular case, i haven't heard a single browser vendor be positive about it
12:07	<wilhelm>	hsivonen: Yes.
12:08	<mookid>	it's something else they have to worry about 0 they probably dont understand it
12:08	<mookid>	so you've talked to browser vendors about this?
12:08	<mookid>	that's blatantly a lie
12:09	<Philip`>	Hixie: C's pointer syntax made more sense when I learned that the type declarations were meant to reflect how you would use variables of that type, e.g. "char *foo" means foo is a char* and *foo is a char, and "char foo[]" means foo[n] is a char* and *foo[n] is a char
12:09	<jgraham>	mookid: You've tlked to browser vendors
12:09	<wilhelm>	mookid: You are talking to browser vendors about this right now.
12:09	<Hixie>	mookid: pretty much everyone who has spoken in this conversation other than me and you is a browser vendor
12:09	<mookid>	ahh taht explains ALOT
12:09	<mookid>	:)
12:09	<Hixie>	actually i guess now that the G1 is out and Chrome is out even i'm technically a browser vendor
12:10	<hsivonen>	Philip`: putting * after the space has never made sense to me. I always think that pointerness is part of the type.
12:10	<Hixie>	but we'll gloss over that so i can continue to act as a vendor-neutral arbitor!
12:10	<mookid>	huhuhuhu
12:10	<tthorsen>	hsivonen: consider this "char* a, b" a is a pointer to a char, but b is just a char
12:10	<Hixie>	hsivonen: it only makes sense because of the binding of the star token in "int* a, b" (b's type is "in" not "int*")
12:10	<Hixie>	what tthorsen said
12:11	<Philip`>	hsivonen: It seems to make some sense either way - "char* x" means x is a char, while "char x" means *x is a char
12:11	<Hixie>	but that's a bug in C and i agree that the * should be before the space
12:11	<hsivonen>	tthorsen: I don't declare multiple variables on one line in C or C++.
12:11	<mookid>	no offence but how many 'big thinkers' are invovled in the nitty gritty of HTML5 -_-
12:11	<mookid>	brwoser vendors or not
12:11	<Hixie>	mookid: how does one determine if one is a big thinker?
12:11	<mookid>	I just really dont think this is the appropriate place to be making design descisions
12:12	<Hixie>	where is appropriate?
12:12	<mookid>	well..
12:12	<mookid>	DESIGN TIME?
12:12	<mookid>	maybe?
12:12	<mookid>	...
12:12	<Hixie>	in #whatwg it is design time all the time
12:12	<Hixie>	that's what we do
12:12	<mookid>	you dont do application design
12:12	<jgraham>	Apart from when we are discussing gsnedders poetry.
12:13	<mookid>	specifically web application design
12:13	<jgraham>	That is not spec design :)
12:13	<Hixie>	oh i thought you mean the design of the language
12:13	<Hixie>	i don't think it would make much sense to decide what tags html had when writing a web app :-)
12:13	<Hixie>	it's kinda late by then
12:13	<mookid>	It's notyruo place to start rejecting features on the basis that you need to 'protect' users from 'crazy' architects/developers
12:13	<mookid>	what?
12:13	<mookid>	Hixie:
12:14	<mookid>	developers are entirely restricted by thtat
12:14	<Hixie>	should we just add all features that people request then?
12:14	<mookid>	no just the ones that don't break anything else and provide more alternatives to developers
12:14	<mookid>	users dont care about html
12:14	<mookid>	developers do
12:15	<Hixie>	your proposal breaks the web architecture
12:15	<mookid>	no it doesnt
12:15	<mookid>	you can still write URI based conneg with my proposal
12:15	<Hixie>	the web architecture is that a resource is identified by a uri
12:15	<mookid>	you can still do it your way
12:15	<Hixie>	you are proposing making them identify multiple resources
12:15	<mookid>	even if my proposal is implemetned
12:15	<mookid>	my proposal is to provide the OPTION
12:15	<Hixie>	the option to break the web architecture, right
12:15	<mookid>	that's compltely different
12:15	<mookid>	no
12:15	<mookid>	not to break it
12:16	<mookid>	the old design
12:16	<mookid>	and OLD applications
12:16	<mookid>	will still work
12:16	<mookid>	there's no change there..
12:16	<mookid>	it's only developers who make web apps that serve html with the attribute
12:16	<mookid>	that will have any change
12:16	<Hixie>	so we should add all features that people ask for if those features are optional?
12:16	<mookid>	provided they dont break anything else
12:16	<mookid>	and they have a valid use for them
12:17	<mookid>	which I'v eclrealy demonstrated
12:17	<Hixie>	wow, that would make for one hell of a big and confusing language
12:17	<mookid>	not really
12:17	<mookid>	if you use your brain
12:17	<Hixie>	dude i have literally THOUSANDS of e-mails of feature requests
12:17	<Hixie>	to go through
12:17	<mookid>	oh right ok then
12:17	<Hixie>	most of which are optional
12:17	<mookid>	maybve think abuot letting someone else help?
12:17	<Hixie>	it's not a matter of it taking time
12:17	<mookid>	or do you not feel like sharing the glory?
12:17	<Hixie>	it's a matter of the size of the language if we added them all!
12:18	<mookid>	or trust anyone to be as super intelligent as you obviously are
12:18	<mookid>	protector of the web
12:18	<mookid>	(architecturE)
12:18	<mookid>	it's a nonsense position to take
12:18	<Hixie>	(actually i've already requested volunteers to take over certain parts of the spec)
12:18	<Hixie>	(btu that's independent of my point here)
12:18	<Hixie>	but
12:18	<mookid>	I'll happilly work on that part and anything else you need
12:18	<Hixie>	sweet
12:19	<mookid>	it's a shame there's no web site for proposals though
12:19	<Philip`>	Specs are useless unless they're implemented, and implementors have limited resources, so even if we had infinite spec-editing capability we'd have to limit the size of the language
12:19	<Hixie>	http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has the details of what needs doing
12:20	<Hixie>	right, the original point still stands, which is that we'd be irresponsible to just accept all (optional) proposals
12:20	<mookid>	right it's a trade off.. but it's pretty obvious that HTTP centric apps are emerging as a a new approach
12:20	<mookid>	otherwise why would you be implementing PUT/DELETE?
12:21	<Hixie>	ok if you agree that it is a tradeoff... what is it a tradeoff between?
12:21	<mookid>	between what it adds.. adding the functionality from HTTP conneg is a big addition with minimal cost and complete backwards compatability
12:22	<mookid>	the fact that you wouldn't use it
12:22	<mookid>	is neither here nor there
12:22	<mookid>	frankly
12:22	<mookid>	I mean
12:22	<mookid>	what realistically does a video tag add?
12:22	<Hixie>	well in the case of your proposal, it adds nothing, it's just another syntax for what you can do already
12:22	<mookid>	what?
12:22	<mookid>	no you CANT..
12:22	<Hixie>	the video element adds a way to do video without paying adobe
12:23	<mookid>	if you can please tell me how
12:23	<Hixie>	instead of src="foo" accept="text/html" you do src="foo.html"
12:23	<mookid>	that's not the same thing
12:23	<mookid>	that's totally different
12:23	<mookid>	that's not HTTP conneg
12:23	<Hixie>	it acts exactly the same to the user
12:23	<mookid>	not to DEVELOPERS
12:23	<mookid>	who are the people
12:23	<Hixie>	yes but HTTP conneg, as previously discussed, is a bad idea
12:23	<mookid>	USING HTML
12:23	<mookid>	users dont SUE html
12:23	<mookid>	USE
12:24	<mookid>	they dont CARE about html
12:24	<Hixie>	developers are developing for the users
12:24	<Hixie>	so if the users see no difference...
12:24	<mookid>	they couldn't care less if it was XHTML HTML whatever
12:24	<mookid>	er..
12:24	<mookid>	yeah..
12:24	<mookid>	but what if the developers see a huge difference?
12:25	<mookid>	what if it gives them a feasible way to use single URIs for many representations
12:25	<mookid>	that's not possible at the moment
12:25	<Hixie>	well in this paricular case, what difference do they see?
12:25	<mookid>	that's a big difference
12:25	<mookid>	well
12:25	<mookid>	not possible -> is now possible
12:25	<hesslow>	mookid: Why don't just use mod_rewrite and use the extension part as content-type?
12:25	<mookid>	that's more of a change than
12:25	<mookid>	crappy object and embed tags for video -> video tags for vide
12:25	<hsivonen>	mookid: you aren't considering things on high enough a level of abstraction
12:26	<Hixie>	what is possible now that wasn't before?
12:26	<hsivonen>	mookid: when you go high enough, the Accept header is just an implementation detal
12:26	<hsivonen>	detail
12:26	<mookid>	hesslow: I know you can do that.. that's what I do at the moemnt
12:26	<mookid>	everyone does it that way
12:26	<mookid>	because you cant do it any other way
12:26	<mookid>	because HTTP conneg isnt supported
12:26	<mookid>	you can make a browser GUI that makes use of HTTP conneg
12:26	<hesslow>	So as a developer is there any difference then?
12:26	<mookid>	so no one produces web apps that use http conneg
12:27	<mookid>	yes there's a huge difference
12:27	<mookid>	because you can use HTTP conneg
12:27	<Hixie>	as hsivonen says, the content negotiation pattern is supported, just not using the low-level implementation details of http vs uris
12:27	<mookid>	and so you can serve multiple content-types from one URI
12:27	<Hixie>	but that's an implementation detail
12:27	<Hixie>	it doesn't affect whether or not the pattern is possible
12:27	<mookid>	yes it does
12:27	<Hixie>	how?
12:27	<mookid>	it's completely different
12:27	<Hixie>	how?
12:28	<mookid>	well it's PROTOCOL level
12:28	<Hixie>	at the architectural level, how is it different?
12:28	<mookid>	masively
12:28	<Hixie>	how?
12:28	<mookid>	URI strcture?
12:28	<mookid>	cachine mechanisms
12:28	<mookid>	caching
12:28	<Hixie>	that's an implementation detail, not an architectural level detail
12:28	<Hixie>	i'm asking what difference does it make at the architecture level
12:28	<hsivonen>	caching has to happen on the representation level anyway
12:29	<mookid>	Vary
12:29	<Philip`>	If you encode the desired content-type in the URI, it's not possible for a general-purpose HTTP-processing device to understand what's the resource identifier and what's the content-type selector, because there's no standard for encoding that stuff in URIs
12:29	<mookid>	yes exactly
12:29	<mookid>	which means that if you were using HTTP conneg
12:30	<mookid>	and your brwoser knew it was only requesting text/html
12:30	<Hixie>	Philip`: such a standard or convention could be easily established
12:30	<hsivonen>	Philip`: is that a problem?
12:30	<mookid>	youc ould implement security mechanism
12:30	<mookid>	to reject that content
12:30	<mookid>	yes
12:30	<mookid>	read what I just wrote
12:30	<mookid>	is one example of the benefits
12:30	<mookid>	of UNIFORMITY
12:30	<Philip`>	whereas there is a standard for encoding the resource identifier in the URI and the content-type selector in Accept, so devices that don't know about your application-specific encoding mechanism can still separate the resource/representation identifiers
12:30	<hesslow>	Are there any good way to do fallback for your own protocols-handlers? I found the type-attribute on a-tags for content-type but there is no way to specify how the fallback should be done. What I would want is a fallback to a normal http-uri if the browser don't support the protocol
12:31	<jcranmer>	mookid: the sever need not match the Accept header
12:31	<mookid>	exactly..
12:31	<mookid>	so if it doesnt
12:31	<mookid>	there's a standard way of sayign
12:31	<mookid>	'hey look I wasnt expecting that'
12:31	<mookid>	if it's in the URI
12:31	<mookid>	that's not feasible
12:31	<mookid>	?type=html ;type=text/html .html
12:32	<Philip`>	Hixie: You couldn't establish it in a way that wouldn't conflict with other people not following that standard and perfectly legitimately happening to use the same magic URI query parameter or whatever the content-type thing is stored as
12:32	<mookid>	you couldn't ?
12:33	<mookid>	dunno if I'm reading that right
12:33	<Hixie>	Philip`: yeah, fair point
12:34	<Philip`>	hsivonen: I don't know if it's a practical problem or not, since it depends on whether general-purpose HTTP-processing devices can do interesting things with that information
12:34	<Hixie>	Philip`: but it's unclear that the convention needs to extend beyond the server
12:34	<Hixie>	Philip`: (i'm not sure i understand the use cases)
12:34	<mookid>	well the security mechnism would be nice..
12:35	<Philip`>	mookid: I mean you couldn't define a standard which says e.g. ?type=text/html in the URI is equivalent to Accept:text/html, because that would conflict with people who happen to use ?type=... for something else
12:35	<mookid>	yeah that's what I mean
12:35	<mookid>	it's not uniform
12:35	<mookid>	so you couldn't reaasonably protect against that
12:35	<mookid>	if it's inteh accept header that a certain request is expected to be only text/html or text/* or whateevr
12:36	<mookid>	and it's outside of that
12:36	<mookid>	you can throw errors or whatever
12:36	<mookid>	you cant do that if it's in the URI
12:36	<Philip`>	Why bother with sending Accept? Just send a normal request, and if you don't get the text/html you expected then throw it away
12:37	<mookid>	As a security feature - thre's probably something you could do to prevent CSRF/XSS
12:37	<mookid>	particularly if the HTML is all modular and stuf
12:37	<mookid>	modularity is great functionality but it's going to make CSRF and XSS go nuts
12:37	<Hixie>	CSRF wouldn't be helped here since the page containing the markup would be the source page
12:38	<Philip`>	mookid: That's sounding incredibly vague :-p
12:38	<Hixie>	and XSS as far as I can tell wouldn't happen with a link, and we've already got sandbox="" for <iframe>
12:38	<mookid>	:/
12:38	<mookid>	so you dont take the point that its easier to implement a security mechanism against HTTP conneg?
12:39	<Philip`>	If there is a specific instance of some vulnerability that could best be solved by this mechanism, then that'd be more useful than saying "there's probably something you do [with this feature]"
12:39	<mookid>	well yeah sure I can go away and come up with the case if you like
12:39	<mookid>	I mean
12:39	<mookid>	it's hard to deny that's the case
12:40	<mookid>	Either way - I think you an I agree that it is a significantly different approach to aplpication development
12:40	<Philip`>	s/you do/you could do/
12:40	<mookid>	particularly from the server standpoint
12:40	<mookid>	of data store
12:40	<mookid>	and representations
12:41	<mookid>	+ it's not imcompatible with the current methods
12:41	<Philip`>	I don't think it's significantly different - it's just a different syntax, and that syntax might make a few things work better and a few things work worse
12:41	<mookid>	the only worse is how do I know what this string URI means
12:43	<mookid>	in a business context there's only so many UAs to account for
12:43	<mookid>	and natural lanaguage goes along way aswell
12:43	<mookid>	god forbid we should humanise human computer interaction
12:44	<mookid>	-_--
12:44	<mookid>	but hey thats all 'moon' stuff
12:48	<Philip`>	Why humanise it? I don't like humans
12:50	<Philip`>	Natural language doesn't seem great - "Visit whatwg.org in your web browser then click "HTML5" in the "Specs" box" is much less helpful to anyone than "Visit http://whatwg.org/html5";, and the uniformity is a significant benefit of URIs
12:51	<jcranmer>	most computer problems emabate from between the chair and monitor
12:51	<jcranmer>	s/b/n/
12:52	<Philip`>	That's a very old-fashioned pre-mobile view of the world :-p
12:53	<jcranmer>	ok then
12:54	<jcranmer>	most problems emanate from devices running at less than 1 KHz clock speed :-)
13:01	<Philip`>	jcranmer: So it's all EDSAC's fault?
13:03	<Hixie>	wtf, now my plugin works in firefox but in safari only the name components are shown, not the values!
13:04	<Hixie>	and it works fine now.
13:04	<Hixie>	ok.
13:04	<Hixie>	fine.
13:05	<Hixie>	whatever.
13:05	<Hixie>	i don't care.
13:05	<Hixie>	:-P
13:06	<BenMillard>	krijnh, this should be an IRC logs tagline: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-283
13:06	<Philip`>	s/design/party/
13:06	BenMillard	forgot the keg...
13:08	<BenMillard>	Philip`, the ".html" or ".pdf" or ".png" and suchlike portion of URIs is already a widespread convention for selecting particular content types (re: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-420)
13:09	<BenMillard>	Hixie, that convention is used outside of servers: browser extensions sometimes use RegExp on URIs in the DOM to figure out what type of thing they are pointing to, and give special behaviour for them
13:09	<BenMillard>	I'm not saying that's a good idea, though...
13:10	<mookid>	no that's terible and totally impractical -_-
13:10	<Philip`>	You should probably use <a href type> for that
13:11	<Philip`>	(if it's purely client-side)
13:11	<Philip`>	(and if you're in control of the content)
13:11	<mookid>	why type and not accept?
13:11	<BenMillard>	Philip`, the extensions are designed to work on the web :)
13:11	<mookid>	what are extensions?
13:11	<Philip`>	mookid: Because type is advisory information indicating the expected type of the thing at the URI
13:12	<mookid>	so.. the accept header?
13:12	<BenMillard>	mookid: AKA browser add-ons
13:12	<Philip`>	mookid: so it's quite similar to the file extension, in that it doesn't affect the request at all
13:12	<mookid>	but then you're just attempting a hybrid of http conneg and URI conneg
13:12	<Philip`>	BenMillard: Ah, fair enough :-)
13:13	<mookid>	if you're admitting there are cases where you would want to indicate what type a link should be
13:13	<Philip`>	mookid: It's not attempting any kind of conneg at all - it's just a way for an HTML document to tell clients what might be the content-type of a URI, so they can add "warning: this link is probably a PDF and may crash your browser" to the links or whatever
13:13	<mookid>	you're kind of producing the 'illusive' use case
13:14	<Philip`>	and it doesn't involve the server at all
13:14	<mookid>	that's what Accept does
13:14	<mookid>	no not as it stands
13:14	<mookid>	it could
13:14	<mookid>	if it was connected to the Accept request
13:14	<mookid>	of that request implied
13:14	<BenMillard>	Philip`, the one's I've tried are actually quite effective as file extensions seem almost ubiquitous and the main types you'd want special behaviour for are rarely in conflict with other types
13:14	<mookid>	by the link
13:15	<BenMillard>	Philip`, it also means the feature (such as grouping links by the type of thing they point to) works without sending loads of HEAD requests and waiting for the responses
13:15	<mookid>	Accept header of the request implied by the link*
13:16	<mookid>	it woudl be really cool if we could get to a stage where HTTP was encouraged to develop a standard way of indicating available content types
13:16	<mookid>	then if someone sends you a URL
13:16	<Philip`>	mookid: But for these particular use cases, there's no need to make it send the Accept header or anything, because it's just informing the client about stuff
13:16	<mookid>	you right click it and get a context-menu 'open with'
13:16	<mookid>	and it lists your UAs for the content types available
13:16	<mookid>	that would be sweet :)
13:18	<Philip`>	That does sound like it could be quite useful
13:18	Philip`	goes away for a while
13:18	<mookid>	yeah that will never be encouraged unless browsers encourage http conneg
13:18	<mookid>	it's chicken and egg
13:19	<mookid>	it's definitely a different way of thinking about URIs though
13:19	<mookid>	browsers dominate HTTP applications so unless it's provisioned there it wont happen
13:20	<Philip`>	You could implement it by e.g. right-click "open with" triggering an HTTP request with a "Tell-Me-About-Extra-Content-Types" header, which legacy servers ignore and they send the default type, but new servers respond with a list of content-types and the client sends an extra request to get the one it wants, or something
13:20	<mookid>	yeah
13:20	<mookid>	exactly
13:21	<Philip`>	(But then that's a purely HTTP thing, not HTML)
13:21	<mookid>	well I jsut mentioned above
13:21	<mookid>	brwosers dominate HTTP app dev
13:21	<mookid>	all the frameworks are designed for them
13:21	<mookid>	so they focus on using URIs
13:22	<BenMillard>	Philip` & mookid, sounds like you want the browser to trigger a 300 Multiple Choices response: http://tools.ietf.org/html/rfc2616#section-10.3.1
13:22	<mookid>	the whole process is way more oslid using protocol level conneg
13:23	<Philip`>	"If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field" - so you need a separate URI per representation?
13:23	<Philip`>	Anyway, I'm going away for a while :-p
13:24	<mookid>	Philip` ftw?
13:24	<BenMillard>	Philip`, I imagine it expects a filetypeless cononical URLs like /foo with a set of filetyped URLs like /foo.bar and /foo.baz and these are what get listed in the reponse it sends
13:24	<BenMillard>	s/cononical URLs/cononical URL/
13:25	<mookid>	or is it foo?type=bar
13:25	<mookid>	or foo?content-type=bar
13:25	<mookid>	foo;type=bar
13:25	<BenMillard>	mookid, although which identifies the type of the resource, yeah
13:26	<BenMillard>	s/although/anything/
13:26	BenMillard	wonders how that typo happened...
13:26	<mookid>	yeah it's just creating ambiguity and resource blaot where its not necessary
13:26	<mookid>	bloat^
13:26	<mookid>	HTTP handles this nicely
13:26	<BenMillard>	huh? that is the HTTP spec :\|
13:26	<BenMillard>	well, cya
13:27	<mookid>	well the http spec actually mentions both methods
13:27	<mookid>	oh, bye
13:27	<mookid>	ABORT ABORT!
13:27	<mookid>	:>
13:38	<mookid>	another key point here is that if users are using PUT to update resources.. how are they to know wheher PUT /document.pdf updates /document.html and /document.xml - it's ambiguous
13:39	<mookid>	if the URI is the same this is completely clear
13:39	<mookid>	added to which - as soon as the PUT is performed on that URI - the caches can pick up on this and react for all representations to be re-cached
13:40	<mookid>	this isn't possible if the URIs are different per resource
13:40	<mookid>	yoru caching mechanism has to be application aware
13:43	<mookid>	^ this is just an example of how doing the conneg in HTTP makes significant changes to development approach
13:45	<Hixie>	wow, httpbis is already up to 300 pages
13:46	<Hixie>	http 1.1 was only 176
13:46	<Hixie>	i thought http bis wasn't adding anything new?
13:46	<mookid>	I dont know I'm not involved with that right now
13:46	<mookid>	how far away is that?
13:47	<mookid>	Hixie: do you even accept that it is different and has benefits?
13:48	<mookid>	I'm not getting at you it just frustrates me that I can articulate it properly :)
13:48	<mookid>	can't^
13:49	<mookid>	I'll take that as a yes then.. -_-
13:53	<ehird>	wow
13:53	<ehird>	mookid is STILL on about conneg?!?!?!
13:53	<ehird>	:o
13:53	<jcranmer>	ehird: it's only been >48 hours
14:03	<mookid>	well I don't think it's as cut and dry as you seem to believe it is
14:04	<mookid>	other than the fact that there's no way I can get this past the protector of the internet
14:17	<takkaria>	PROTECTOR OF THE INTERNETES
14:18	krijnh	adds a new subtitle to his logs
14:19	<mookid>	he talked to me
14:19	<mookid>	I am blessed
14:19	<mookid>	thanks be to Neo
14:21	<mookid>	don't tell him about javascript it'll break his little heart
14:21	<mookid>	:P
14:23	<krijnh>	It'll wake him up now, mostly :)
14:35	<Dashiva>	ehird: This is nothing compared to alt, alt 2: the return of alt, alt 3: son of alt, and all the others yet to come
14:35	<ehird>	:D
14:36	<ehird>	who's gonna by connegcube.com
14:36	<ehird>	4-day harmonic content negotiation
14:38	<mookid>	lies!
14:38	<mookid>	what a dissapointment that was
14:40	<Dashiva>	ehird: Site doesn't work :<
14:41	<ehird>	*buy
14:41	<ehird>	well duh i was asking for someone to make it
14:41	<ehird>	:D
14:45	<Dashiva>	Oh snap, new last week
14:46	<annevk2>	poor quality lately
15:17	<Philip`>	"Mr last Week sez: ... tone down the insults and rhetoric, it is uncalled for" - ooh, irony
15:37	<webben_>	What's the current thought on how should inline stage directions/descriptions be handled in DIALOG?
15:50	<webben_>	or multiblock speeches...
16:12	<mookid>	Philip`: did you have any more thoughts on it?
16:13	<Philip`>	mookid: On what in particular?
16:18	<mookid>	whether there is a significant difference in HTTP conneg, and whether it's provision is compatible with conneg in URI
16:37	<Philip`>	mookid: I can't think of any more thoughts at the moment
16:39	<mookid>	ok just chicken
16:58	<Philip`>	Oh no, #html-wg got invaded
16:59	<Philip`>	hsivonen: Continuing my comment from there: (and making the spec intentionally complex and obscure in order to discourage people writing their own probably-buggy XML parsers when they should be using a library instead, seems kind of elitist (that's not quite the right term but I can't think of the right one))
17:00	<Philip`>	Wow, someone just made Gmail ugly
17:00	<Philip`>	Hmm, it's a bit better if I reload the whole page and it's not mixing the old and new themes...
17:02	<gavin>	omgchange!
17:03	<Philip`>	Hmm, the layout is still different, and therefore ugly
17:04	<Philip`>	Judging by what happened when they last upgraded everything, I will be terribly upset for about two days and then I will be used to it and it'll seem perfectly normal
17:04	<gavin>	heh, indeed
17:12	<Philip`>	Hmph, Jim Jewett seems to think my name on IRC is a typo :-(
17:13	<Philip`>	(when actually it's just me being far too unimaginative to come up with a decent name, and someone else having already registered "Philip" on this network)
17:19	<mookid>	imagine if caching was controlled just with the Vary header
17:19	<mookid>	that would be fricking awesome
17:20	<Philip`>	But impossible
17:20	<mookid>	not for new apps
17:20	<mookid>	if your GUI and your API are the same interface
17:20	<mookid>	one being the HTML representation and the other being JSON or XML
17:21	<Philip`>	If you have multiple formats for some resource, but it takes a few minutes to do the conversion (because it's expensive transcoding or OCRing or whatever), how would you handle cache invalidation once the new format has been generated?
17:21	<mookid>	gah? -_-
17:23	<Philip`>	Nicely-designed apps shouldn't block users who are uploading data while the server does a load of back-end computation - asynchrony is more user-friendly, but doesn't seem to interact well with the assumptions made by caches
17:23	<mookid>	why would that be the case? yuo don't have to cache the entire of your application
17:24	<mookid>	you should only be caching what's appropriate to cache. -_-
17:24	<mookid>	you can control that with your responses
17:41	<Dashiva>	No worries about keeping warm this winter as long as public-html stays as it is. :)
17:43	Philip`	wonders why Textile parses "@,@ _x_@x@" correctly, but not "@, @_x_@x@"
17:47	<Dashiva>	The former looks like two smileys on a seesaw, the latter looks like some weird mutant and something
17:49	<Philip`>	The latter parses into <code>, @<em>x</em>@x</code>, which surely can't be intentional
17:59	<Dashiva>	Philip`, you just got told
18:00	<Philip`>	Indeedily
18:01	<Dashiva>	Anything you would like to tell our viewers?
18:02	<Philip`>	No
18:03	<Dashiva>	What will you do next?
18:03	<Philip`>	Nobody knows - that's how crazy I am
18:04	<Philip`>	so you better keep watching!
18:06	<Dashiva>	You heard him. Don't change that channel!
18:37	<gsnedders>	Philip` pwn'd on last week :)
19:47	<yecril71>	Philip`, could you look at my test page in IE8 today?
19:47	<yecril71>	Is there a chance for the section headers in HTML5 show up in IE7?
19:48	<yecril71>	It is very inconvenient that they do not
19:48	<yecril71>	You do not know what you are reading about
19:52	<yecril71>	Where is OBJECT[classid] declared?
19:53	<yecril71>	I cannot find it in the green summary box
19:53	<gsnedders>	yecril71: it's non-conforming, so nowhere
19:55	<yecril71>	But it is still mentioned in the text
19:55	<yecril71>	"If the classid attribute is present, and has a value that isn't the empty string,"
19:56	<gsnedders>	It has defined processing for UAs
19:56	<gsnedders>	Just because it has defined processing doesn't make it conforming
19:56	<yecril71>	Was that present perfect, or present simple?
19:57	<gsnedders>	present simple
19:58	<yecril71>	Thx
19:58	gsnedders	should be less ambiguous
19:59	<takkaria>	can someone explain to me the difference? :)
20:00	<gsnedders>	takkaria: Yes
20:00	<yecril71>	Present simple is the verb itself, inflected, followed by the object.
20:01	<yecril71>	Present perfect is aux "have" + past participle, followed by the object.
20:01	<Dashiva>	The ambiguity lies in whether defined is used as a participle or as an adjective
20:02	<gsnedders>	What can I put on my CV about WHATWG?
20:02	<Dashiva>	"Official inner-circle teamster"
20:03	<yecril71>	What should happen to embeeded ActiveX objects then?
20:03	<gsnedders>	Dashiva: Not a fanboy.
20:03	<yecril71>	I understand type="application/x-oleobject", but what about the CLSID?
20:04	<yecril71>	Where do I put it, given that classid is out?
20:05	<yecril71>	s/embeeded/embedded/
20:08	<yecril71>	classid is not mentioned as a difference from HTML4
20:08	<gsnedders>	Then the diff dsoc is wrong :)
20:08	<gsnedders>	*doc
20:09	<yecril71>	I would be glad to update it, but I need some information on how the decision was taken.
20:09	<annevk2>	feel free to blame me or submit patches to some mailing list I read
20:10	<yecril71>	I can do it myself, patches are excessive
20:10	<annevk2>	I actually think classid is still being considered for inclusion, using some hardcoded mapping table of values and plugins
20:10	<Philip`>	yecril71: Embedded ActiveX objects are not at all interoperable between platforms, so it wouldn't make much sense for HTML5 to provide specific syntax for them
20:11	<Philip`>	The conforming thing to do is to not use ActiveX :-)
20:11	<Philip`>	yecril71: I could look at your page, if you remind me where it is
20:11	<annevk2>	Philip`, you could make it interoperable if you map the classid to NPAPI
20:12	<yecril71>	<http://www.2a.pl/~ne01026/test.htm>;
20:12	<Philip`>	How odd, IE8 can't even render Google search result pages non-buggily :-/
20:12	<gsnedders>	hmmm
20:13	<gsnedders>	logs missed the link to jgraham='s CV
20:13	<Philip`>	(It cut off after 1.5 results (but still showed the footer after that), until I selected some text and then the rest popped into existence)
20:13	<jgraham>	gsnedders: I didn' link to my CV :)
20:13	<gsnedders>	jgraham: Didn't you?
20:13	<yecril71>	That would be good, talking about an undefined attribute is rather strange
20:14	<yecril71>	It is better to say classid (deprecated) than nothing at all.
20:15	<yecril71>	It is possible not to use ActiveX and delegate all processing to server,
20:15	<annevk2>	we've taken the approach to only mention things when there's an effect or when they're allowed for convenience
20:15	<yecril71>	or to use application/java.
20:15	<annevk2>	currently neither is the case as far as HTML5 is concerned
20:15	<annevk2>	though as I said that might be changing
20:15	<yecril71>	classid has a defined effect, only itself is undefined.
20:16	<Philip`>	yecril71: Both columns look the same (except for the left one being narrower), and about the same as in Opera and Firefox - there's an "a" slightly above (overlapping) the horizontal line, and a "b" slightly below (also overlapping) the line
20:16	<yecril71>	That is rather peculiar.
20:16	<yecril71>	That is good.
20:16	<annevk2>	UAs that would let it have effect would be non conforming per HTML5 as it stands today
20:16	<yecril71>	IE7 is broken in that regard.
20:16	<yecril71>	Thx a lot.
20:17	<Philip`>	yecril71: IE8 in IE7 bug compatibility mode is very different - there's no overlapping, and the left column has an extra blank line before the "b", which I assume is what IE7 does
20:17	<yecril71>	So it looks like, although it is not a blank line at all.
20:18	<Philip`>	Well, it's a line that's blank ;-)
20:18	<yecril71>	No, it is vertical space.
20:18	<yecril71>	A line is something, a space is lack of something ;-)
20:19	<yecril71>	The effect is described in item 1 of the embedding algorithm in HTML5.
20:19	<yecril71>	(of classid).
20:20	<yecril71>	So it takes precedence over anything else.
20:20	<yecril71>	And yet classid is undefined.
20:21	<yecril71>	The effect is conforming, only the attribute itself is nonconforming.
20:22	<yecril71>	ActiveX objects can be advantageous in an in-house application.
20:22	<annevk2>	ah, classid is already mentioned for browsers? ok
20:22	<Philip`>	<b>x<i>y</b>z</i> is non-conforming, but there are conformance requirements for how browsers must handle that, so it's not really any different with these nonconforming attributes
20:22	<yecril71>	The alternatives of using in-page java or a server-side process can be too expensive.
20:23	<gsnedders>	annevk2: Can we have more standards suckage?
20:23	<yecril71>	Except that B and I are defined and do not jump at the reader out of nowhere.
20:24	<yecril71>	And yet it would be nice to be able to validate the pages the components reside in.
20:24	<yecril71>	Without customizing the validator.
20:25	<yecril71>	Of course, one can always use HTML4 for that purpose,
20:25	<yecril71>	but what about HTML5?
20:25	<yecril71>	Is there a chance of getting a hint?
20:25	<yecril71>	(of course, IE requires classid now;
20:26	<yecril71>	assuming we can change it, what should it be changed to?)
20:26	<gsnedders>	yecril71: Nothing is as bad as the image element
20:26	<gsnedders>	(it is mentioned once, in the parser, where it gets converted to img)
20:28	<yecril71>	How about type="application/x-oleobject;classid={G-U-I-D}"?
20:33	<annevk2>	gsnedders, we'll resume shortly; not exactly sure when
20:46	<roc>	it's sad that some of the top-crash bugs we're seeing are caused by trojans
20:49	<takkaria>	ah, that sucks :(
20:49	<takkaria>	but I guess it speaks for the stability of your product
20:50	<roc>	I think for both us and Webkit the majority of top-crash bugs are actually Flash-related
21:02	<yecril71>	I do not understand how Tom Broyer got the need to have separate URLs for representations.
21:03	<Dashiva>	Maybe he doesn't agree they're representations?
21:03	<yecril71>	It does not follow from Fielding�s quote.
21:06	<hsivonen>	whose idea was it to start calling them URIs instead of URLs?
21:11	<yecril71>	Seems like OP�s.
21:13	<yecril71>	Although Fielding uses the term "identifier", so that misuse can be probably traced to the boss.
21:14	<yecril71>	s/misuse/unneeded generalization/
21:21	<ehird>	eh, it makes sense
21:21	<ehird>	how do you locate <tel:...>
21:43	<yecril71>	What is <tel:>?
21:44	<yecril71>	And does it implement content negotiation?
21:47	<gsnedders>	yecril71: tel is a uri scheme for telephone numbers
21:57	<takkaria>	erk. I joined the debate
21:57	<takkaria>	ehird: you locate it by phoning it, surely?
21:57	<takkaria>	oh, right
21:57	<takkaria>	I missed the context. :)
21:58	<yecril71>	And what about callto:?
21:58	<ehird>	ok then, how do you locate isbn::
21:58	<ehird>	("going to a bookstore and buying it" is not an answer)
21:58	<yecril71>	Wikipedia has a tool for that
21:59	<yecril71>	And isbn: does not support content negotiation either.
21:59	<ehird>	what has content negotiation got to do with this
22:00	<yecril71>	It is being asked in the context of content negotiation.
22:00	<takkaria>	I missed the context
22:00	<yecril71>	Why content negotiation is advertised for URIs in general.
22:00	<takkaria>	I thought that it was a "what am I meant to do with a tel:" number question, not a URI vs URL question
22:01	<takkaria>	URL means Universal Republic of Love, anyway, Tim Bray told me so :)
22:01	<yecril71>	wanna cyber? ;-)
22:01	takkaria	chortles
22:02	<yecril71>	Is tel: anything official?
22:02	<yecril71>	I have never seen tel:, only callto:
22:03	<takkaria>	I've seen tel: here and there
22:03	<yecril71>	Seems like by mistake
22:03	<yecril71>	Does ekiga register for tel:?
22:06	<ehird>	yecril71: timbl has it in his foaf file
22:06	<ehird>	somehow i doubt a mistake.
22:17	<gsnedders>	yecril71: http://www.iana.org/assignments/uri-schemes.html
22:17	<Philip`>	yecril71: RFC 3966
22:17	<gsnedders>	yecril71: Ns such thing as callto registered
22:18	gsnedders	returns to Shakespeare
22:20	<yecril71>	I only wanted information, not a proof :-)
22:20	<yecril71>	Seems the people at Skype are illiterate