Re: Attributes should only be there if part of the name/address space

Dan Connolly wrote:
> 
> Daniel LaLiberte wrote:
> >
> > Tim Berners-Lee writes:
> >  >  under no circumstances should any
> >  > information other than those needed to identify an object be
> >  > included in the URL.  If the information *is* needed to identify
> >  > the object, then it must (clearly) be included in the URL.
> >
> > This is a good policy, but I want to clarify something.  The question
> > is, what is the "object" that is identified?
> 
> It seems very useful to me to say that "objects" (i.e. resources)
> are, by definition, identified by their URL.
> 
> i.e. different URL means, by definition, different object.
> 
> In this case, an object isn't directly observable: the only
> way to observe it is to send it messages and see what comes
> back.
> 
> See: http://www.w3.org/pub/WWW/Architecture/Terms#resource
> 
> I might restate Tim's distinction between 'information needed
> to identify an object' and other sorts of information in terms
> of 6th grade grammar: restrictive and non-restrictive clauses.
> 
> If you're talking about "the document XYZ, which has title
> ABC" then then ABC must not be part of the identifier. Because
> you might want a reference ala "the document XYZ, which
> has author Fred" to be recognized as the same resource.
> 
> On the other hand, you might refer to a resource using
> a restrictive clause: "the service ZZZ that started in 1996".
> In this case, "the service ZZZ that started in 1995" is a
> distinct resource. So the year is part of the URL.

I like this analysis, and would welcome some suggested wording
for how we might get this captured in draft-masinter-url-process
Internet Draft.  Suggestions to ietf-url@imc.org. While you
might imagine we could add it to the "generic syntax" draft
(draft-fielding-url-syntax), I think that we're really in
the area of future philosphy rather than present reality.


> > Now, it is possible to identify the collection with one identifier and
> > also identify each of the individual members of the collection with
> > their own independent identifiers.  HTTP 1.1 provides a different
> > alternative, that of entity tags for identifying individual members of
> > a collection all identified by a single http URL.
> 
> I don't consider that etags refer to different resources: they refer
> to entities in responses from resources. They're used to predict
> how a resource will respond to a message, so that you can avoid
> the traffic altogether.
> 
> > My suggestion is that it is desirable to have a uniform format for
> > the complete identification of an object, including all the parameters
> > that were used.  It may not always be possible to create or provide
> > such an identifier, but when it is, it is useful.
> 
> Hmmm... I suppose so. That is, given any http resource H, you
> can define another resource, H', where sending messages to H'
> is defined as sending messages to H with certain parameters
> bound to certain values.
> 
> Doing that with a new URL scheme is possible.
> 
> But let me suggest another possibility: rather than
> computing the address of H' from the address of H and
> the parameters, we leave the information provider to
> choose any address at all for H', and provide external
> metainfo that allows clients to discern the relationship.
> 
> For example, suppose you want "the resource http://www.w3.org/
> where accept-lanugage is fr". Hmmm... the strategy I'm
> describing doesn't allow you to express exactly that. Rather,
> it allows you to express "a resource that is a french
> variant of http://www.w3.org":
> 
>         <about href="http://www.w3.org/index.fr">
>                 <link href="http://www.w3.org/" rel=language-variant>
>                 <meta name="content-language" content="fr">
>         </about>
> 
> Dan

We went around on this many times in HTTP-WG. In the end, it was:
the resource provider gets to decide what the granularity of
"resource" is. If the resource provider wants you to be
able to name "the resource http://www.w3.org/ where accept-language is
fr" 
then the resource provider should give it a name.

If we wanted ETags to be "names", we would have given them more
global scope. This was also a lengthy debate in the working group;
in the end, we just needed a protocol element with local scope,
and increasing the scope of it (e.g., by using content-IDs as
ETags) just got in the way.

I'm not sure if this belongs in the URL document. It _is_ a discussion
that seems to be repeated if not recorded, but I'm not sure where
or in which document it would fit. Suggestions?

Thanks,

Larry