XML is not a language, in the sense that it doesn't define any semantics; only syntax. It's up to the person using XML to create a language out of its constructs (elements and attributes and such).
It's best to think of XML as a language construction toolkit. In the same manner, SOAP is a protocol construction toolkit, more than a protocol in its own right.
Ernst & Young have a regular P3P Dashboard Report[PDF] that summarizes adoption of P3P by large Web sites.
Privacy is a difficult issue; P3P has been derided because it doesn't do enough (actively negotiate or protect your privacy), because it does too much (intrusion into the browser, difficult to implement) and generally because it's too complex.
As a result, it's a compromise that noone is 100% happy about, but it does give us something to work with. Standards that try to do everything for everyone almost always fail.
The W3C is, next week, holding a workshop to look at the future of P3P; I haven't had a chance to read the position papers yet, but the fact that they're holding a workshop shows that they know there's more work to do.
The Web is a shared information space; GET is its designated means of making a safe, side-effect free request for retrieving a represntation of a resource.
This isn't debatable; it's enshrined in the protocol --
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
15.2 Attacks Based On File and Path Names
Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
Representation retrieval is safe: Agents do not incur obligations by retrieving a representation.
Reuters did nothing wrong, because it isn't the act of linking to an object that makes it available on the Web (and doing so is still, in most reasonable people's minds, protected; see the deep linking issue). Rather, it's the act of, well, making it available, by exposing an interface that understands GET and other HTTP methods as appropriate.
After all, a protocol is, in a very real sense, a contract. If they had wanted to make the resource available but restrict access to it, they could have used HTTP authentication or even cookie authentication; in either case, they have control over who gets an authentication token. GETing a URI is not illegally obtaining access, because a URI in the request-line is an identifier, nothing else.
It's very likely that the publishers were using software that they didn't understand fully, and that is poorly designed, by making assumptions about the nature of the Web and how resources on it are accessed (i.e., "people only use browsers to navigate the Web").
Even if the entire constellation is destroyed it would result in an outage of no more than a day given the resources that would become available in the aftermath.
Dude... you mean if they take out the Milky Way, you're back up in one day flat? Damn... I know they were working on that Interplanetary Internet thingy, but wow! You Verisign people kick ass! I used to work at Akamai, and we weren't half that distributed (or smart!).
Oh wait a minute, the Milky Way is a galaxy.../me wonders what constellation you're talking about... what constellation are we in, anyway?
If IRI entry software normalizes the characters entered, but the
resource names on the interpreting side are not normalized
accordingly, and the interpreting software does not take this into
account, there is a possibility of "spoofing". Similar possibilities
turn up when interpreting software accepts URIs in various native
encodings or allows accents and similar things to be ignored.
"Spoofing" means that somebody may add a resource name that looks the
same or similar to the user while actually being different, or a
resource name that contains the same characters, but in a different
encoding. The added resource may pretend to be the real resource by
looking very similar, but may contain all kinds of changes that may be
difficult to spot but can cause all kinds of problems.
Conceptually, this is no different from the problems surrounding the
use of case-insensitive web servers. For example, a popular web page
with a mixed case name (http://big.site/PopularPage.html) might be
"spoofed" by someone who obtains access to
(http://big.site/popularpage.html).
However, the introduction of character normalization, of additional
mappings for user convenience, and of mappings for various encodings
may increase the number of spoofing possibilities. In some cases, in
particular for Latin-based resource names, this is usually easy to
detect because UTF-8-encoded names, when interpreted and viewed as
legacy encodings, produce mostly garbage. In other cases, when
concurrently used encodings have a similar structure, but there are no
characters that have exactly the same encoding, detection is more
difficult. A good example may be the concurrent use of Shift_JIS and
EUC-JP on a Japanese server.
Administrators of large sites which allow independent users to
create subareas may need to be careful that the aliasing rules do not create chances for spoofing.
Of course there isn't any such thing as a T-1 in Australia; however, there is an E-1 (the European equivalent; 2 megabits, IIRC).
Most providers in Australia charge around.15/Mb because connect.com.au started per-meg pricing about five years ago, and at the time the majority of Australian ISPs got connectivity through them [disclaimer: I am a former (disgruntled) employee of connect].
Later, when connect dropped their own overseas links and got a 100Mb pipe to Telstra because Telstra was beating them at their own game, a number of the ISPs switched, but by that time the pattern had been set; all of the first-tier providers were doing usage-based pricing.
Although current applications (and some implementations) focus on RPC-over-HTTP-using-XML (and "section 5" encoding), most of the big WS vendors believe the real meat of WS is in literal-encoded documents in long-lived message exchanges.
This buys you a lot; instead of needing to have objects at both ends, you send messages that are described by a schema; the implementations are relatively independent. WS are more flexible, more loosely coupled, and more dynamic.
In this manner, WS is closer to message queuing solutions (e.g., MQSeries, MSMQ, Tibco, etc.) than it is to Corba.
The intermediary model in SOAP hasn't been exploited much yet, but should prove interesting.
Another interesting feature of SOAP is the extensibility that Modules bring you; this should allow a number of common behaviours (like reliable delivery) to be standardized.
Finally, SOAP isn't just over HTTP; again, many vendors believe that HTTP is too limiting and tempermental to be useful for the more interesting applications.
When we were married in early '96, we went to a local jeweler to get rings made. Ina was just starting to play with Ti, IIRC, and she offered to give it a go for our rings.
She ended up using Ti tubing, lining the inside with silver and riviting the metals together with gold. This made the inside comfortable; because it's difficult to work with Titanium, she couldn't round the edges very effectively.
Anyway, cut forward a few months. We're watching the X-Files on a Friday night, and I'm absently playing with the ring.
Take the ring off; twiddle; put it on. Repeat. Repeat.
Oops, It's on the middle finger, not the ring finger. *shrug* Will get it of during the commercial break. Commercial break comes, can't get it off. *shrug* Will have a good look after the show.
Show ends. Wife sees purple finger, is mildly concerned. We tried soap, oil, string, etc., to no avail.
So, we trip down to the local hospital at about 10pm. The take me in the Emergency room, have a few unsucessful goes at it, and say "no problem, we have a tool for this, it'll take five minutes."
Whereupon they produce a shiny, metal torture-device looking thing with a sort of a spur and a handle on one end; the idea being that you clamp the end with the spur around the ring and turn the handle to cut it.
It's a purpose-build ring-cutter. They seem awfully confident about it; apparently, they cost a few grand. We point out that the ring is Titanium.
"What's that?"
"Uhh, they make spaceships out of it"
Two hours and two ruined tools later, the ring comes off. We ended up taking turns with the knob, and passed the time by recounting the X-Files episode's plot.
Ina laughed at me and proceeded to rivit and weld it back together.
It's actually called an inteception proxy; see RFC3040 (this name was chosen to avoid confusion with semantic transparency, which you seem to be doing).
Transparent proxying is a violation of IP routing, plain and simple. This has been discussed ad nauseum on the IETF WREC WG mailing list and the IETF main list.
Even when you get past their detection page, the MSN homepage isn't valid XHTML; they don't close some img elements, and use UPPERCASE img and hrefs throughout.
Interesting that MSN doesn't even allow the W3C's own browser, Amaya.
Even more interesting, their 'error' page has parsing errors, according to Amaya:
Errors/warnings in http://www.msn.com/ line 1, char 280: Unknown XHTML attribute topmargin line 1, char 280: Unknown XHTML attribute leftmargin
Also doesn't seem to validate too well with the W3C HTML validator either.
You need to put a fraud alert on all three of your credit reports. This has three effects: 1) You get a free copy of your credit report, 2) they remove your name and address from the pre-approved offers list, and 3) any new credit grantor will be instructed to telephone you to verify that you really want to open the account.
Hmm, this sounds like a pretty good deal. I wonder if you can "pre-report" fraud for these benefits... legally?
P3Pv1 does *not* allow you to "bargain with websites for... privacy", as the article states.
This capability was in earlier versions of the protocol (it has a long history), but it was taken out for a number of reasons.
The current Candidate Recommendation only allows sites to 'advertise' what their privacy policy is, allowing the client to decide whether or not to send privacy-sensitive information (like cookies, etc.), or whether to make the request at all.
Inserting a proxy when the client doesn't have knowledge isn't something to be proud of; it breaks browsers, violates the end-to-end principle at the IP layer, and brings some serious privacy/data integrity problems to light.
The Australian internet is in a stranglehold by Telstra. Let's see, the government owns a majority of the "privatised" Telstra, and also has oversight over the telecommunications industry. Sound fair?
Australia has a pool of outstanding IT talent, but they're wasted because businesses don't have incentives to open offices there.
Slashdot Mirror
XML is not a language, in the sense that it doesn't define any semantics; only syntax. It's up to the person using XML to create a language out of its constructs (elements and attributes and such).
It's best to think of XML as a language construction toolkit. In the same manner, SOAP is a protocol construction toolkit, more than a protocol in its own right.
Ernst & Young have a regular P3P Dashboard Report[PDF] that summarizes adoption of P3P by large Web sites.
Privacy is a difficult issue; P3P has been derided because it doesn't do enough (actively negotiate or protect your privacy), because it does too much (intrusion into the browser, difficult to implement) and generally because it's too complex.
As a result, it's a compromise that noone is 100% happy about, but it does give us something to work with. Standards that try to do everything for everyone almost always fail.
The W3C is, next week, holding a workshop to look at the future of P3P; I haven't had a chance to read the position papers yet, but the fact that they're holding a workshop shows that they know there's more work to do.
The Web is a shared information space; GET is its designated means of making a safe, side-effect free request for retrieving a represntation of a resource.
This isn't debatable; it's enshrined in the protocol --
and by the W3C's Architectural Principles of the World Wide Web (in progress) --
Reuters did nothing wrong, because it isn't the act of linking to an object that makes it available on the Web (and doing so is still, in most reasonable people's minds, protected; see the deep linking issue). Rather, it's the act of, well, making it available, by exposing an interface that understands GET and other HTTP methods as appropriate.
After all, a protocol is, in a very real sense, a contract. If they had wanted to make the resource available but restrict access to it, they could have used HTTP authentication or even cookie authentication; in either case, they have control over who gets an authentication token. GETing a URI is not illegally obtaining access, because a URI in the request-line is an identifier, nothing else.
It's very likely that the publishers were using software that they didn't understand fully, and that is poorly designed, by making assumptions about the nature of the Web and how resources on it are accessed (i.e., "people only use browsers to navigate the Web").
Even if the entire constellation is destroyed it would result in an outage of no more than a day given the resources that would become available in the aftermath.
/me wonders what constellation you're talking about... what constellation are we in, anyway?
Dude... you mean if they take out the Milky Way, you're back up in one day flat? Damn... I know they were working on that Interplanetary Internet thingy, but wow! You Verisign people kick ass! I used to work at Akamai, and we weren't half that distributed (or smart!).
Oh wait a minute, the Milky Way is a galaxy...
This was discussed on RISKS some time back. They provide a link to a copy of the article.
Also, from draft-masinter-url-i18n-08:
6. Security Considerations
If IRI entry software normalizes the characters entered, but the resource names on the interpreting side are not normalized accordingly, and the interpreting software does not take this into account, there is a possibility of "spoofing". Similar possibilities turn up when interpreting software accepts URIs in various native encodings or allows accents and similar things to be ignored.
"Spoofing" means that somebody may add a resource name that looks the same or similar to the user while actually being different, or a resource name that contains the same characters, but in a different encoding. The added resource may pretend to be the real resource by looking very similar, but may contain all kinds of changes that may be difficult to spot but can cause all kinds of problems.
Conceptually, this is no different from the problems surrounding the use of case-insensitive web servers. For example, a popular web page with a mixed case name (http://big.site/PopularPage.html) might be "spoofed" by someone who obtains access to (http://big.site/popularpage.html).
However, the introduction of character normalization, of additional mappings for user convenience, and of mappings for various encodings may increase the number of spoofing possibilities. In some cases, in particular for Latin-based resource names, this is usually easy to detect because UTF-8-encoded names, when interpreted and viewed as legacy encodings, produce mostly garbage. In other cases, when concurrently used encodings have a similar structure, but there are no characters that have exactly the same encoding, detection is more difficult. A good example may be the concurrent use of Shift_JIS and EUC-JP on a Japanese server.
Administrators of large sites which allow independent users to create subareas may need to be careful that the aliasing rules do not create chances for spoofing.
Of course there isn't any such thing as a T-1 in Australia; however, there is an E-1 (the European equivalent; 2 megabits, IIRC).
.15/Mb because connect.com.au started per-meg pricing about five years ago, and at the time the majority of Australian ISPs got connectivity through them [disclaimer: I am a former (disgruntled) employee of connect].
Most providers in Australia charge around
Later, when connect dropped their own overseas links and got a 100Mb pipe to Telstra because Telstra was beating them at their own game, a number of the ISPs switched, but by that time the pattern had been set; all of the first-tier providers were doing usage-based pricing.
That's not what Web Services are about.
Although current applications (and some implementations) focus on RPC-over-HTTP-using-XML (and "section 5" encoding), most of the big WS vendors believe the real meat of WS is in literal-encoded documents in long-lived message exchanges.
This buys you a lot; instead of needing to have objects at both ends, you send messages that are described by a schema; the implementations are relatively independent. WS are more flexible, more loosely coupled, and more dynamic.
In this manner, WS is closer to message queuing solutions (e.g., MQSeries, MSMQ, Tibco, etc.) than it is to Corba.
The intermediary model in SOAP hasn't been exploited much yet, but should prove interesting.
Another interesting feature of SOAP is the extensibility that Modules bring you; this should allow a number of common behaviours (like reliable delivery) to be standardized.
Finally, SOAP isn't just over HTTP; again, many vendors believe that HTTP is too limiting and tempermental to be useful for the more interesting applications.
When we were married in early '96, we went to a local jeweler to get rings made. Ina was just starting to play with Ti, IIRC, and she offered to give it a go for our rings.
She ended up using Ti tubing, lining the inside with silver and riviting the metals together with gold. This made the inside comfortable; because it's difficult to work with Titanium, she couldn't round the edges very effectively.
Anyway, cut forward a few months. We're watching the X-Files on a Friday night, and I'm absently playing with the ring.
Take the ring off; twiddle; put it on. Repeat. Repeat.
Oops, It's on the middle finger, not the ring finger. *shrug* Will get it of during the commercial break. Commercial break comes, can't get it off. *shrug* Will have a good look after the show.
Show ends. Wife sees purple finger, is mildly concerned. We tried soap, oil, string, etc., to no avail.
So, we trip down to the local hospital at about 10pm. The take me in the Emergency room, have a few unsucessful goes at it, and say "no problem, we have a tool for this, it'll take five minutes."
Whereupon they produce a shiny, metal torture-device looking thing with a sort of a spur and a handle on one end; the idea being that you clamp the end with the spur around the ring and turn the handle to cut it.
It's a purpose-build ring-cutter. They seem awfully confident about it; apparently, they cost a few grand. We point out that the ring is Titanium.
"What's that?"
"Uhh, they make spaceships out of it"
Two hours and two ruined tools later, the ring comes off. We ended up taking turns with the knob, and passed the time by recounting the X-Files episode's plot.
Ina laughed at me and proceeded to rivit and weld it back together.
It's actually called an inteception proxy; see RFC3040 (this name was chosen to avoid confusion with semantic transparency, which you seem to be doing).
Transparent proxying is a violation of IP routing, plain and simple. This has been discussed ad nauseum on the IETF WREC WG mailing list and the IETF main list.
From all accounts, he is cranky and sometimes more than downright nasty.
You just described just about everyone who produces open security software. Hmm... what does that say?
XML wouldn't be a good alternative for CLM2, but it's squarely in scope for RDF and the Semantic Web.
...and watch Farscape. Much better.
Even when you get past their detection page, the MSN homepage isn't valid XHTML; they don't close some img elements, and use UPPERCASE img and hrefs throughout.
Errors/warnings in http://www.msn.com/
line 1, char 280: Unknown XHTML attribute topmargin
line 1, char 280: Unknown XHTML attribute leftmargin
Also doesn't seem to validate too well with the W3C HTML validator either.
Standards indeed.
WTF does ebXML have to do with i18n, and why is it 'informative'?
You need to put a fraud alert on all three of your credit reports. This has three effects: 1) You get a free copy of your credit report, 2) they remove your name and address from the pre-approved offers list, and 3) any new credit grantor will be instructed to telephone you to verify that you really want to open the account.
Hmm, this sounds like a pretty good deal. I wonder if you can "pre-report" fraud for these benefits... legally?
I don't see this at all - was very quick on first load into 0.91.
Perhaps there's something about your machine or connectivity that's causing it?
NCD's rock ass. I had two; one of the portraits and one of the square 15" ones. Fantastic machines; still wish I had them.
*sigh*
and then you can restore whatever got wiped out from backups.
You are using tripwire, right? And keeping good backups?
*grin*
HTTP Version in the request-line *doesn't* imply the types of headers in the message (or at least, minor version doesn't).
Most HTTP/1.0 clients also send a Host header. The number that don't is VERY small, IIRC limited to Netscape 1 and its peers.
EOM
P3Pv1 does *not* allow you to "bargain with websites for ... privacy", as the article states.
This capability was in earlier versions of the protocol (it has a long history), but it was taken out for a number of reasons.
The current Candidate Recommendation only allows sites to 'advertise' what their privacy policy is, allowing the client to decide whether or not to send privacy-sensitive information (like cookies, etc.), or whether to make the request at all.
Inserting a proxy when the client doesn't have knowledge isn't something to be proud of; it breaks browsers, violates the end-to-end principle at the IP layer, and brings some serious privacy/data integrity problems to light.
The Australian internet is in a stranglehold by Telstra. Let's see, the government owns a majority of the "privatised" Telstra, and also has oversight over the telecommunications industry. Sound fair?
Australia has a pool of outstanding IT talent, but they're wasted because businesses don't have incentives to open offices there.
Spot on.