- From: Craig A. Finseth <fin@finseth.com>
- Date: Thu, 13 May 1999 09:02:04 -0500 (CDT)
- To: jim@nc.com
- CC: gomer@lgerca.com, www-tv@w3.org
So how does the client know where the "leading part" of the URI ends and the "path" portion starts. I don't think there is a parsable The applications client does not know or care, just like a client looking up this URL: http://www.foo.com/a/b/c/d/e does not know or care if C is NFS mounted onto b. delimiter in the btv syntax for this. So does the "resolver" need to support the equivalent of wildcards which redirect the requestor to another potential data source for full resolution? The specifics of the optimizations must (necessarily) vary from transport to transport. Each transport must adopt a set of standard rules for defining these optimizations. The rules are part of the definition of the mapping information. Proposed rules and mappings for ATSC have been defined. See below. I understand how fully opaque and fully parsable URI's work, but I'm a bit confused about how the two can be combined. Does the btv proposal assume that partial lookup and redirection support are both implementation details and hence irrelevant to the URI structure? Close. It assumes that they are part of the instantiation of the general structure for each transport. Again, see supporting documents. Supporting documents can be found at: http://www.finseth.com/~fin/uri Craig
Received on Thursday, 13 May 1999 10:02:13 UTC