The OverlayLinkTypes that reload includes are all message-oriented protocols. It's up to the usage defining the application-id to indicate what is actually passed in these messages. e.g. the sip usage specifies SIP messages for application-id 5060.
Beyond the application-id, I don't think it's the role of an IETF draft to specify how that is presented to the upper layers, though a usage has to specify what is on the wire clearly enough that compatible implementations can be written, obviously. Bruce On Wed, Oct 26, 2011 at 3:20 PM, Frederic-Philippe Metz <[email protected]> wrote: > Hi all, > > I definitely support Michaels question into the P2P group. The draft > doesn't clearly figure out how the connection "description" is > presented to the upper layers. In short terms, the reference point of > a usage using AppAttach is not defined which connection it should > expect. It may cause incompatibility if the same usage (i.e. SIP) > would expect different connection type "formats" from RELOAD. > Best Regards >>> Frédéric > > On Wed, Oct 26, 2011 at 1:04 AM, Michael Chen <[email protected]> > wrote: >> Hi, >> >> We had some discussions at the [email protected] list, and I like >> to post this question here. The base draft makes no mention of whether >> the link between two peers from an AppAttach may/should/must also >> establish D/TLS connection. Without an agreement, two peer will not be >> able to forward the actual SIP dialog traffics. >> >> This could be a big inter-op issue, so I would like the principles of >> this draft address it. >> >> Thank you >> >> --Michael >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
