Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 3 Aug 2009 09:40:54 +0200

Hi,

Regarding UUI.

As we know, the R-URI value is not end-to-end. It may change in the
path, due to normal SIP procedures. That is the reason we have
History-Info: to record what has happened, for applications etc which
needs that information.

But, in my opinion History-Info is not a generic mechanism of
transporting parameters transparently end-to-end, however, and UUI is a
parameter which is supposed to be transported end-to-end. Therefor I
think it would fit better in a separate header.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Friday, July 31, 2009 3:43 PM
To: Hadriel Kaplan
Cc: SIPCORE
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

Hadriel Kaplan wrote:
> I believe the exact charter says "Delivering request-URI and
parameters to UAS via proxy to IESG".  4244bis does that.  It's just
delivering ALL request-uri's, so we're just arguing over how to figure
out which one was the "right" one.
> 
> With regard to UUI, Francois' point was "H-I delivers Req-URI and its
params, but there is no consensus UUI should be a Req-URI param".

Right.

But it does raise the bar for UUI. IIRC, one of the arguments against
using R-URI params for UUI was the problem of them getting lost along
the way - not reaching the destination. If that problem is removed by
H-I, is there another compelling argument for introducing a new header?

	Thanks,
	Paul

> -hadriel
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Dean Willis
>> Sent: Friday, July 31, 2009 5:09 AM
>> To: SIPCORE
>> Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter 
>> delivery
>>
>>
>> I propose that since we're claiming that RFC 4244bis meets our 
>> charter deliverable goal of delivery of parameters from UAC to UAS 
>> that the use cases document for RFC 4244bis should document this use
case.
>>
>> Further, if we find out that History-Info does NOT effectively meet 
>> the requirements of the use case, then we should find some other 
>> mechanism by which to meet that charter deliverable.
>>
>> --
>> Dean
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
> 
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 3 Aug 2009 04:21:47 -0400

I agree that a new header seems suitable to carry this information.
However there may be proxies and middleboxes (B2BUA) which may not pass
this header transparently. 

So does this mean that they will need to be upgraded as well to support
this functionality?

Sanjay

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Christer Holmberg
>Sent: Monday, August 03, 2009 1:11 PM
>To: Paul Kyzivat (pkyzivat); Hadriel Kaplan
>Cc: SIPCORE
>Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS 
>parameter delivery
>
>
>Hi,
>
>Regarding UUI.
>
>As we know, the R-URI value is not end-to-end. It may change 
>in the path, due to normal SIP procedures. That is the reason we have
>History-Info: to record what has happened, for applications 
>etc which needs that information.
>
>transporting parameters transparently end-to-end, however, and 
>UUI is a parameter which is supposed to be transported 
>end-to-end. Therefor I think it would fit better in a separate header.
>
>Regards,
>
>Christer
>
> 
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Kyzivat
>Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS 
>parameter delivery
>
>
>
>Hadriel Kaplan wrote:
>parameters to UAS via proxy to IESG".  4244bis does that.  
>It's just delivering ALL request-uri's, so we're just arguing 
>over how to figure out which one was the "right" one.
>> 
>But it does raise the bar for UUI. IIRC, one of the arguments 
>against using R-URI params for UUI was the problem of them 
>getting lost along the way - not reaching the destination. If 
>that problem is removed by H-I, is there another compelling 
>argument for introducing a new header?
>
>	Thanks,
>	Paul
>
>> -hadriel
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Aug 2009 08:59:14 -0400

There are two questions here:

- Should this UUI requirement be viewed as a use case for
   a general mechanism for passing parameters from calling
   application to called application? (Or is it is some way
   "special" so that it requires a unique mechanism just for
   it?)

- If this is a use case for a general mechanism, then what
   should the general mechanism be?

IMO the answer to the first question is that this should be a use case 
for a general mechanism. The only rationale I see for treating it 
separately is an impatience to wait for a general mechanism.

Dean has been making strong arguments about the second question. I 
really don't have anything to add to them right now.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 Aug 2009 14:24:16 -0500

> think it would fit better in a separate header.

Once again: The reason I lobbied for and requested the milestone for  
end-to-end delivery of request URI AND parameters was SO THAT  
PARAMETERS COULD BE DELIVERED END TO END. That was also the initial  
goal of Jonathan's ua-loose-route draft, although in that process, we  
discovered that the non-parameter part of the target URI was also  
needed for some applications.

If we don't think that History-Info is a generic mechanism of  
transporting parameters transparently end-to-end, then it is NOT  
meeting the goal of the charter deliverable.

Do we, or do we not, have consensus on whether or not History-Info is  
an adequate solution to the problem?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 3 Aug 2009 22:12:38 +0200

Hi,

>needed for some applications.

The initial goal of Jonathan's draft was NOT to transport transparent parameters end-to-end.
 
The initial goal was to make sure that the initial R-URI reaches the other end.

>meeting the goal of the charter deliverable.

The purpose of H-I is to make sure that certain parameters, which may change in the path, are transported end-to-end. 

That is not the same as transporting transparant parameters end-to-end, in my opinion.

