At 2:15 AM -0700 7/29/08, Bruce Lowekamp wrote: > > > overlay-node://22301203/ > >so my understanding is that 22301203 is a node-id
Yes. > > >> that can be decorated with the context id, if there is no existing >> context or there would be ambiguity: >> >> overlay-node://22301203/;context="http://introducer.example.net/\ >> example.odd"? >> >> but it remains a pointer to the node. >> > >and this is a pointer to a node-id with a reference to the overlay-pointer Yes. > > To point to a resource at that node, the draft uses this syntax: >> >> overlay-node://22301203/;context="http://introducer.example.net/\ >> example.odd"?resource=service-instance >> > >so this is where I get confused. A "resource at that node" is an >unusual thing to want a pointer to (unless you're interested in >diagnostic information). As an external pointer, it might be rare. I think it would be more usual in an internal context (possibly diagnostic, possibly to have a URI pointer to a specific instance). > What I would expect to want to be retrieved >would be a resource in an overlay. > > or >> >> overlay-node://22301203/;context="overlay://enrollment.example.org/\ >> ;otype=pastry"?resource=example.iso >> >> when using the overlay URI scheme. >> >>> So if this is pointing to a resource, I would prefer the host-part of >>> the URI (is that the right name now?) to be a search term rather than a >>> hash, i.e. [EMAIL PROTECTED] >> >> For host part, I think you mean authority section. The syntax allows >> you to elide that, so that you can reference a resource within a context >> without including any node. >> >> >>> My understanding of the URI in Section 5 is that resource= would be a >>> kind in reload's current terminology. >> >> It could actually be a filename, if you want to say something like >> "I want the debian.iso file stored at this node id in this overlay >> context" >> >> overlay-node://22301203/;context="overlay://enrollment.example.org/\ >> ;otype=pastry"?resource=debian.iso >> >> I think this is different from "kind" in the current document. >> > >kind is a type, like a certificate or a sip registration. A resource >name is something like [EMAIL PROTECTED] So what I might want to do >is retrieve the certificate for [EMAIL PROTECTED] from the example.com >overlay. Normally this is done by hashing [EMAIL PROTECTED] to produce >a Resource-ID and then the peer responsible for that Resource-ID is >located. But since you don't know what peer will be storing that >resource under normal conditions, you wouldn't want to look up a >resource on a peer. Evolving from your syntax, if I use a resource-id >instead of a peer-id, what I could see would be > >overlay-resource://resource-id/;context=overlay-pointer;kind=cert > >One of my initial thoughts was that I would rather use the resource-name >than the id since it's expected to be human-readable. > >although the ordering of this bothers me. Hierarchically, wouldn't >something like > >overlay://overlay-pointer/resource-name;kind=cert > >be a bit better from a top-down perspective? > >>> Separate from those questions, my other thought when reading this is >>> whether the overlay specification needs to be different for something >>> that is trying to direct a node to make a query to an overlay as a >>> client vs a spec that is intended to be used by new peers. I think >>> reload would support a one-shot query as it exists now, but it certainly >>> hasn't been a design focus. >> >> I'm not sure what you mean by overlay specification here. The >> overlay URI scheme and odd files? >> > >I was thinking of the overlay-pointer type. Essentially random >wondering of whether there should be a shorter description available of >how to simply make a query to an overlay as a client than is required to >join the overlay as a peer. Or maybe there would be more peers >available for clients to contact to make query than are available to >serve as bootstrap peers. > >Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
