I would personally implement it essentially as #2, with the application implementing an interface with a receiveMessage(Message) function and invoking an interface provided by the reload implementation that has a sendMessage(Message) function. Reality needs to be a bit more complicated as, for example, the SIP usage specifies requirements about the certificate of the other side.
I'm happy to provide a clarification in the draft if we can find some helpful text. But I don't see this as needing to be specified in the draft---any of the approaches could produce a valid implementation. It might be a good discussion in an implementers' wiki page, though. Bruce On Sun, Oct 30, 2011 at 5:36 AM, Frederic-Philippe Metz <[email protected]> wrote: > Hi Bruce, thanks for the reply, I agree with you. > I think I missed the point. > > For the implementors, it is not clear (please correct me if I am wrong > Michael): > > The draft says: > "For example, if a P2PSIP node wishes to > establish a SIP dialog with another P2PSIP node, it will use > AppAttach to establish a direct connection with the other node. This > new connection is separate from the peer protocol connection. It is > a dedicated UDP or TCP flow used only for the SIP dialog." > > and > > " AppAttach: used to form application layer connections between > nodes." > > and the paragraph 5.5.2: > > This could mean two things at least (the third is for completeness): > > 1. An application issues an AppAttach to RELOAD and receives the > candidates. The application then have to form the connection itself. > > 2. An application issues a command to RELOAD that does the AppAttach > stuff ( AppAttach -> ICE -> TLS/D/TLS) and RELOAD provides an > application connection to the application (an "OverlayLinkType > connection") > > (3. For completeness: Same as 2, but RELOAD provides a pure TCP or UDP > connection to the application (AppAttach -> ICE -> TCP/UDP). The > application then has to perform TLS/DTLS itself.) > > I assume, with respect to your answer, you mean point 2. applies. Am I > right ? That means An application somehow tells RELOAD to make a > connection and RELOAD provides a application connection the > application then uses to exchange the application messages. > > Best Regards, > Frédéric > > > > On Sat, Oct 29, 2011 at 10:40 PM, Bruce Lowekamp <[email protected]> wrote: >> 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
