Re: URI references and aggregation

Graham,
	Thanks for your long and considered reply; I'll make comments
in-line.


> Ted,
> 
> I apologize for taking so long to respond to this.  If I understand you 
> correctly, you are proposing that:
> 
> (1) There is an IANA-allocated URL associated (in a well defined fashion) 
> with every registered (IETF-tree and global-tree) feature tag.  The data 
> resource at this URL would be a copy of the feature registration template.

Yes.  The advantage of this actually relates primarily to content
feature references, as it provides a uniform association of URL and
Tag for each of the trees (IETF, global, and URL).  While I believe
many platforms would easily handle the unfaceted, g., and url forms,
there are some limited devices which would benefit from using a single
association method.  This would provide that association method while
retaining the different specification levels.  The standard forms would,
of course, remain valid.

> 
> (2) [At the definer's discretion] the URI part of an unregistered feature 
> tag can be used in similar fashion as a URL to retrieve information about 
> the feature.

Unregistered feature tag will have the same pointer type as the
above-named URL feature pointers.  In practice, anyone using an
unregistered feature tag will be using a URL, not a URN, because of
the URN requirements for long term referencability.  

> 
> (3) Use a URL to name an aggregate, with the aggregate expression being the 
> referenced resource.

Use a URL as a pointer to an aggregate, with the pointed-to-resource
possibly containing the aggregate expression; I don't presume that
resolution is possible.


> (4) Allow a defined form of URN (or a URI that is not a URL) to represent a 
> hash-based aggregate name.

I see this as a pointer in the form of a hash-based identifier; think
of it as parallel to the way message-ids are used as cids in
Multipart-related.  It is not a URN.

> 
> The motivation for this, I understand, is to have a uniform approach for 
> dealing with unknown features, and unknown aggregates.
> 
> I see a number of possible problems here:
> 
> (a) unless a URL can always be resolved to a machine-interpretable 
> definition, I think there there is marginal value in having a uniform 
> resolution machinery.  If the expectation is that an aggregate URL resolves 
> to an interpretable expression, it may be better if simple feature tag URIs 
> are not resolvable, since there is generally no corresponding machine 
> interpretable expression.  Also, there is a syntactic difference between 
> usage of feature tags and aggregate names (i.e. auxiliary predicate vs 
> comparison forms), though it might be possible to finesse that in some way.

I think we disagree on the marginal utility of having a single pointer
type (I don't actually presume that it will always admit of
resolution, but more on that later).  I believe that there are an
increasing number of cases (set-top boxes, low-capacity devices, etc.)
where having a single pointer type will help.  I don't think that
would affect more capable devices and their ability to use multiple
pointer types.

The syntactic differences between feature tags and feature aggregates
are important, and I don't believe they should be finessed.  I believe
that the current proposal retains that difference (at the moment the
potential confusion is between the URL tree and the aggregate).

> 
> (b) the unregistered feature tag form is defined as using URI syntax, not 
> limited to being a URL.  So a mechanism for resolution is not necessarily 
> always present.

In practice, URIs are currently URLs and URNs.  My presumption is that
the long-term referencability requirements for URNs make them unlikely
choices for unregistered feature tags.

> 
> (c) the "<URL>" form in the current feature-hash draft was introduced for a 
> potent reason:  to dispel any possible ambiguity concerning the order of 
> substitution and hash value calculation.
>
> I think there is a need to draw a clear distinction between simple-valued 
> ("primitive") features and composite-valued aggregates, else undesired 
> complexities or even non-determinism may result.
> 
> However, I do believe there is value in providing a well-defined mapping to 
> URI form, with URL and resolution available where appropriate.  I happen to 
> like the idea of using a URN form, as suggested by Larry, as part of the 
> solution.

I agree on the need to draw a clear distinction between simple-valued
features and composite-valued aggregates; I think the <URL> form would
work for that.

I believe Larry argued that a URN form would work for the
IANA-registered features; I don't believe that he argued that it could
work for the unregistered feature tags.  I assume he'll chime in here,
but my presumption is that they won't work for those tags.  If you
agree that a single pointer type is of benefit, that eliminates
substituting URNs for URLs.  If you don't agree on that, then we need
to work out the basic agreement one way or the other first.

> 
> Currently, I perceive there are a two fixed points to be accommodated if 
> the range of proposed capabilities is to be realized:
> 
>     Feature tags (currently the basis of CONNEG expressions)
>     URLs (currently the only proposed form of directly resolvable identifier)
> 
> As far as I can tell, you are proposing what is, in effect, a direct 
> mapping from feature tag to URL:
> 
>     Tag --> URL
> 
> and a corresponding:
> 
>     Aggregate --> URL

Yes and no.  I would retain the syntactic difference between the URL
pointers to Tags and those pointing to aggregates using both position
and markers.  I don't propose collapsing them into the same syntax.

> 
> I would suggest allowing an intermediate URN form that can represent the 
> difference between primitive and aggregate values:
> 
>     Tag       --> URN:a:xxx
>     Aggregate --> URN:b:xxx
> 
> The URNs here would use different URN namespaces, with different resolution 
> properties.  As I suggest above, I'm not convinced that feature URNs should 
> be further resolvable (for now, at least;  it's possible that we'll devise 
> a useful machine-interpretable form for these in future).  OTOH, it will 
> sometimes be useful for aggregate URNs to be resolvable, using ad-hoc or 
> (to-be-)standardized URN resolution mechanisms, possibly on a 
> per-application basis.  A possible ad-hoc mechanism might be a simple 
> textual subsitution of the 'URN:namespace' prefix for an 
> 'http://host/path/' form of prefix;  for aggregate names that contain URLs, 
> the resolution mechanism may be to simply dereference to URL.

I'm not convinced that all of the tags can be URNs (the unregistered
tags seem to fail the permanence test for at least some cases).  I'm
also not sure what the advantage is of going to a URN form; it's less
recognized and the resolution mechanisms are less clear.  Certainly
ad-hoc methods like substituion of URN:namesapce for http://host/path/
raise the question: why not just start with "http://host/path/" ?

