- 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>
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