Re:So when do we get its successor?
on
X Power Tools
·
· Score: 1
it doesn't actually address the criticism at all.
What criticism? The complaint didn't describe anything actually wrong with X. I see no problem with the "put up or shut up" response when the other person hasn't even bothered to describe what problems they think need to be fixed.
There are four sentences in my comment. One saying it's not a link. One saying what it is. One saying what it's for. One saying where it came from. I fail to see how the comment relates to any of these, let alone proves them wrong. If you disagree, please explain why instead of ranting about your grudge with the W3C. It's not hard to do, my comment wasn't long or complicated.
Why do you even need to validate it, unless you're a validator? Just try to parse it
The external DTD subset isn't just for error checking. It defines the character entities and the content model for element types. If you don't have access to the DTD (or hard-coded HTML-specific behaviour) you can't parse it fully.
Screen scraping is reading the final output of program (or in this case web page) in image format and converting that into usable data with methods such as OCR (optical character recognition).
Actually, the term is widely used as a synonym for spidering a site. It's rare I see it used in the way you describe. Sorry for the confusion.
"Webmasters" refers to people who run websites, not the W3C. And this particular feature is an artefact of SGML, which was around for over a decade before the W3C ever existed.
If they didn't want the traffic they should have specified the matter in their RFCs.
You mean like how RFC 2616 describes the caching mechanism that is being ignored by the problem clients? Or are you referring to the established-for-decades SGML system catalogue that they mention in the HTML 4 specificationmultiple times?
You can tell them apart by their attention to the consequences of their actions.
If people writing client software actually did what they were supposed to, this wouldn't be a problem. This is not a designed-in bug, this is caused by a minority of developers eschewing the specifications and standard practice out of either ignorance or apathy.
Add some sort of caching parameter to the DTD spec, that specifies how long browsers should cache those DTDs.
You're solving that problem at the wrong layer. HTTP already includes caching mechanisms, the W3C already use them, and part of the problem is that buggy software is ignoring them.
Another potential solution: Have browsers keep the DTDs cached
Please read the article. This is already supposed to happen. Buggy software fails to do this, which is the problem being talked about.
They insist that every document begin with a declaration that includes a link to their site.
It's not a link. It's a reference to an external DTD subset. It's there so that generic SGML software can properly parse the document without any special knowledge of HTML.
The link in the declaration serves absolutely NO purpose other than to comply with the standard that they created. It sounds like the whole purpose was so that they could have every source page begin with a link to their site. Serves the right.
No, external DTD subsets are a part of SGML, which is at least a decade older than the W3C.
No, Slashdot is not contributing to the problem, that is correct code. Just because a URI is listed, it doesn't mean that software should request it each and every time it sees it. Most code that sees that URI should already have a copy of the DTD in the local catalogue. It's only generic SGML software that cannot be expected to have a copy of the DTD.
Why on earth are you blaming webmasters? They are just about the only people who cannot be responsible for this. People who write HTML parsers, HTTP libraries, screen-scrapers, etc, they are the ones causing the problem. Badly-coded client software is to blame, not anything you put on a website.
In particular, the OpenID folks were resisting (and with good reason) all the pressure to use OpenID for things like, say, verifying that a user was associated with a particular email address, despite how useful that would be. So, how can Yahoo and AIM logins be OpenID logins?
I'm not sure what you don't understand. Why wouldn't they be OpenID logins? Just because I use the same username and password to authenticate for my Yahoo email and my Yahoo OpenID, it doesn't mean that my Yahoo email address is disclosed to everybody.
In particular, there seems to be no URL associated with either of those types of logins.
You're conflating two different things here: identity and access mechanism. Whether you sign into Yahoo mail via their website or via your mail client, it's still the same user account. Likewise, when you use your AOL OpenID, you might not use the same access mechanism as when you use AIM, but it's still the same identity.
No. You misunderstand. Again. If you aren't trolling, please just go and read an OpenID tutorial or something before posting more silly comments.
Some OpenID providers will only offer the bog-standard username and password authentication. Some OpenID providers will offer better security, for instance via client-side SSL certificates, swipe cards, etc. The people who want this extra security now have the option of going to a premium OpenID provider as opposed to a typical OpenID provider, and all the websites and web applications that accept OpenIDs will be more secure for these people without the websites and web applications having to do anything special to accommodate you.
You, as a security-conscious user, can seek out more secure forms of authentication by picking a better OpenID provider. And you can do this without the websites you use doing anything more than implementing standard OpenID. This is what jfengel is referring to when he is talking about paying for an OpenID.
And no, switching away from an OpenID provider doesn't mean you will lose your OpenID. Switching providers is something that OpenID handles through delegation.
There is, even if yahoo keep it to themselves they need to put it in that system.
What are you talking about? What system are they putting it into? The OpenID authentication on Yahoo's servers can just query the existing database that already holds your username and password.
As far as putting my yahoo details into a *different* site. Not gonna happen.
You don't put your username and password into a different site. The only thing you put into the other site is your OpenID, which is something like https://me.yahoo.com/text-of-your-choosing. There's even a new feature in OpenID 2.0 that lets you just pick "Yahoo.com" so you don't have to enter anything at all relating to you on the other site.
OpenID works very differently to how you are imagining it.
I'm kinda worried that yahoo have - without my permission - put my username and password for them in the openid database.
There's no "OpenID database", it's decentralised. If you use your Yahoo OpenID on a website, that website sends you to Yahoo, where you are authenticated against the same Yahoo database that you've always had your account details in. When Yahoo decides you are who you say you are, they send you back to the original website. Your username and password haven't gone anywhere.
OpenID promises single signon, but can't deliver it because everyone wants their own walled garden - Yahoo and AOL don't want to share users.
According to the AOL developers' blog, they are actively working on making their products accept OpenID, and even if they weren't, just because AOL wants a walled garden, it doesn't mean nobody else can become a relying party. There's plenty of utility in OpenID even if all the big players are only providers.
No, you are mixing up OpenID providers with OpenID relying parties. Yahoo and AOL are both OpenID providers, which means that if you have an account with them, then you have an OpenID. The sites you log into are OpenID relying parties, which means that if you have an OpenID you can log into them.
Yahoo and AOL don't have any services that are OpenID relying parties as far as I know (AOL say they are "actively working on it"). But you can use Yahoo and AOL OpenIDs to log into an OpenID relying party, for instance, if you have an AOL account, you can use your OpenID to log into LiveJournal, which is an OpenID relying party.
Fine, but what happens once somebody does get your username and password, let's say a keylogger, or one of these fake banking sites designed to steal your password. Now they can get into everything.
For practically everybody, this is already the case. At present, the username and password they need to crack are for your email account. Then they can access all your other accounts by extension via their forgotten password features.
So the downside of OpenID is a downside that is already present. Something to think about, for sure, but hardly a deal-breaker that should prevent adoption.
Is it really all that secure to have one username and password for every website you go to?
This isn't about having one password. This is about having one account. There's ample opportunity for improved security without the need for passwords. Have your OpenID provider authenticate you via an SSL cert on your USB flash drive if you want, or even via fingerprint recognition, you or your provider can implement whatever level of security you need and there's no need for the relying parties to mess about with their authentication system to accommodate you, it all just works automatically with any OpenID-capable website or web application because it's the OpenID provider doing the authentication, not the websites or web applications themselves.
Websites and web applications are relatively limited in what they can offer in terms of authentication options. OpenID allows people to experiment with alternative authentication schemes without having to drag websites and web applications along with them.
Re:Spending a paragraph being a grammar nazi ...
on
Drupal 5 Themes
·
· Score: 1
Speaking of technical editing, why is it so common to see crap like yourdomain in books? The.example TLD along with example.com etc. have all been reserved for this purpose by RFC 2606 so examples don't conflict with domains that are already in use. Isn't this the sort of thing a technical editor, as opposed to a normal editor, should pick up on? It just reminds me of the stupid novel and film writers that title their works with domain names already in use by others. It's just not necessary.
Slashdot Mirror
What criticism? The complaint didn't describe anything actually wrong with X. I see no problem with the "put up or shut up" response when the other person hasn't even bothered to describe what problems they think need to be fixed.
There are four sentences in my comment. One saying it's not a link. One saying what it is. One saying what it's for. One saying where it came from. I fail to see how the comment relates to any of these, let alone proves them wrong. If you disagree, please explain why instead of ranting about your grudge with the W3C. It's not hard to do, my comment wasn't long or complicated.
Did you mean to reply to my comment? I can't see the connection between what I said and what you are saying.
The external DTD subset isn't just for error checking. It defines the character entities and the content model for element types. If you don't have access to the DTD (or hard-coded HTML-specific behaviour) you can't parse it fully.
Actually, the term is widely used as a synonym for spidering a site. It's rare I see it used in the way you describe. Sorry for the confusion.
"Webmasters" refers to people who run websites, not the W3C. And this particular feature is an artefact of SGML, which was around for over a decade before the W3C ever existed.
You mean like how RFC 2616 describes the caching mechanism that is being ignored by the problem clients? Or are you referring to the established-for-decades SGML system catalogue that they mention in the HTML 4 specification multiple times?
If people writing client software actually did what they were supposed to, this wouldn't be a problem. This is not a designed-in bug, this is caused by a minority of developers eschewing the specifications and standard practice out of either ignorance or apathy.
You're solving that problem at the wrong layer. HTTP already includes caching mechanisms, the W3C already use them, and part of the problem is that buggy software is ignoring them.
Please read the article. This is already supposed to happen. Buggy software fails to do this, which is the problem being talked about.
It's not a link. It's a reference to an external DTD subset. It's there so that generic SGML software can properly parse the document without any special knowledge of HTML.
No, external DTD subsets are a part of SGML, which is at least a decade older than the W3C.
No, Slashdot is not contributing to the problem, that is correct code. Just because a URI is listed, it doesn't mean that software should request it each and every time it sees it. Most code that sees that URI should already have a copy of the DTD in the local catalogue. It's only generic SGML software that cannot be expected to have a copy of the DTD.
Why on earth are you blaming webmasters? They are just about the only people who cannot be responsible for this. People who write HTML parsers, HTTP libraries, screen-scrapers, etc, they are the ones causing the problem. Badly-coded client software is to blame, not anything you put on a website.
This is not mentioned in the article, nor in the article from the source of this survey, UKTV Gold. So where did this claim come from?
Quite frankly, I don't trust UKTV Gold to run a survey properly, especially when they class Mona Lisa and Lady Godiva as "fictional characters".
I'm not sure what you don't understand. Why wouldn't they be OpenID logins? Just because I use the same username and password to authenticate for my Yahoo email and my Yahoo OpenID, it doesn't mean that my Yahoo email address is disclosed to everybody.
You're conflating two different things here: identity and access mechanism. Whether you sign into Yahoo mail via their website or via your mail client, it's still the same user account. Likewise, when you use your AOL OpenID, you might not use the same access mechanism as when you use AIM, but it's still the same identity.
No. You misunderstand. Again. If you aren't trolling, please just go and read an OpenID tutorial or something before posting more silly comments.
Some OpenID providers will only offer the bog-standard username and password authentication. Some OpenID providers will offer better security, for instance via client-side SSL certificates, swipe cards, etc. The people who want this extra security now have the option of going to a premium OpenID provider as opposed to a typical OpenID provider, and all the websites and web applications that accept OpenIDs will be more secure for these people without the websites and web applications having to do anything special to accommodate you.
You, as a security-conscious user, can seek out more secure forms of authentication by picking a better OpenID provider. And you can do this without the websites you use doing anything more than implementing standard OpenID. This is what jfengel is referring to when he is talking about paying for an OpenID.
And no, switching away from an OpenID provider doesn't mean you will lose your OpenID. Switching providers is something that OpenID handles through delegation.
What are you talking about? What system are they putting it into? The OpenID authentication on Yahoo's servers can just query the existing database that already holds your username and password.
You don't put your username and password into a different site. The only thing you put into the other site is your OpenID, which is something like https://me.yahoo.com/text-of-your-choosing. There's even a new feature in OpenID 2.0 that lets you just pick "Yahoo.com" so you don't have to enter anything at all relating to you on the other site.
OpenID works very differently to how you are imagining it.
No, now all OpenID relying parties accept AOL accounts. Please stop misrepresenting the situation.
They should complete this survey so we know exactly how far we can go before offending them.
There's no "OpenID database", it's decentralised. If you use your Yahoo OpenID on a website, that website sends you to Yahoo, where you are authenticated against the same Yahoo database that you've always had your account details in. When Yahoo decides you are who you say you are, they send you back to the original website. Your username and password haven't gone anywhere.
According to the AOL developers' blog, they are actively working on making their products accept OpenID, and even if they weren't, just because AOL wants a walled garden, it doesn't mean nobody else can become a relying party. There's plenty of utility in OpenID even if all the big players are only providers.
No, you are mixing up OpenID providers with OpenID relying parties. Yahoo and AOL are both OpenID providers, which means that if you have an account with them, then you have an OpenID. The sites you log into are OpenID relying parties, which means that if you have an OpenID you can log into them.
Yahoo and AOL don't have any services that are OpenID relying parties as far as I know (AOL say they are "actively working on it"). But you can use Yahoo and AOL OpenIDs to log into an OpenID relying party, for instance, if you have an AOL account, you can use your OpenID to log into LiveJournal, which is an OpenID relying party.
For practically everybody, this is already the case. At present, the username and password they need to crack are for your email account. Then they can access all your other accounts by extension via their forgotten password features.
So the downside of OpenID is a downside that is already present. Something to think about, for sure, but hardly a deal-breaker that should prevent adoption.
This isn't about having one password. This is about having one account. There's ample opportunity for improved security without the need for passwords. Have your OpenID provider authenticate you via an SSL cert on your USB flash drive if you want, or even via fingerprint recognition, you or your provider can implement whatever level of security you need and there's no need for the relying parties to mess about with their authentication system to accommodate you, it all just works automatically with any OpenID-capable website or web application because it's the OpenID provider doing the authentication, not the websites or web applications themselves.
Websites and web applications are relatively limited in what they can offer in terms of authentication options. OpenID allows people to experiment with alternative authentication schemes without having to drag websites and web applications along with them.
Are you sure you don't have an OpenID? If you have a LiveJournal, you have an OpenID. If you have a Yahoo! account, you have an OpenID. If you have an AOL account, you have an OpenID.
Speaking of technical editing, why is it so common to see crap like yourdomain in books? The .example TLD along with example.com etc. have all been reserved for this purpose by RFC 2606 so examples don't conflict with domains that are already in use. Isn't this the sort of thing a technical editor, as opposed to a normal editor, should pick up on? It just reminds me of the stupid novel and film writers that title their works with domain names already in use by others. It's just not necessary.
I'm sure he doesn't. He suffers from chronic RSI and has hired people to type for him in the past (not sure what his current situation is though).
A lot of people pronounce it "Jabber". The name "XMPP" arose when they were moving it through the IETF standardisation process.