I think we are in agreement as well, and as I have written previously, I was
not suggesting that we rewrite section 2 (modulo the ed's proposed rewrite).
Jean-Jacques.
Henrik Frystyk Nielsen wrote:
> >Regarding node names vs. role names : first of all, I think we've been
> >clear that role names can be chosen to identify a specific node, or to
> >identify some more abstract purpose (next, cachemanagers,
> >etc.)
>
> I agree with the overall trend but I think it is safe to say that
> regardless of the level of abstractness, a role name identifies a node
> in the very sense that it for a particular purpose is the resource
> identified by that name. This doesn't mean that it has to be the only
> node for which this is true, this all depends on the mechanism by which
> identity is discovered. In other words, it depends on the resolution
> mechanism, and here I mean resolution in the broadest possible sense. In
> some instances, the resolution process is tied to DNS, in others it is
> not. In general, we have nothing to say about it other than we allow all
> of the above. The "next" URI is a splendid example of a resolution
> process that is entirely independent of DNS.
>
> >Jean Jacques is right that 4.4.3 needs some cleanup, but I
> >don't think the
> >notion of role name is broken, and I don't think we should be in the
> >business of prescribing how many URI's might be used to
> >identify a node (I
> >believe the web architecture is clear that the same resource
> >can easily
> >have multiple URIs, none of which is necessarily preferred
> >over others.)
> >So, I think none of this is broken in the current spec, except for the
> >need to clean up 4.4.3.
>
> I don't disagree with the effect of this statement although I would
> formulate it as being the result of a slightly different model. Rather
> than saying that a resource can have multiple URIs, I think it is a
> simpler model if we say that each URI identifies a resource and under
> certain conditions, two or more resources can be said to be "equal". The
> "equality" can be expressed in a variety of ways and may be tied to the
> notion of the resolution process above.
>
> If we again look at the "next" URI, then it is considered equal to
> whatever other URI identifies a SOAP node in the context of SOAP
> processing. If, however, we look at the "next" URI and some other URI
> identifying a SOAP node in some other context then they may not be
> equal. An HTTP client would for example never consider them to be equal
> because it doesn't operate within the SOAP processing context.
>
> >During that processing, an error occurs that
> >results from some interaction between the transaction header and the
> >processing for the header that is labeled "next". I think its very
> >reasonable to ask the node to identify itself with a URI, and I don't
> >think we should say anything about what that URI is. If the
> >node chooses
> >a URI that matches a role, so be it. If it chooses a role
> >that matches
> >one used by the transport bindings, fine too, or it can use
> >anything else.
> > Specifications for applications of or deployments of SOAP might well
> >mandate conventions for the nature of such URI's, but I don't think we
> >should.
>
> I agree with this.
>
> As I mentioned in my previous mail, I think section 2 is fine as is.
>
> Henrik