Subject: Re: URI references and aggregation

From: Graham Klyne <[email-masked]>
Date: Mon, 10 Jan 2000 15:57:34 +0000

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.

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

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

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

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.

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

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

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

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.

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

At 12:21 PM 12/20/99 -0800, [email-masked] 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-masked])

---

From: [email-masked]
Date: Mon, 10 Jan 2000 10:40:13 -0800 (PST)

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

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

> tag can be used in similar fashion as a URL to retrieve information about 

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 

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.

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

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

> limited to being a URL.  So a mechanism for resolution is not necessarily 

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.

> like the idea of using a URN form, as suggested by Larry, as part of the 

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.

> mapping from feature tag to 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.

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

> I trust I've not grasped _completely_ the wrong end of your proposed.

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

---

From: "Martin J. Duerst" <[email-masked]>
Date: Tue, 11 Jan 2000 09:05:53 +0900

> the resolution mechanism may be to simply dereference to URL.

Just some very short points:

- Unsing urn namespaces to solve problems of conneg syntax seems
  not a good idea.
- Restricting each class to a single urn namespace seems a bad
  idea.
- Even if resolvability may not always be possible, and indeed
  not always necessary, artificially making it difficult by
  betting on the wide use of URNs and the associated resolver
  infrastructure is also questionable.

Sorry for being dry and straight.
I guess Ted's comments went into a similar direction.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

---

From: Graham Klyne <[email-masked]>
Date: Mon, 10 Jan 2000 22:26:40 +0000

Ted,

I'm still struggling to fully understand your position here.  There seem to 
be a couple of points that need to be more fully explored:

>would affect more capable devices and their ability to use multiple

It seems to me that a URL (potentially) represents such a wide range of 
possible pointer types that calling it a "single pointer type" is kind-of 
strange.  I find it difficult to appreciate that allowing URNs and URLs 
really adds much in the way of complexity.  At the end of the day, they're 
all URIs.

>choices for unregistered feature tags.

[...]

>raise the question: why not just start with "http://host/path/" ?

OK, I've misunderstood the nature of a URN.  I was trying to capture the 
idea of an identifier that was not bound to a specific resolution protocol, 
like "mid:..." or "cid:..." [RFC2392].  I had not thought of these as URLs, 
but on closer examination that's just what they are.

I agree that my proposals should not have been so URN-centric.

But I still fail to see any real advantage in excluding the use of URNs.  I 
think they effectively
amount to just another scheme that a limited system may or may not be able 
to handle.

>and markers.  I don't propose collapsing them into the same syntax.

I'm not sure what you mean here (particularly by "using both position and 
markers").

>sorry if the first message was less than clear.

I think my mental fog is clearing a little ... sorry to be so dense.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Tue, 11 Jan 2000 10:57:12 +0000

Martin,

I'm going to respond to your points here, partly in the hope of provoking a 
response that improves my understanding.  But you may notice from my other 
response that I had slightly mistaken the division between URNs and URLs, 
so my proposals are somewhat moot.

>- Unsing urn namespaces to solve problems of conneg syntax seems

OK -- I see URNs are not enough.  But should they be excluded from a solution?

>- Restricting each class to a single urn namespace seems a bad

I was coming at this from the point of providing a common URI form 
associated with registered feature tags, rather than *restriction* of the 
syntax to specific URN forms.  Indeed, it was not my intent that there 
would be any changes to CONNEG syntax;  I was trying to run with Ted's idea 
of having some degree of uniformity in handling, while maintaining the 
fundamental distinction between features and aggregates.

>   infrastructure is also questionable.

Well, yes.  I was punting a bit with the idea of ad-hoc mechanisms, but I 
agree URNs are not needed for that.

#g

------------
Graham Klyne
([email-masked])

---

From: [email-masked]
Date: Tue, 11 Jan 2000 10:31:36 -0800 (PST)

Graham,
	Thanks for your comments; I'll give replies in-line.
					Ted
	
> really adds much in the way of complexity.  At the end of the day, they're 

It's hard to argue against the point that they are all URIs at the end
of the day; they certainly are.  I also agree that the fairly regular
syntax of the URN doesn't add that much complexity.  What's driving me
in this direction, though, is that we lack a single pointer type for
referring to the feature tags.  The "unregistered" group can't be
referenced by URNs, for the reasons given below; that leaves
registering names for everything, which we've agreed isn't appropriate
for the "unregistered" group, and providing URL pointers for all of
them, which seems fairly easy to accomplish.

I actually don't object to the idea of also having URNs, but I don't
want it to be at the expense of having URL pointers to the registered
and global tags.  It may well be that the URN pointers would come into
wider or dominant use when URNs in general are more widely available.

Having selected URLs as the "uniform" pointer type for the feature
tags, there seem to be some good reasons to keep on that track for the
aggregates (which again can't be URNs).  I do think there will be a
fair amount of complexity in this system, as multiple URL schemes will
be used in the pointers.  I don't think that complexity extends into
the need to provide resolution mechanisms for all of the possible URL
schemes.  The ability to dereference these shouldn't be a
pre-requisite for this model to succeed.

> but on closer examination that's just what they are.

This is exactly the kind of identifier that I had in mind for the
hashes; it's not bound to a particular resolution protocol, but can be
used reliably as a unique key into a index of known aggregates. I
think these are likely to be used most commonly when there is a fairly
limited set of possible values.  Some of the fax folk have discussed
it as a way of short-cutting the negotiation process, and I believe it
would also be useful in some of the limited capacity wireless devices.

> I'm not sure what you mean here (particularly by "using both position and 

Probably freshman linguistics haunting me (positional v.  inflected
grammars); I meant that I would not collapse the URL pointers for
aggregates into the u. faceted form for feature tags, either by
overloading that facet or by forcing them to be usable in the same
places in the grammar.  As you have noted several times, they are
different--one represents a feature and one represents a predicate.

Thanks again for your continued patience with my poor attempts at
making this clear,
			regards,
				Ted

---

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 12 Jan 2000 10:10:03 +0900

> OK -- I see URNs are not enough.  But should they be excluded from a solution?

Not at all. Say URI, reference RFC 2396, and they are included.

> fundamental distinction between features and aggregates.

It might be a good idea to use URNs for IANA-registered features
at a time we have more experience and implementation of URNs, and
in that case, it may even be a good idea to have a single prefix
for these and only for these (because they represent something
different e.g. from books, for which you would have isbns).
But trying to cover user-defined (non-registered) features in
the same namespace would involve a rather complicated infrastructure,
most probably too much for what you get.
Also, as long as the simplest examples of urn namespaces, the
ones for rfcs and internet-drafts, don't work out of the box
for major browsers, I'm not sure we should bother IANA with
more of them.

Regards,   Martin.