[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: How could RDDL be distributed ?

  • From: Mark Baker <mark.baker@c...>
  • To: Miles Sabin <MSabin@i...>
  • Date: Tue, 16 Jan 2001 15:29:06 -0500

Re: How could RDDL be distributed ?
Miles Sabin wrote:
> Unfortunately I don't think HTTP is a good fit here. Bear in
> mind that there are serious security issues here ... malicious
> subsitition of bogus DTDs/Schemas could be a serious problem.

Sure.  But in my laptop scenario, you control the proxy, so it's easy to
trust.

> The HTTP solution to this would be HTTPS with server side
> certification.

Well, that's one, but HTTPS isn't very proxy friendly, since even the
HTTP headers (which caching proxies are interested in) are encrypted. 
S/MIME or some other body-only mechanism would be better.

> > Don't be too concerned about "hot spots".  Who knows, maybe
> > whomever maintains that document uses Akamai.  Ain't
> > abstraction wonderful?
> 
> I'm _extremely_ concerned about hot spots, and I'm not at all
> convinced that Akamai type solutions will help us here.

It was designed to help with *exactly* this problem (and others too). 
That the architecture of the Web makes it possible is no accident.

Michael added;
> RESCAP is a bit faster and more lightweight than HTTP. By the time
> HTTP has done the 3 way handshake for the TCP session RESCAP
> has already gotten the answer....

With all due respect, that thinking is what encouraged WAP to happen. 
One can always build a more optimized protocol for their app, but let's
consider the cost of doing so first.

RESCAP is fine, but isn't as applicable in the context of HTTP, because
HTTP has its own semantics for managing metadata.

From the RESCAP protocol draft
(http://www.ietf.org/internet-drafts/draft-ietf-rescap-proto-main-01.txt);

"For example, a mail user might want to know whether another mail user
is able to natively display TIFF files before creating a message with a
TIFF file in it."

With HTTP, you compose a HEAD request with "Accept: image/tiff", and
check the response.  If you got a 406, then the receiver doesn't accept
TIFF.

[re Akamai]
> I think that's part of the problem. The abstractions are hiding
> some of the metadata you need in order to determine what or where the
> appropriate copy of something may be....

Why can't the infrastructure responsible for creating the abstraction
manage that metadata?  Why does a client need it?

Anyhow, we're getting way off track from the charter of xml-dev.  Let's
take it offline.

<ObXML/>

MB

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.