RE: [metaDataInURI-31]: Initial draft finding for public review/c omment.

Hi Mark,

Thanks for the feedback.

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org] 
> Sent: 9 July 2003 14:26
> To: www-tag@w3.org
> Subject: 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

The example was on that Tim Bray suggested... I hadn't realised it went so
deep (as in country specific Ts&Cs over who can have DNS names that end in a
country code).

I'll work on adding the reference... which I shouldn't assume is a set of
"Registration Rules" or whatever the resource is, that it became effective
on 5th June 2003, or that it delivers a PDF representation :-)

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

That was the point of sections 2 and 3 - glad you like them.

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

Understand the first part (hardcoded knowledge of URI structure), understand
the second part (progression through application state). Don't understand
the conjuction ("and uses this knowledge to") of the two. Maybe you could
elaborate if you think it would be worthwhile (and remain on topic).

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

Sorry... you've probably tried really hard to keep it brief here... but its
not managing to make sense of it.

There are probably a load of assumptions buried in "this way".

>  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

Will take another look.

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

I think it's a question of conforming to standards/specifications. If a spec
imposes a constraint that you ignore then you are not conforming to the
spec. The URI spec could forbid schemes making such a constraint (but I
don't think it does), therefore a scheme could impose such a constraint.
Whether any schemes actually do is probably up for discussion. The language
in some at best leave you unsure of whether a constraint is intended - maybe
the absense of 2119 capitalised imperatives is a clue.

> The most they can 
> do is declare which types of resources the scheme was 
> designed to be used to identify.

I will agree that the authors intent is not clear in the narrative.

[RFC2368]
   The mailto URL scheme is used to designate the Internet mailing
   address of an individual or service. In its simplest form, a mailto
   URL contains an Internet mail address.

The use of the word "is" seems pretty factual. Its certainly not an
imperative like MUST, MAY or SHOULD. 

At least one way of reading this would be that uses of mailto: scheme URI
that do not 'designate' an Internet mailing address are non-conformant uses
of the URI.

Another reading is the is that the "is" is really a "may be", granting
permission to use them for that purpose, but not restricting their use to
only that purpose.

We also find varing use of the words 'designate', 'identify' and 'denote' in
various works describe what URIs do. They may be intended as synonyms, or
the use of particular words may mask subtle differences.

Then of course there is common usage built up around the various
specifications.

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

I think that the point is arguable. You have certainly used a mailto URI to
indirectly identify yourself... but if you want to make assertions about the
mailbox itself and not about Mark Baker, what identifier would you use if
you have used up mailto:distobj@acm.org as identifying you.

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

Well looks like I took the bait.

> 
> Cheers,
> 
> Mark.

Cheers,

Stuart
--
> 
> 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 Friday, 11 July 2003 11:59:42 UTC