There are three related but seperable issues here: (1)is there a
benefit to having a method which can be used to point to tags in any
tree?  (2)is there a benefit to using the same method in a different
syntax to point to feature aggregates, which are predicates rather
than simple tags?  (3)is there a benefit to using a method which
implies a resolution mechanism?

I believe the answer to 1 is yes.  I'm less sure about 2 and 3 .  I am
currently leaning toward the idea that if we do 1, the effort required
to do 2 and 3 is small and there is at least a potential benefit.


> 
> In summary, if I understand your proposal correctly, I am proposing adding 
> a level of indirection via URNs to allow evolution of a uniform resolution 
> framework while preserving the essential distinctions between tags and 
> aggregates.
> 
> I'm not yet sure how to address my point (c) above in this framework, but I 
> suspect that admits a reasonable simple solution.  One approach would 
> simply be to say that the hash is always calculated without further 
> substitution, and that dereferenced expressions would not (normally) be 
> permitted to contain further references.
> 
> I trust I've not grasped _completely_ the wrong end of your proposed.
> 
> #g

And I hope that my comments at least begin to elucidate the original argument;
sorry if the first message was less than clear.
				best regards,
					Ted Hardie





> --
> 
> 
> At 12:21 PM 12/20/99 -0800, [email protected] wrote:
> >Over the past few months, the group has struggled with the question of
> >how to reference aggregations of features; we have discussed most
> >extensively proposals based on MD5 hashes and based on URIs.  During
> >those discussions, it has been clear that there were different use
> >cases for which different methods were more appropriate.  For very
> >feature and resource rich environments, URIs have some clear
> >advantages; for feature and resource limited environments, hashes have
> >advantages.  The obvious solution, support both, has been proposed
> >several times, but I have pushed back as chair to see if we can't come
> >to resolution on a single system which works across multiple
> >environments.  After discussion with the document authors and IANA,
> >my current thought is this:
> >
> >Work with IANA to change the form of the feature registry so that
> >registered features are directly referencable by individual URLs.  (The
> >current registry format is a single text page containing all of the
> >registered features).  This will allow us to reference registered
> >(unfaceted), global, and unregistered features using URLs, which has
> >not been possible up to this point.
> >
> >Use URLs as the pointers for feature aggregates.  As a special type of
> >reference, allow an object identifier URI based on the MD5 hash of the
> >canonical representation of the feature tag and value; the canonical
> >representation for the feature tags will be the URL pointer to the tag
> >(the value representation will continue to be set during
> >registration).  The MD5 hash URI could either be a unique scheme,
> >registered according to the recently established URI registration
> >guidelines, or a data URI (possibly requiring a content type
> >registration through the MIME processes).
> >
> >I believe that this approach gives us a reasonable implementation
> >path for systems with a variety of resource constraints.
> >
> >Please consider this carefully in light of your intended use of
> >the CONNEG systems, and send comments and criticism to the list.
> >                         regards,
> >                                 Ted Hardie
> 
> ------------
> Graham Klyne
> ([email protected])
>