>Do we, or do we not, have consensus on whether or not History-Info is an adequate solution to the problem?

I certainly think that that History-Info is a solution to the initial goal of Jonathan's draft.

Sending transparant parameters end-to-end is, in my opinion, a completly separate issue.

Regards,

Christer

--
Dean

---

From: Michael Procter <[email-masked]>
Date: Tue, 4 Aug 2009 17:15:42 +0100

2009/8/3 Christer Holmberg <[email-masked]>:
> Dean Willis:

And that includes any parameters that are part of it.  I thought one
of the main motivating reasons for ua-loose-route was to allow the
"grid" parameter to be passed through transparently, and hence removed
from the gruu draft.  Yes, there are a number of reasons why the rest
of the request URI is also useful, but I thought uri parameters were a
key component, and not just a 'nice to have'.

Regards,

Michael

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 4 Aug 2009 21:59:19 +0200

Hi,
 
>And that includes any parameters that are part of it.
 
Of course. 
 
But, in my opinion the R-URI contains information (which may or may not be changed in the path) used to targeting and finding the UAS - not to transport network transparent data between the users. 
 
I don't think we should start to define out-of-context R-URI parameters just because we have a mechanism (History-Info) which will ensure that the UAS receives them.
 
>I thought one of the main motivating reasons for ua-loose-route was to allow the

AFAIK, R-URI parameters are related to addressing, targeting and finding the remote SIP user. UUI has nothing to do with that. UUI doesn't even have anything to do with the core SIP session itself.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 4 Aug 2009 16:52:38 -0500

I completely agree with Christer on this point.

> Sent: Monday, August 03, 2009 13:13
> To: Dean Willis
> Cc: SIPCORE; Hadriel Kaplan
> > transporting parameters transparently end-to-end, however, 
> and UUI is 
> > a parameter which is supposed to be transported end-to-end. 
> Therefor I 
> The purpose of H-I is to make sure that certain parameters, 
> which may change in the path, are transported end-to-end. 
> 
> >Do we, or do we not, have consensus on whether or not 
> History-Info is an adequate solution to the problem?
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Aug 2009 09:26:45 +0100

It think we need to ask the question whether, for a given class of
information included by the UAC in the original request (e.g., UUI),
that information should be preserved if the request is retargeted.
Clearly most classes of information should be preserved when the
Request-URI changes because of rerouting, but when retargeting occurs
the answer might not be so clear.

So taking UUI, if A sends a request with UUI to B and the request is
retargeted to C, is the UUI relevant to C too, or only to B? If the UUI
has implicit semantics, it is not at all clear to me that it is equally
applicable to C.

If the information is equally applicable to B and C, this would argue in
favour of a separate header field for UUI.

If the information is specifically targeted at B, this would argue for a
URI parameter. In that case, although C might receive the information
via H-I, it will at least know that the UUI was targeted at B and it can
take it or leave it, depending on application. The problem with a
separate header field in this case is that C would need to trawl through
H-I to find out whether the UUI really was targeted at C, and if H-I is
not available (e.g., because of privacy or lack of support) or somehow
obfuscated, then C might interpret the UUI wrongly.

Having said this, the cc-uui draft states:
"REQ-4: The mechanism will allow UUI to be able to survive proxy
   retargeting."
This seems to suggest that UUI should have semantics of being equally
applicable to B and C, and this would indeed suggest a separate header
field. However, I am not sure I have interpreted that requirement
correctly or the motivation for that requirement.

John

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: 04 August 2009 22:53
> To: Christer Holmberg; Dean Willis

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 5 Aug 2009 10:49:30 +0200

Hi John,

>favour of a separate header field for UUI.

Yes.

>"REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting."
>field.
 
That is my understanding, and that is why I have used "network transparent" wording, and that is why I think the information does not belong to the R-URI.
 
>However, I am not sure I have interpreted that requirement correctly or the motivation for that requirement.
 
So, maybe we should clarify that first, then :)
 
Regards,
 
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Aug 2009 09:02:46 -0400

Comment at end

> correctly or the motivation for that requirement.

I agree with you John.

I have been struggling to understand this because of the confusing 
answers I have been getting about UUI formats. The encoding is not 
negotiated, and apparently can include private and/or national formats. 
If that is true, then the info may only apply to certain recipients. If 
retargeted, it may not be understood. I can imagine that it may even 
contain info that should not be seen by another party.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 5 Aug 2009 20:37:08 +0200

Hi,
 
>contain info that should not be seen by another party.

Well, that is a generic issue with SIP - it is difficult to control what is going to happen with your data when certain actions take place in the network.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Aug 2009 14:56:17 -0400

> Well, that is a generic issue with SIP - it is difficult to control what is going to happen with your data when certain actions take place in the network.

That's why we negotiate where we can, and standardize what can't be 
negotiated. And for the rest, we specify that you ignore what you don't 
understand, or else return an error.

I don't think there is enough standardized here (for UUI) for the 
recipient to know if it understands what is received or not.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 5 Aug 2009 21:01:44 +0200

Hi,
 
>recipient to know if it understands what is received or not.

You have the same issue with message bodies sent in the INVITE, before anything is negotiated. Feature tags can of course help in many cases.

