At least as the discussion has gone so far, I actually like the idea of this myself, particularly using an option structure of some sort.
There is already a bit of cruft here and there in the protocol (my personal take is that it is a bit too heavy in current form), but this actually looks useful to me, so for now, I'm behind the idea of adding it. David (as individual) Sent from my mobile device -----Original Message----- From: Eric Rescorla <[email protected]> Date: Sun, 12 Jul 2009 11:33:20 To: Narayanan, Vidya<[email protected]> Cc: [email protected]<[email protected]> Subject: Re: [P2PSIP] Client operation in RELOAD At Sat, 11 Jul 2009 23:10:07 -0700, Narayanan, Vidya wrote: > > I'd support this as well. I think this would be quite useful. > > Vidya > > > -----Original Message----- > > From: Hardie, Ted > > Sent: Friday, July 10, 2009 4:25 PM > > To: Bruce Lowekamp > > Cc: Eric Rescorla; Narayanan, Vidya; [email protected] > > Subject: Re: [P2PSIP] Client operation in RELOAD > > > > At 4:10 PM -0700 7/10/09, Bruce Lowekamp wrote: > > >ekr already mentioned that AppAttach is supposed to come into the next > > draft. > > > > > >What if we have a 16 bit field in Attach and AttachLite that specifies > > >role/purpose of the connection? No normative purpose in the base > > >draft, but for use with future extensions. Specify maybe five values > > >for neighbor, routing table, peer optimization, client responsible > > >peer attachment, and client optimization, and allow for future code > > >points. > > > > In general, this sounds like a useful way forward. I don't see that this change adds any value. It's just additional cruft. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
