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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 8 Dec 2001 00:40:02 -0500

> -----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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 10 Dec 2001 01:15:58 -0500

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

--
Flemming Andreasen
Cisco Systems

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Dec 2001 09:57:26 +0200

Hi,

In a SIP phone, there may be a "database" of previous incoming calls.
Them, when I want to call someone back, I browse the database, pick one
of the previous calls, get the Reply-To header value from that call and
send the INVITE.

In a gateway, however, that probably wouldn't work. How does the
gateway know how to which previous incoming call it shall map a new
outgoing call? Yes, there are some specific scenarios where it may work,
but those cases are very rare and non-generic I belive.

Then, a couple of questions:

Q1:

Eg in a mobile environement, what happens if I need to "update"
the information I sent in the Reply-To? SIP defines a mechanism (using
the REGISTER method) to update location servers, but not the end-user
which have the Reply-To value. So, if I have sent different Reply-To
header values to every user I've called, do I have to send REGISTER for
all of those?

Q2:

Is it allowed to only include the HOST part in the header, and let the
other party insert the USER part when it calls back?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Dec 2001 10:26:45 -0700

> but those cases are very rare and non-generic I belive.

A gateway doesn't have the notion of responding to a call, so the
concept makes no sense. Think of email: if I just send you another email
(not hitting "Reply"), it will not use Reply-To, but use a "manual"
reply-to (e.g., your business card).

> header values to every user I've called, do I have to send REGISTER for

Reply-To works best if you include a permanent address, not something
that changes every time you change your cell. We can't prevent somebody
from including [email-masked] in their Reply-To, in either mail or
SIP. 

> other party insert the USER part when it calls back?

I can see no reason to do this.