At 6:07 AM -0700 7/28/08, Bruce Lowekamp wrote: >I read through the pointers draft and have a couple comments/questions: > >- With the media-type in Section 3, and taking no position on which type >is better or where it should live, is there a reason this type should be >functionally different than that in reload's Section 13.2? They seem >like they are serving the same purpose, ultimately.
They are certainly related. The version in p2psip-p2p-pointers is slimmed down from the previous version (p2poverlay-pointers), which was written before reload had reached its current state (before the merge at all, I think). Reload's current version is a bit "fatter" with aspects which are specific to reload. There are a few things about reload's version that differ in presumption; the reload draft indicates that it is fetched from an enrollment server for example, and it does not use a registry for things like chord-128-X-X values. But could these be merged, or could the reload draft substitute a pointer to an updated version of the pointers draft? Almost certainly. >- I found Section 5 a bit confusing. Although the section title is node >pointer, the text seems to define a resource pointer. At least, that is >my understanding of the phrase "focused on the node and its resources is >proposed here, along with context-dependent ways to use it... to >represent resources". The aim of the section is to provide a way to reference a specific node, or a specific resource at that node, or a specific resource wherever it exists. That's why there are three forms. The most basic is for the node: overlay-node://22301203/ 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. 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 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. > >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? Ted >Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
