Hi, I think that the text addresses mostly the case when the destination type is a nodeId but does not say much about the behavior when the destination type is a resourceId or compressed which are the other allowed destination types. Note that a resourceId can only be the final location in a resource list
Regards Roni Even -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Lowekamp Sent: Wednesday, October 15, 2008 4:00 PM To: JiangXingFeng Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method Jiang, Thanks for looking at this in detail. JiangXingFeng wrote: ... > So I propose to make a few modifications to Attach method in RELOAD to make > the semantics of Attach more clear and avoid necessary connections. > 1. Add more text in Attach section on how to set the destination type in the > Attach request. resource id or node id; I think this would be a good clarification. I will try to add some more text here suggesting why you would route an Attach to a resource-id or to a node-id. > 2. When the responsible peer receives the Attach request, the peer will > check the destination type first. If the destination type is node id, the > peer will check whether the peer's own node id equals to the destination > node id; If they don't equal, sends a error to the sending peer and refuse > to establish connection. I think this is the correct behavior, but it's actually already accomplished in another way. The general routing algorithm only delivers messages routed to a node-id if the node-id is an exact match for a particular node, as described in the third bullet of 6.1.2.1 and clarified in the note in that section. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
