2011/10/31 <[email protected]> > > Hi, > I think it isn't enough beneficial that RELOAD provides connection for > application. > Firstly, it is difficult that RELOAD understand the link type of all kinds of > applications. The Link type defined in RELOAD doesn't necessarily suitable > for all applications.
OverlayLinkType is extensible. If your draft needs something else, please define it. > > Secondly, it is difficult that RELOAD maintains the connection of > application. Different application have different connection maintainence > mechanism, for example, some applications need long connection, but other > applications need short connection. From 5.5.2.1: The application using connection set up with this request is responsible for providing sufficiently frequent keep traffic for NAT and Firewall keep alive and for deciding when to close the connection. Bruce > > Even though RELOAD provides raw connection for application, it isn't more > beneficial than application providing connection itself. But its shortcoming > is obvious, and it increases the coupling between RELOAD and application and > increases implementation complexity. > > So I think it is suitable that applicatin forms connection ifself. Then we > need think about the definition of the link type of AppAttach. It is > different from the link type of Attach, and it should be compatible for all > kinds of application. Maybe the specific options of link type of AppAttach > should be leaved to application. > > > *************************************** > Email： [email protected] > TEL： 025-52871543 > Mobile： 13776637274 > Fax： 025-52872187 > *************************************** > > > Frederic-Philippe Metz <[email protected]> > 发件人: [email protected] > > 2011-10-31 04:35 > > 收件人 > p2psip WG <[email protected]> > 抄送 > 主题 > Re: [P2PSIP] Establish D/TLS after AppAttach? > > > > > 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 > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
