Hi Bruce, great that we can discussed this point. I guess "helpful text" means that I should suggest one :-) I will think about it if so. On the implementation side, I would assume that there doesn't exist any assumptions what the connection should look like to the usage and as a consequence, it would be configurable in an implementation.
There's one question open: The problem came from an implementation design where one implementor thought that the application with the SIP usage expects a pure TLS/DTLS connection from RELOAD (#2) to send raw SIP stuff and the other implementation would expect a TCP/UDP connection (#3) where the usage (I mean application) would do the TLS/DTLS stuff on its own. They would not be compatible to each other. Shouldn't that be standardized that (when using RELOAD) an application has to expect a special kind of connection (maybe in the usage draft for every usage) ? If not, if the connection coming from RELOAD should be assumed as a raw connection (even if TLS/DTLS is already done in RELOAD) and the usage (i.e.SIP) i.e. wants to use TLS then the usage (application) should do TLS on top of the RELOAD connection ? Cheers, Frédéric On Sun, Oct 30, 2011 at 4:32 PM, Bruce Lowekamp <[email protected]> wrote: > 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
