Re: [metaDataInURI-31]: Initial draft finding for public review/comment.

Hey Stuart,

Here's my feedback ...

Section 1.1, example b); I agree that this is the case, but it wasn't
always.  CIRA seriously relaxed the rules regarding the "Canadian
presence" requirement a couple of years ago when it took over
administration of dot-ca.  As it relates to this draft though, I'd say
that you should reference the CIRA policy as the authority on
determining what one can and cannot infer from a dot-ca URI (as you,
IMO, accurately describe elsewhere, about successive application of
public specs).  The best URI for this purpose is probably;

http://www.cira.ca/en/documents/q2/RegistrationRules-EffectiveDateJune52003.pdf

And if I can peek into *that* URI (8-), it appears that it's not
appropriate to use it to identify the current CIRA policy, so you may
want to qualify use of it with "at the time of publication of this
finding", or perhaps use this URI instead;

http://www.cira.ca/en/cat_Registrar.html 

Regarding your general question of whether the finding should just say
"Don't peek inside URI", I don't believe it should, because I consider
that at best a "rule of thumb", and at worst, just plain wrong.  I
personally quite like sections 2 and 3, because they clearly demonstrate
this by outlining what information can be gleaned from a URI.

REST's "hypermedia as the engine of application state" constraint has
relevance here too, I believe.  If an agent is hardcoded to know about
URI structure, and uses this knowledge to progress through the
application state machine, then it isn't conforming to this REST
constraint.  As an example of one of problems with doing things this
way, though the resource reachable through this knowledge would have a
URI, Google would have no way of discovering this URI, as it isn't
hardcoded with that same knowledge.  Perhaps that should go in section
1.1?  BTW, the constraint is discussed most directly (AFAICT), briefly
in section 5.3.3 of Roy's dissertation;

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_3

The only other issue that I felt required mention, was that I believe
the statements in sections 2.1 and 3.1 regarding constraining the type
of resource that a scheme can identify, are incorrect; a URI scheme
cannot constrain the kind of resource a URI in that scheme identifies.
The most they can do is declare which types of resources the scheme
was designed to be used to identify.  For example, though "mailto:" is
said to, and most commonly used to, "designate the Internet mailing
address", I could use it to identify my person without any issue, so
long as I'm the one receiving messages at that address, thereby
reinforcing with the message sender that this is an identifier for me.
Luckily, I don't see this issue as key to the point that the finding
addresses, so it should be able to be removed without impact (or left
as is, I suppose - I recognize this may be a rat hole).

Cheers,

Mark.

On Tue, Jul 08, 2003 at 02:41:46PM +0100, Williams, Stuart wrote:
> 
> Folks,
> 
> I've been drafting a finding [1] for TAG issue metadataInURI-31 [2] which
> discusses the encoding of resource properties in URI and the inference of
> resource properties from URI.
> 
> In discussion with the TAG there different viewpoints. At one end of the
> scale is a simple statement of "Don't peek inside URIs" (restricting just
> client behaviour it think). At the other end is a view that its ok to infer
> things that can be derived from a delegated chain of specifications and
> policies rooted in the URI specification. URI assignment authorities may
> publish policies on the structure of URI paths and/or queries that they
> serve.
> 
> This draft is closer to the latter position and written from the
> point-of-view that there is deeper discussion to be had. Are there things
> that can be inferred based on knowledge of the governing specifications -
> are scheme and query components truly opaque? Does the presense of a
> fragment ID make a material difference to the sort of thing being reference
> (shades of httpRange-14)? There is also the question of the role of the
> person or software inspecting a URI: an observer of assignments made by
> others; the assignment authority itself; and intermediate infrastructure
> such as proxies, gateways and caches.
> 
> I would appreciate some feedback on this draft. Whether a simpler, shorter,
> finding is a better path to take? Whether "Don't peek inside URIs" is all
> that need be said?
> 
> Thanks in advance,
> 
> Stuart Williams
> --
> [1] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20030708.html
> [2] http://www.w3.org/2001/tag/ilist#metadataInURI-31

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Wednesday, 9 July 2003 09:20:51 UTC