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

From: "Mark Watson" <[email-masked]>
Date: Wed, 2 Jan 2002 14:32:38 -0000

Jonathan,

I can't see how the two mechanisms are orthogonal. Reply-To: seems to be a
straight sub-set of the functionality in Remote-Party-ID in privacy-02.

Anyway, it's your call. If it's closed, it's closed.

I am a little surprised at the enthusiasm for specific solutions over a
generic one.

I thought there was considerable value in a generic solution to this problem
which would avoid the need to re-invent the machinery attached with
communicating identity information every time we encounter a new
requirement. In particular the machinery associated with carrying private
information within a trusted domain (although this doesn't apply to
Reply-To).

There *is* a difference between defining new individual headers (e.g.
Reply-To) versus defining new types in a more generic header (aka
Remote-Party-ID), and that is that the latter offers some forwards
compatibility advantages - I can be sure that (if RPI is supported) then the
new RPI type header will receive the generic RPI processing even at nodes
which do not support the new type. In contrast, a new header will just be
ignored.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 27 December 2001 03:58
> To: Flemming Andreasen
> Cc: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Open Issue #188: Reply-To
> 
> 
> 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:
> 
> > 
> > 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
> >>
> >>-----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
> >>
> > 
> > --
> > Flemming Andreasen
> > Cisco Systems
> > 
> > 
> > 
> 
> 
> -- 
> 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
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 02:24:33 -0500

Mark Watson wrote:

> Jonathan, 
> 
> I can't see how the two mechanisms are orthogonal. Reply-To: seems to be
> a straight sub-set of the functionality in Remote-Party-ID in
> privacy-02.

We've been through this one. R-P-ID is a network provided identity. It 
is not a catch-all for all forms of identification. If that were the 
case, we would deprecate Contact, From, and To, and use R-P-ID instead. 
Thus, Reply-To is an end-user provided reply address.

> I thought there was considerable value in a generic solution to this
> problem which would avoid the need to re-invent the machinery attached
> with communicating identity information every time we encounter a new
> requirement. In particular the machinery associated with carrying
> private information within a trusted domain (although this doesn't apply
> to Reply-To).

That is only an issue for network inserted information. If I wish to 
remain private, I would fill out the From and REply-To and 
New-Fangled-ID header with anonymous values. The issue of general 
privacy services is that the network needs to authenticate me, and thus 
insert headers which later need to be removed. Thus, for NETWORK 
PROVIDED IDENTITY, a general solution is desirable.

> compatibility advantages - I can be sure that (if RPI is supported) then
> the new RPI type header will receive the generic RPI processing even at
> nodes which do not support the new type. In contrast, a new header will
> just be ignored.

See above. It is moot once you realize that R-P-ID is a network provided 
identity.

-Jonathan R.