Re: [Sip] Open Issue #188: Reply-To

[Flemming Andreasen <fandreas@cisco.com>]

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:brett@broadsoft.com]
> > Sent: Friday, December 07, 2001 4:21 AM
> > To: sip@ietf.org
> > 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
> jdrosen@dynamicsoft.com                     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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip