Re: How could RDDL be distributed ?

[Mark Baker <mark.baker@canada.sun.com>]

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