Hi Thomas, On 19/04/16 22:43, Thomas C. Schmidt wrote: > Hi Stephen, > > On 19.04.2016 23:05, Stephen Farrell wrote: > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 5.1: I guess it's too late to ask, but I'll ask >> anyway, just in case this hasn't yet been implemented >> and it's not too late... I can see why you want to >> support SIP URIs and can't e.g. only support SIPS URIs >> here. But in supporting SIP URIs couldn't you have >> taken an opportunistic security approach to using TLS >> and e.g. maybe treated a SIP URI as if it's a SIPS URI >> except for the certificate validation step? I do get >> that that might restrict re-use of unmodified SIPS >> stacks but maybe that'd be ok in this context. Any >> chance of considering that or is it too late or a case >> where there's not enough energy/interest? (EIther form >> of "no" is a very reasonable answer.) >> > > I guess, something similar to opportunistic security is actually > happening on the RELOAD overlay. All links are (D)TLS encrypted. Further > security additives are out of scope for the moment, I would be tempted > to say. > >> - Just out of curiosity, are folks deploying this >> anywhere? >> > > The whole P2PSIP story is suffering from a much delayed standards > process (it started in 2006). For example, we had a joint implementation > with Deutsche Telekom and quite a number of others had efforts, too. All > this seems quite a while ago. Currently, we are more on finishing the > work that unfortunately had circulated way too long in the WG.
Understood. In that case, I'm fine with you not trying to polish it more. Cheers, S. > > Cheers, > Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
