Subject: RE: [Sip] Open Issue #188: Reply-To

From: "Mark Watson" <[email-masked]>
Date: Thu, 20 Dec 2001 11:15:29 -0000

RE: [Sip] Open Issue #188: Reply-ToA Reply-To identity supplied by the user has to be treated with a certain amount of caution, since the user could include any identity at all. There are obvious scams where people send out calls with a Reply-To of some premium rate number etc.

But this is the case with lots of e2e information - as long as the status of the information is clear, there should not be a problem (i.e. 'user beware')

However, it shows that a Reply-To identity which has in some way been verified by the outgoing proxy would have some value. Indeed, the ability to have some network-vouched-for Reply-To identity is a value-added service in itself that the outgoing proxy can provide.

The intention of the RPI 'return' type was to provide both (user provided, and network verified). It seems to me that a wheel has been removed from the privacy draft and half of it is being re-invented. I thought the aim of PRI was to be generic, so that one capability could be re-used whenever a similar requirement emerged.

Just a final point on IPR - AFAIK you don't get IPR on a syntax. So if there is IPR on the RPI header, there would be IPR on other syntaxes for the same thing e.g. Reply-To, From etc. I would doubt that there is any real IPR on these things, as identities of these kinds have been carried in the PSTN for years.

...Mark 

-----Original Message----- 
From: Flemming Andreasen [mailto:[email-masked]] 
Sent: 10 December 2001 06:16 
To: Jonathan Rosenberg 
Cc: [email-masked]'; [email-masked] 
Subject: Re: [Sip] Open Issue #188: Reply-To 

The old privacy-02 draft had a "return" rpi-id-type defined just for this, 
however with the refined scope in the new privacy-03 draft, which only addresses 
network authenticated (and provided) identity information, it was removed. Since 
the UA is presumably the one that determines where it would like return calls to 
go, another header would make sense. Privacy of such a header is trivially 
handled by the UA by simply not supplying it (recall that the reason for 
encrypting the Remote-Party-ID rather than just removing it is to allow for 
things like call trace), unless you are looking for some kind of "scoped" 
privacy (I hope not). I agree that simply adding a Reply-To header to bis for 
this would make sense. 

-- Flemming 

Jonathan Rosenberg wrote: 

