W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2000

Re: XP Service URIs

From: Mark Nottingham <mnot@akamai.com>
Date: Tue, 21 Nov 2000 13:53:13 -0800
To: Ray Denenberg <rden@loc.gov>
Cc: XML Distributed Applications List <xml-dist-app@w3.org>
Message-ID: <20001121135308.B8965@akamai.com>
On Tue, Nov 21, 2000 at 04:22:23PM -0500, Ray Denenberg wrote:
> Mark Nottingham wrote:
> > Can we assume that every XP service has an identifiable URI?
> It's been a fundamental premise in my thinking, except for the case where
> two parties have prior agreement.
> > If so, perhaps
> > we should consider requiring this?

Sorry, not requiring. I meant formalizing it in the model, as expressed by
the glossary, etc. 

re: when the parties have prior agreement; yes. I think that the 'prior
agreement' scenario has many implications and possible optimisations, but
IMHO we shouldn't plan for it. I.e., let's design a conservative protocol
and if people want to cut corners, etc. when they own both ends, so be it.
At some point there should be a discussion about how this can be expressed;
it may be explicit along with each protocol mechanism, or it may be
summarized in a separate section (my preference). But I digress...

> Depends what we mean by "requiring".
> > .... it would also be good to require the envelope to identify
> > the URI, ........
> I think it would be good to require the envelope to *support*
> identification of the URI. I don't necessarily think that the URI should
> be a required element.

I know that it's a concern that we not stuff too many things into the 'core'
specification, but IMHO service identification is critical for a number of
reasons; it is likely to be the basis of most XP modules that are created
(e.g., with caching, it helps define the namespace; with authorization, it
identifies the realm, with routing, it identifies the target, etc.).
Additionally, it makes a 'virtual hosting' style service much simpler.

I'd prefer something something more detailed than just supporting it (taking
into account previous discussion about "supported" functionalities).

Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)
Received on Tuesday, 21 November 2000 16:53:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:10 UTC