Here¹s another take on using URIs for resource ids:
Suppose we define the uri of an ALTO resource as
[uri-of-alto-ird] # [resource-id]
Eg, the uri of the default network map in the {9.2.3} example would be:
http://alto.example.com/directory#my-default-network-map
In the IRD, we use the resource-id as the key for simplicity, because all
ids have the same prefix.
BTW, this makes it easier to configure a client to use a specific resource
(e.g., a specific non-default network map) just give the client the uri
of that format.
Also, the resource id can be in any IRD reachable from the IRD in the
resource uri. e.g., the uri of the filtered cost service in {9.2.4} would
be
http://alto.example.com/directory#filtered-cost-map
What do y¹all think of that interpretation?
- Wendy Roome
On 02/05/2014, 12:53, "Martin Thomson" <[email protected]> wrote:
>On 5 February 2014 05:01, Elwyn Davies <[email protected]> wrote:
>> This is not really anything to do with me but I would point out that the
>> Information Centric Networking folks would probably disagree with the
>> view on "new data" that Martin expresses below - ICN would prefer that
>> if the data is the same then it has a single way of naming it and any
>> copy is as good as any other (and the recipient can check it).
>
>It's always nice to conceptualize the next highest layer of
>abstraction, but I find that when enacting anything, the lowest
>abstraction layer that works is often best.
>
>There's nothing wrong with the concept you describe. But I haven't
>found that the abstraction is as useful in practice as it is in
>theory.
>
>> As regards locations and URIs, the ni naming scheme (RFC 6920) for data
>> objects is a URI scheme that specifically avoids incorporating locations
>> in the components that uniquely identify the data whilst allowing a
>> location to be added as a hint.
>
>I didn't suggest ni, for two reasons: ni isn't widely used; and the
>document already has an additional layer of indirection, my concern
>was that the additional indirection was unnecessary, not that a
>different form would be more appropriate.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
