Re: URI scheme listing for httpsy

On Thursday 14 August 2003 03:32, Larry Masinter wrote:
> Why again isn't this an extension to https?

It is. See:

http://www.waterken.com/dev/YURL/httpsy/#The_https_scheme_*-subset

> Why does it need its own scheme?

For fail-safe use of the authentication protocol.

The specification defines an authentication protocol and two URI
schemes: one for fail-open use and one for fail-safe use. The
fail-open URI scheme, the https *-subset, preserves connectivity
with old client software, but does not guarantee that the security
properties provided by the HTTPSY protocol are in effect. The
fail-safe URI scheme, httpsy, does make this guarantee, but at the
cost of breaking connectivity with old client software.

The https *-subset is only provided as a temporary bridge to
enable deployment of HTTPSY server applications during the rollout
of HTTPSY client applications. A gradual migration to httpsy URLs
is expected.

> You write
>
> "When interpreted by an HTTPSY-unaware client, etc. etc."
>
> but how can you give rules for what a client should
> do, if the client doesn't pay attention to the rules
> in this document?

The full text of this constraint is:

"When interpreted by an HTTPSY-unaware client, the semantics for
this scheme are the same as for the https scheme. The *key_id@
portion of the URL MUST be ignored."

As you can see, the specified behaviour is exactly the behaviour
of existing https clients. The constraint does not place any new
requirements on existing https clients. The purpose of the
constraint is only to specify the https client behaviour that the
https *-subset specification relies upon.

Tyler

-- 
The union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Received on Thursday, 14 August 2003 10:50:00 UTC