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

From: Dean Willis <[email-masked]>
Date: Fri, 31 Jul 2009 04:08:37 -0500

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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 31 Jul 2009 04:21:59 -0500

Dean,

Our chartered delivereable is to deliver the whole
URI (including the parameters):

Verbatim:
Delivering request-URI and parameters to UAS via proxy to IESG (PS) 

And yes, that is one of the 2 main use cases for rfc4244bis.
(the other one being fixing broken things in RFC 4244).

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Friday, July 31, 2009 02:09
> 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
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 31 Jul 2009 05:23:27 -0400

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

-hadriel

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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 31 Jul 2009 05:44:07 -0500 (CDT)

> (the other one being fixing broken things in RFC 4244).

Just handing the raw data in an obfuscated way to the UAS is not enough.

We need to deliver the URI and parameters to the UAS in such a fashion
that the application running on the UAS can actually use them.

You keep saying "History-Info does this", but when we TRY to use
History-Info in this manner, people say "Well, these parameters don't feel
like History, they feel like something else, so I need to use some
easier-to-parse mechanism". They're not using History-Info for parameter
delivery.

Show a successful use case for parameter delivery using History-Info, or
stop claiming it solves the problem.
ing with respect to the request URI.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 31 Jul 2009 10:45:50 -0000 (UTC)

On Fri, July 31, 2009 9:23 am, 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.

and which parameters are the right ones? They're not necessarily the ones
on the first request-URI, either!

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 31 Jul 2009 05:59:44 -0500

Parameters without the URI itself are completely useless.
I know you would like to change that so that parameters 
stand on their own outside of the URI, but that's not
how SIP works, and we can't change it. It's engrained
in SIP.

So basically, you need to know WHICH URI you are looking for.

Depending on which Target-URI problem you are trying to solve,
it could be typically either the first or the last retarget.

In our current draft, that would mean either the first 
entry with aor flag, or the last one.

So it does work. I don't know why you claim it's difficult.

If we remove the aor flag, then the logic will have to be 
different. Probably something like "first or last entry
without a fluff flag".

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Friday, July 31, 2009 03:44
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; SIPCORE
> Subject: RE: [sipcore] RFC 4244 bis use cases and UAC->UAS 
> parameter delivery
> 
> > Our chartered delivereable is to deliver the whole URI 
> (including the 
> > parameters):
> >
> > Verbatim:
> We need to deliver the URI and parameters to the UAS in such 
> a fashion that the application running on the UAS can 
> actually use them.
> 
> You keep saying "History-Info does this", but when we TRY to 
> use History-Info in this manner, people say "Well, these 
> parameters don't feel like History, they feel like something 
> else, so I need to use some easier-to-parse mechanism". 
> They're not using History-Info for parameter delivery.
> 
> Show a successful use case for parameter delivery using 
> History-Info, or stop claiming it solves the problem.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Jul 2009 08:42:45 -0400

> 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