But, I wasn't talking about understanding, but whether you want the receiver to receive the data in the first place. Once you've sent your INVITE, you normally don't know what is going to happen in case of retargets etc.

Regards,

Christer

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 11 Aug 2009 17:11:50 +0200

All,

Sorry that I am a bit late in this thread but I am catching up.

The UUI may only be applicable to B but there is no way of knowing if it
may also be applicable to C following retargeting. This will depend upon
the content of the UUI, its purpose and the capabilities of C.

The key issue with trying to pass the UUI as a parameter in H-I is
Privacy. If A sets Privacy to value 'header' then the H-I entry included
by the retargeting to the registered terminal address will be removed
and will not even be received by B let alone C as the H-I will be
removed.

You need to place the UUI in a separate header to ensure that it is not
removed when the URI is protected by Privacy.

Ian Elz

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 05 August 2009 09:27
To: Francois Audet; Christer Holmberg; Dean Willis
Cc: SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

John

> > The initial goal was to make sure that the initial R-URI reaches the

> > other end.
> > The purpose of H-I is to make sure that certain parameters, which 
> > may change in the path, are transported end-to-end.
> >

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Aug 2009 11:29:32 -0500

> removed when the URI is protected by Privacy.

So if we assume that 4244bis is our mechanism for passing parameters
from UAC to UAS, then we have to realize that this completely doesn't
work in conjunction with Privacy.

It seems evident to me that we might want to pass parameters from UAC to
UAS even when we want identity privacy. This argues against 4244bis
being an acceptable solution to the problem.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 19 Aug 2009 17:54:16 -0500

The RFC 4244bis does not allow for "removing" entries for achieving privacy.
Instead, it uses anonymizing (like RFC 3323). The parameters should therefore not
be removed.

I guess, one could decide to remove them, just like one could decide to remove the
new field that we could be defining.

In other words, I think this is a red herring. 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, August 12, 2009 09:30
> To: Ian Elz
> Cc: Elwell, John; Audet, Francois (SC100:3055); Christer 
> Holmberg; SIPCORE; Hadriel Kaplan
> > The UUI may only be applicable to B but there is no way of 
> knowing if 
> > it may also be applicable to C following retargeting. This 
> will depend 
> > upon the content of the UUI, its purpose and the capabilities of C.
> > 
> > Privacy. If A sets Privacy to value 'header' then the H-I entry 
> > included by the retargeting to the registered terminal 
> address will be 
> > removed and will not even be received by B let alone C as 
> the H-I will 
> > be removed.
> > 
> > You need to place the UUI in a separate header to ensure that it is 
> > not removed when the URI is protected by Privacy.
> 
> 
> So if we assume that 4244bis is our mechanism for passing 
> parameters from UAC to UAS, then we have to realize that this 
> completely doesn't work in conjunction with Privacy.
> 
> It seems evident to me that we might want to pass parameters 
> from UAC to UAS even when we want identity privacy. This 
> argues against 4244bis being an acceptable solution to the problem.
> 
> --
> Dean
>

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 20 Aug 2009 04:49:30 -0000 (UTC)

> Instead, it uses anonymizing (like RFC 3323). The parameters should

Are "anonymized" parameters useful?

--
Dean

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 20 Aug 2009 18:34:55 +0200

If the parameters are associated with a URI and the URI is anonymize the
as Dean stated are the remaining parameters useful?

If the parameters are not associated with the specific URI then why are
they URI parameters? 

Is there somewhere which defines anomymizing as just changing the URI
and not the associated URI parameters?

Is there a possibility that leaving a URI parameter when anonymizing
could reveal user information?

Ian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 20 August 2009 05:50
To: Francois Audet
Cc: Dean Willis; Ian Elz; Elwell, John; Christer Holmberg; SIPCORE;
Hadriel Kaplan
Subject: RE: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

On Wed, August 19, 2009 10:54 pm, Francois Audet wrote:
> Instead, it uses anonymizing (like RFC 3323). The parameters should 
> therefore not be removed.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Aug 2009 11:48:49 -0500

They may or may not.

In this particular case, they should be useful because of the semantics of
UUI (i.e., not associated with URI in any way shape or form).

However, since SIP introduces things like forking and lots of redirection
for routing, the parameters may not be understandable by the far end. IMHO,
UUI has a very narrow window of usefulness, i.e., for retrofitting legacy 
applications in very controlled environsment. When normal SIP forking and 
routing applies, with "normal" SIP endpoints, it won't work. The beauty
of all the possible mechanisms considered for UUI is that while there will be
more and more cases where "it won't work" (i.e., the UUI will not be useful), none
of them break anything (at least in theory). In the case of using URI parameters
(we shouldn't call it RFC 4244bis since that's not what it is: it's really 
using URI parameters), the parameters are ingnored. 

> Sent: Wednesday, August 19, 2009 21:50
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; Ian Elz; Elwell, John; Christer Holmberg; 
> SIPCORE; Hadriel Kaplan
> Subject: RE: [sipcore] RFC 4244 bis use cases and UAC->UAS 
> parameter delivery
>