> 
> 
> > -----Original Message----- 
> > From: Brett Tate [mailto:[email-masked]] 
> > Sent: Friday, December 07, 2001 4:21 AM 
> > To: [email-masked] 
> > Subject: RE: [Sip] Open Issue #188: Reply-To 
> > 
> > > Proposal: 
> > > 
> > > Its simple. Its compatible. Its well understood. Its going to 
> > > really be 
> > > needed for MESSAGE, probably other things. Let us take the 
> > > simple route and 
> > > add it. 
> > 
> > It seems like an ideal candidate for a 
> > new extension draft or a new version of 
> > sip-privacy. 
> 
> The question is whether this is trivial enough to just put into bis rather 
> than write a separate 1 page I-D for it. sip-privacy is, I think, different. 
> More below. 
> 
> > 
> > What is its relationship to From and 
> > Remote-Party-ID? 
> 
> >From is who sent the request. 
> Reply-To is to whom you should call-back later if you want to talk again. 
> Not necessarily the same, just as they aren't the same in email. 
> 
> Remote-Party-ID provides network authenticated identities. Reply-To is 
> provided by the client. If the network wanted to provide what it believes is 
> the true reply-to address, it would, in theory, insert a R-P-ID with id-type 
> "reply-to" or some other such thing. However, I don't think there is much 
> value in that. Who cares what the network provider thought your reply-to 
> should really be? 
> 
> > 
> > How many entries can it contain? 
> 
> One. 
> 
> > If more 
> > than 1, should something like a q-value 
> > be present to communicate the meaning of 
> > more than 1 value being present? 
> > 
> > Should it contain an expiration value? 
> 
> No. KISS. If its good enough for email, its good enough for us. 
> 
> > 
> > Should it have a similar definition to 
> > Remote-Party-ID so that privacy and trust 
> > issues can be communicated? 
> 
> There are privacy implications, yes. I don't think we need a new R-P-ID 
> type, as I discuss above, but if privacy is requested, I would imagine that 
> the reply-to would be stripped at the edge, else encrypted or some other 
> such thing, as R-P-ID would. 
> 
> -Jonathan R. 
> --- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
> Chief Scientist                             First Floor 
> dynamicsoft                                 East Hanover, NJ 07936 
> [email-masked]                     FAX:   (973) 952-5050 
> http://www.jdrosen.net                      PHONE: (973) 952-5000 
> http://www.dynamicsoft.com 
> 
> _______________________________________________ 
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip 
> This list is for NEW development of the core SIP Protocol 
> Use [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application of sip 

-- 
Flemming Andreasen 
Cisco Systems 

_______________________________________________ 
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip 
This list is for NEW development of the core SIP Protocol 
Use [email-masked] for questions on current sip 
Use [email-masked] for new developments on the application of sip

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 21 Dec 2001 17:19:06 -0500

Mark Watson wrote:

> A Reply-To identity supplied by the user has to be treated with a
> certain amount of caution, since the user could include any identity
> at all. There are obvious scams where people send out calls with a
> Reply-To of some premium rate number etc.
>
> But this is the case with lots of e2e information - as long as the
> status of the information is clear, there should not be a problem
> (i.e. 'user beware')
>
> However, it shows that a Reply-To identity which has in some way been
> verified by the outgoing proxy would have some value. Indeed, the
> ability to have some network-vouched-for Reply-To identity is a
> value-added service in itself that the outgoing proxy can provide.
>

Anything can be a value-added service, but where do we draw the line ? I
could make the exact same arguments for e.g. a Contact header and hence
we should start providing network authenticated Contact headers. We can
probably find lots more if we start looking. Unless we can find a good
real-life example where this kind of functionality would be important,
I'd leave it out.

>
> The intention of the RPI 'return' type was to provide both (user
> provided, and network verified).

I'm not so sure about the network verified part. I think we simply
started using the RPI for all kinds of identity information with little
consideration as to whether it made sense to have it authenticated or
not. The privacy-03 draft has corrected this my only letting the RPI
header apply to identity information that should be verified by the
network.

> It seems to me that a wheel has been removed from the privacy draft
> and half of it is being re-invented.

> I thought the aim of PRI was to be generic, so that one capability
> could be re-used whenever a similar requirement emerged.
>

Right, however we tried refining it to only address network
authenticated identity information. You could of course define another
similar header that addressed not-network authenticated identity
information, but there's not much difference between defining new
individual headers (e.g. Reply-To) versus defining new types in a more
generic typed "user-provided identity" header (ala Remote-Party-ID).

-- Flemming

>
> Just a final point on IPR - AFAIK you don't get IPR on a syntax. So if
> there is IPR on the RPI header, there would be IPR on other syntaxes
> for the same thing e.g. Reply-To, From etc. I would doubt that there
> is any real IPR on these things, as identities of these kinds have
> been carried in the PSTN for years.
>
> ...Mark
>
> > > What is its relationship to >From and
> > > Remote-Party-ID?
> >

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 22:57:51 -0500

Mark, Flemming,

The issue of whether or not to add the "return" type back to the privacy 
spec is, really, orthogonal to this particular issue, which is whether 
to have a Reply-To header in SIP. Adding Reply-To to sip perhaps adds 
more fire to the issue, but it remains orthogonal.

Consensus at IETF 52 was to add it this header. On this list, we had 
emails of support from Dean Willis, Alan Johnston, and Vijay Gurbani. 
There was support, coupled with questions, from Brett Tate.

I think this represents sufficient rough consensus. I am therefore 
declaring this issue closed, and we will add a Reply-To header to sip 
with identical meaning to the usage in email.

-Jonathan R.

Flemming Andreasen wrote:

>>>The question is whether this is trivial enough to just put into bis
>>>
>>rather
>>
>>>than write a separate 1 page I-D for it. sip-privacy is, I think,
>>>
>>different.
>>
>>>More below.
>>>
>>>
>>>Reply-To is to whom you should call-back later if you want to talk
>>>
>>again.
>>
>>>Remote-Party-ID provides network authenticated identities. Reply-To
>>>
>>is
>>
>>>provided by the client. If the network wanted to provide what it
>>>
>>believes is
>>
>>>the true reply-to address, it would, in theory, insert a R-P-ID with
>>>
>>id-type
>>
>>>"reply-to" or some other such thing. However, I don't think there is
>>>
>>much
>>
>>>value in that. Who cares what the network provider thought your
>>>
>>reply-to
>>
>>>should really be?
>>>
>>>
>>>There are privacy implications, yes. I don't think we need a new
>>>
>>R-P-ID
>>
>>>type, as I discuss above, but if privacy is requested, I would
>>>
>>imagine that
>>
>>>the reply-to would be stripped at the edge, else encrypted or some
>>>
>>other
>>

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com