Subject: [dispatch] Proposed Charter for CCUS - Call Control UUI for SIP

From: Alan Johnston <[email-masked]>
Date: Wed, 22 Jul 2009 11:39:41 -0500

For discussion during DISPATCH next week.  Comments most welcome.

Thanks,
Alan

- - - - - -

The Call Control UUI for SIP  (CCUS) working group is chartered to 
define a SIP mechanism for transporting call control related 
user-to-user (UUI) information between User Agents.

The ISDN User to User Information Service, defined by ITU-T Q.931, is 
extensively deployed in the PSTN today, supporting such applications as 
contact centers, call centers, and automatic call distributors (ACDs).  
A major barrier to the movement of these applications to SIP is the lack 
of a standard mechanism to transport this information in SIP.

Call control UUI is user information conveyed between user agents during 
call control operations.  As a result, the information must be conveyed 
with the INVITE transaction, and must survive proxy retargeting, 
redirection, and transfers.  The mechanism must utilize a minimum of SIP 
extensions as it will need to be supported by many simple SIP user 
agents such as PSTN gateways.  The mechanism must interwork with the 
existing ISDN service but should also be extensible for use by other 
applications and non-ISDN protocols.

While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI 
can be generated by a number of protocols that are not ISUP, and as such 
it is architecturally unreasonable to interwork these protocols at the 
SIP / ISUP gateway. That is, existing SIP-T approaches defined in 
RFC3372 do not meet the requirements.

Mechanisms based on the SIP INFO method, RFC2976, will not be considered 
by the working group since the UUI contents carry information that must 
be conveyed during session setup at the user agent - the information 
must be conveyed with the INVITE transaction.  The information must be 
passed with the session setup request (INVITE), responses to that 
INVITE, or session termination requests.  As a result, it is not 
possible to use INFO in these cases.

The group will produce:

- A problem statement and requirements document for implementing a SIP 
call control UUI mechanism

- A specification of the SIP extension to best meet those requirements.

Goals and Milestones
====================

Dec 09 - Problem statement and requirements document to IESG 
(Informational)
Mar 10 - SIP call control UUI specification to IESG (PS)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Jul 2009 07:53:23 +0100

Alan,

What is meant exactly by "must survive ... transfers". Surviving
retargeting and redirection I am comfortable with, but transfers?

Would it be worth enumerating the particular ISDN services that it is
intended to work with? I believe it is just UUI1.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan Johnston
> Sent: 22 July 2009 17:40
> To: [email-masked]
> Subject: [dispatch] Proposed Charter for CCUS - Call Control 
> UUI for SIP
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 23 Jul 2009 07:55:37 -0500

John,

Thanks for your comments.  Transfers means the ability to pass UUI in a 
Refer-To URI in a REFER.  This requirement and the use cases are in:

     http://tools.ietf.org/html/draft-johnston-dispatch-sip-cc-uui

which is the same set of requirements and use cases we discussed in 
SIPPING in the past.  I'm not trying to add or change these 
requirements, just summarize them at a high level in the charter text.

And yes, we should say that this is ISDN UUS Service 1.

Thanks,
Alan

---

From: Dean Willis <[email-masked]>
Date: Sat, 25 Jul 2009 03:58:07 -0500

Alan Johnston wrote:
> Refer-To URI in a REFER. 

So, IF we had a way to pass user-to-user parameters in a request URI,
then we would not need a specialized mechanism for UUI.

We have an effort underway to learn how to pass parameters, but people
keep getting confused about why we need it.

So here's a question: Can we solve the UUI case using History Info? If
so, then we're basically done; we just need to register a standard
parameter for UUI. If not, then I argue that History-Info is not an
adequate method for parameter preservation end-to-end, and we need to
revisit that solution.

In absolutely no case should we be developing yet another
application-specific SIP extension header for CC-UUI. The application is
NOT part of the signaling.

--
Dean

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 25 Jul 2009 11:37:43 +0200

At the higher level I think the semantics of this line of reasoning are broken.

Surely, the overall requirement is that in certain forms of transfer, the UUI that went to the original called user should be delivered to the transferred user. Like a number of headers, this is information that the calling user put in the package because he wanted them delivered to the final destination.

That has nothing to do with recording the Request-URI of the calling user, which is what I believe the semantics of the History-Info relate to. That is because it has nothing to do with the Request-URI in the first place. Surely we place URI parameters in the Request-URI because they are something to do with the URI therein contained.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Saturday, July 25, 2009 9:58 AM
> To: Alan Johnston
> Cc: [email-masked]
> Subject: [dispatch] CCUS and History-Info (was Proposed 
> Charter for CCUS - Call Control UUI for SIP)
> 
> Alan Johnston wrote:
> > John,
> > 
> > Thanks for your comments.  Transfers means the ability to 
> pass UUI in 
> > a Refer-To URI in a REFER.
> 
> So, IF we had a way to pass user-to-user parameters in a 
> request URI, then we would not need a specialized mechanism for UUI.
> 
> We have an effort underway to learn how to pass parameters, 
> but people keep getting confused about why we need it.
> 
> So here's a question: Can we solve the UUI case using History 
> Info? If so, then we're basically done; we just need to 
> register a standard parameter for UUI. If not, then I argue 
> that History-Info is not an adequate method for parameter 
> preservation end-to-end, and we need to revisit that solution.
> 
> application-specific SIP extension header for CC-UUI. The 
> application is NOT part of the signaling.
> 
> --
> Dean
>

---

From: Alan Johnston <[email-masked]>
Date: Sat, 25 Jul 2009 09:45:24 -0500

Dean,

Thanks for your comments.

We did consider URI parameters as a mechanism.  If we used this 
approach, we would still need SIP extensions for those URI parameters 
and a new SIP option tag to indicate support for it.  As such, we'd 
still need a mechanism to be standardized.  I think in DISPATCH we are 
supposed to be discussing scope and charter text, and I think the 
current charter text is mechanism agnostic, so this approach would still 
be covered, correct?

In terms of History-Info, I don't think we've considered that before.  
There were two problems with the URI parameters.  One was the 
retargeting problem but the other is semantics.  Last time I read RFC 
3261, the Request-URI contained information about the destination 
resource, and sometimes information about the next hop to that 
resource.  To put user-to-user data about the originator in the request 
into the Request-URI seems like a big change to SIP semantics that we'd 
need to think carefully about before diving into.  We would definitely 
need a SIP option tag to say that we are reversing the meaning of 
Request-URI.

As for History-Info, it doesn't feel very right - how is UUI history 
about the call?  If anything, it is future information about the call.  
Also, wouldn't every proxy that might retarget in the path have to 
support it, or the UUI would be lost?  If so, we'd need to use 
Proxy-Require: history which is both ugly and not permitted by RFC 4244.

Anyway, I look forward to more mechanism discussions in the future, but 
for now lets focus on the charter discussions.

Thanks,
Alan

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 25 Jul 2009 16:27:42 -0400

I think the retargeting and middlebox support issues are not really germane as it pertains to H-I.  H-I records the req-uri's even through retargeting, so the UUI would be available to the UAS.  And it would survive even if Proxies don't support H-I, because the first UAC can insert the first H-I of the req-uri, which would simply be mandated for UUI-supporting UAC's if we went that way. 

But the real problem is the semantics as you say - to me a request URI is information about the targeted resource or how to reach it, not information about the source resource.  Since H-I is just a list of req-uri's, it's not the right place.

Really the technically *right* place would be in MIME, afaict - it's opaque application data just like geoloc, right?  But pragmatically, the issues/problems with doing it in MIME were already covered and debated in sipping, and iirc consensus was: put it in a header.

ISTM that we always complain about lack of running code, and here we have a case where there is running code from multiple vendors, and it's not fundamentally broken/un-sound.  It ain't broken, why do we need to fix it?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alan Johnston
> Sent: Saturday, July 25, 2009 10:45 AM
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Jul 2009 02:12:46 -0500

I agree with both Alan and Hadriel. 

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Saturday, July 25, 2009 13:28
> To: Alan Johnston; Dean Willis
> Cc: [email-masked]
> Subject: Re: [dispatch] CCUS and History-Info (was Proposed 
> I think the retargeting and middlebox support issues are not 
> really germane as it pertains to H-I.  H-I records the 
> req-uri's even through retargeting, so the UUI would be 
> available to the UAS.  And it would survive even if Proxies 
> don't support H-I, because the first UAC can insert the first 
> H-I of the req-uri, which would simply be mandated for 
> UUI-supporting UAC's if we went that way. 
> 
> But the real problem is the semantics as you say - to me a 
> request URI is information about the targeted resource or how 
> to reach it, not information about the source resource.  
> Since H-I is just a list of req-uri's, it's not the right place.
> 
> Really the technically *right* place would be in MIME, afaict 
> - it's opaque application data just like geoloc, right?  But 
> pragmatically, the issues/problems with doing it in MIME were 
> already covered and debated in sipping, and iirc consensus 
> was: put it in a header.
> 
> ISTM that we always complain about lack of running code, and 
> here we have a case where there is running code from multiple 
> vendors, and it's not fundamentally broken/un-sound.  It 
> ain't broken, why do we need to fix it?
> 
> -hadriel
> 
> > resource.  To put user-to-user data about the originator in the 
> > request into the Request-URI seems like a big change to SIP 
> semantics 
> > that we'd need to think carefully about before diving into. 
>  We would 
> > definitely need a SIP option tag to say that we are reversing the 
> > meaning of Request-URI.
> > 
> > Anyway, I look forward to more mechanism discussions in the future, 
> > but for now lets focus on the charter discussions.

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Jul 2009 03:42:24 -0500

> current charter text is mechanism agnostic, so this approach would still

Part of what DISPATCH has to do is decide whether the problem requires
substantive new specification to perform, and if so, to shape the
charter of that work.

My belief is that if SIP provides a mechanism for user-to-user parameter
passing as an inherent mechanism, then call-control UUI should use that
mechanism. This means that there is no need for a SIP-extending working
group to be formed to complete that work. Instead, it would be
appropriate to document the parameter names and values using an
individual draft.

So I think my comments are very appropriate to the charter discussion in
 DISPATCH. I'm saying that we do NOT need to charter a working group for
this work as I understand it. More strongly said, since History-Info is
our currently agreed mechanism for meeting the SIPCORE charter
deliverable of UAC to UAS parameter passing, and since ISDN call control
proposes a new method of UAC to UAS parameter passing, then THIS
PROPSOED WORK IS IN DIRECT CONFLICT WITH CHARTERED WORK IN SIPCORE.

Now, it is arguable that we don't really have an effective mechanism for
parameter passing using History-Info. If so, then the charter we should
be talking about is for a generic UAC to UAS parameter passing
mechanism, which call-control UUI could then utilize. This work could be
done in SIPCORE (in fact, I believe that's the place for it, as we're
talking about a very central and universal aspect of SIP), or in a new
working group. That conversation we can certainly have in DISPATCH.

> need a SIP option tag to say that we are reversing the meaning of

...

> Proxy-Require: history which is both ugly and not permitted by RFC 4244.

We currently have SIPCORE working group consensus on History-Info being
the mechanism for delivery of user-supplied data from UAC to UAS, that
having been the goal of the original UA Loose route work.

This is not a "reversal of request-URI semantics"; rather it is the
original intent of the SIP Request URI, which is modeled on the HTTP
request URI. The HTTP request URI is HTTP's normal mechanism for the
delivery of application data from UAC to UAS. HTTP server applications
don't have ready access to new HTTP headers (one would have to rewrite
Apache for every such protocol extension), but they do have easy access
to the request URI.

There's nothing special about ISDN call control data in its interaction
with SIP. It does NOT interact with the SIP state machine in any way.
Extending SIP explicitly to support it is a serious violation of
protocol layering. Admittedly, SIP is full of such cross-layer issues,
but why do we insist on adding more?

Call Control UUI is a "poster child", or in other words a perfect use
case, for UAC to UAS parameter passing. If our UAC to UAS
parameter-passing mechanism doesn't work for it, then we need to back up
and take another look at the parameter-passing mechanism rather than
continue to extend SIP with application-specific usages that should be
outside of its scope.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Jul 2009 03:48:41 -0500

Hadriel Kaplan wrote:

> I think the retargeting and middlebox support issues are not really
> But the real problem is the semantics as you say - to me a request
> URI is information about the targeted resource or how to reach it,
> not information about the source resource.  Since H-I is just a list
> of req-uri's, it's not the right place.

I disagree. SIP is based on HTTP The Request URI encodes the request
being made by the UAC to the UAS. The CCUUI data is not germane to SIP,
it's just stuff being passed along the chain from UAC to UAS.

Now, it might be reasonable to universally declare that SIP is, in fact,
NOT HTTP, and that it uses a different parameter passing mechanism. If
so, then what we would probably want to do is define a new header field,
perhaps "User-Parameters:", that is reserved for user-to-user data
consumed by applications. I'd be okay with that.

> Really the technically *right* place would be in MIME, afaict - it's
> opaque application data just like geoloc, right?  But pragmatically,
> the issues/problems with doing it in MIME were already covered and
> debated in sipping, and iirc consensus was: put it in a header.
> 
> ISTM that we always complain about lack of running code, and here we
> have a case where there is running code from multiple vendors, and
> it's not fundamentally broken/un-sound.  It ain't broken, why do we
> need to fix it?

The same reason we shoud object to all layer-violation hacks:
because it is architecturally unsound, inconsistent with the current SIP
design approach, and leads to further unnecessary complexity in an
already too-complex protocol.

--
Dean

---

From: Alan Johnston <[email-masked]>
Date: Mon, 27 Jul 2009 11:02:26 +0200

Dean,

So basically, you want a different name for the header field?   
Otherwise the semantics seem identical to what is proposed.

Thanks,
Alan

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 27 Jul 2009 05:34:30 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, July 27, 2009 4:49 AM
> To: Hadriel Kaplan
> 
> being made by the UAC to the UAS. 

Then you might as well argue the request-URI should encode MIME bodies.  The UUI is not a part of the resource being addressed in any way, and thus not a part of a Uniform Resource Identifier.

> NOT HTTP, and that it uses a different parameter passing mechanism. 

Well, I'll probably be flamed, but afaict it is not HTTP in most every important way.  It does a LOT of things differently.  That ship has sailed.  It is far closer to email (with some weird combo of SMTP and POP3), if anything. 

> If

That was actually how I interpreted the semantic notion of the User-to-User header.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jul 2009 09:33:17 -0400

Alan Johnston wrote:
> Dean,
> 
> So basically, you want a different name for the header field?  Otherwise 
> the semantics seem identical to what is proposed.

There at least needs to be some interoperable way to specify the format 
of the data being passed. We have that with MIME, but when using a 
header the mechanism needs to be reinvented, along with a way to say "I 
don't understand that".

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Mon, 27 Jul 2009 09:43:16 -0500

Paul Kyzivat wrote:
> There at least needs to be some interoperable way to specify the 
> format of the data being passed. We have that with MIME, but when 
> using a header the mechanism needs to be reinvented, along with a way 
> to say "I don't understand that".
This is an excellent point.

The latest version of the mechanism draft has a way of specifying the 
purpose (application) and encoding, based on this need.

The requirements currently say that a UAC has to be able to discover if 
a UAS supports the UUI  *mechanism*.   The obvious way to do this is a 
SIP option tag.  But do we need a requirement for a UAC to discover if a 
UAS supports a particular purpose/application?  If the same UUI is 
encoded in different ways, do we need a way to say "you need to be able 
to support *one* of the data objects?

Thanks,
Alan

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 27 Jul 2009 17:07:17 +0200

And just to note that this needs to map into the equivalent ISDN features.

These are implicit, where I am saying: "if the place where this is delivered to cannot understand it, then throw it away",

and explicit, where I am saying: "if the place where this is delivered cannot understand it, then fail the call".

It doesn't need anything else, and there is no discovery mechanism in the ISDN (apart from by making calls containing UUI explicit and seeing what fails).

regards

Keith

> Sent: Monday, July 27, 2009 3:43 PM
> To: Paul Kyzivat
> Cc: [email-masked]; Hadriel Kaplan
> The latest version of the mechanism draft has a way of 
> specifying the purpose (application) and encoding, based on this need.
> 
> SIP option tag.  But do we need a requirement for a UAC to 
> discover if a UAS supports a particular purpose/application?  
> If the same UUI is encoded in different ways, do we need a 
> way to say "you need to be able to support *one* of the data objects?
> 
> Thanks,
> Alan
> 
> 
> >
> >     Thanks,
> >     Paul
> >
> >> Thanks,
> >> Alan
> >>
> >>
> >>
> >>>> not information about the source resource.  Since H-I is just a 
> >>>> list of req-uri's, it's not the right place.
> >>>
> >>> being made by the UAC to the UAS. The CCUUI data is not 
> germane to 
> >>> SIP, it's just stuff being passed along the chain from UAC to UAS.
> >>>
> >>> Now, it might be reasonable to universally declare that 
> SIP is, in 
> >>> fact, NOT HTTP, and that it uses a different parameter passing 
> >>> mechanism. If so, then what we would probably want to do 
> is define a 
> >>> new header field, perhaps "User-Parameters:", that is 
> reserved for 
> >>> user-to-user data consumed by applications. I'd be okay with that.
> >>>
> >>>
> >>>> Really the technically *right* place would be in MIME, afaict - 
> >>>> it's opaque application data just like geoloc, right?  But 
> >>>> already covered and debated in sipping, and iirc 
> consensus was: put it in a header.
> >>>>
> >>>> ISTM that we always complain about lack of running code, 
> and here 
> >>>> we have a case where there is running code from multiple 
> vendors, 
> >>>> and it's not fundamentally broken/un-sound.  It ain't 
> broken, why 
> >>>> do we need to fix it?
> >>>
> >>> because it is architecturally unsound, inconsistent with 
> the current 
> >>> SIP design approach, and leads to further unnecessary 
> complexity in 
> >>> an already too-complex protocol.
> >>>
> >>>
> >>> --
> >>> Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Jul 2009 17:24:33 -0500

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: Dean Willis
>> [mailto:[email-masked]] Sent: Monday, July 27, 2009 4:49
>> AM To: Hadriel Kaplan
>> 
>> I disagree. SIP is based on HTTP The Request URI encodes the
>> request being made by the UAC to the UAS.
> 
> Then you might as well argue the request-URI should encode MIME
> bodies.  The UUI is not a part of the resource being addressed in any
> way, and thus not a part of a Uniform Resource Identifier.

I take it you've never written an HTTP application using something like
the Common Gateway Interface (CGI) for parameter passing. Perhaps taking
some time to learn the history here would be helpful for you, so that
you stop making patently incorrect assertions about what can be in a
request URI.

Let's look at the request-URI used by the IETF tools team's draft search
page.

Take, for example: http://tools.ietf.org/id/?doc=common

Everything up to the first / is network routing information -- it finds
the host responsible for the application.

The /id/ part identifies the application. That might arguably be
"application routing", but it is not NETWORK routing. It doesn't create
Via header fields in the SIP request.

The "?doc=common" part is parameters being delivered to the "id"
application. The question mark is the common CGI delimiter for
parameters. This delimits a parameter having the name "doc" and taking
the value "common", thereby telling the id application to search for all
docs having the string "common" in their name.

Note that, in your parelance, "id" and "common" are NOT part of the
resource being addressed in any way. Yet, they are encoded into the
resource, in such a way that they can easily be presented in writing,
pasted onto a business card, or whatever else you might want to do with
a URI.

Nowhere in the HTTP spec (nor in the HTTCP CGI spec at
http://hoohoo.ncsa.illinois.edu/cgi/interface.html) is "doc" or "common"
defined. Rather, the specification defines a syntax for parameter names
and parameter values, and leaves the actual choice of parameter names
and encoding of values up to the application. This has allowed many
millions of HTTP applications to be developed without having to amend
the HTTP specification for each one of them.

Back when we were working on the SIP that eventually became RFC 2543, we
intended SIP to support a CGI-type invocation model. We just didn't do
it right, for a number of reasons mostly having to do with failed
communication between the people driving the spec.

> 
> 
>> Now, it might be reasonable to universally declare that SIP is, in
>> mechanism.
> Well, I'll probably be flamed, but afaict it is not HTTP in most
> every important way.  It does a LOT of things differently.  That ship
> has sailed.  It is far closer to email (with some weird combo of SMTP
> and POP3), if anything.

Possibly true. But we need SOME equivalent of HTTP's parameter passing
model, else we are stuck with having to extend SIP again and again for
every possible application, and that's just a ridiculous idea.

> 
> 
>> If so, then what we would probably want to do is define a new
>> header field, perhaps "User-Parameters:", that is reserved for

That is, I think, the intent in Alan's current draft. He's not at all
far off from what I think would be a reasonable solution. There's some
guidance needed on semantic negotiation and how to say "I don't
understand the parameters you have sent me", but it should be pretty
straightforward to remedy.

I find this approach much more attractive for user-to-user parameter
passing than the idea that we encode the parameters HTTP-style in the
request URI, then have the UAS wade backwards thru the History-Info
stack until it finds them.

But our current consensus is to do just exactly that: so I'm using
CC-UUI to challenge that consensus. Either we can use request-URI
parameters and History-Info for parameter passing (in which case we
should do CC-UUI that way), or we develop the more robust mechanism that
SIP has long needed (and that Alan has a good start on). I'm in favor of
the latter, but will accept either.

What I won't accept is yet another application-specific SIP extension
header that works for CC-UUI but doesn't solve the general problem,
coupled with a head-in-sand insistence that we've solved the general
problem using History-Info, despite having proved (by the need to
develop yet another special extension for CC-UUI) that we in fact have
NOT solved the general UAC-to-UAS parameter passing problem.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Jul 2009 17:30:38 -0500

> to support *one* of the data objects?

We certainly need a way to say "I understand the parameter you have sent
me, but the value you gave it doesn't make any sense".

It might also be ok to have a criticality indicator on a parameter, and
I can envision a subset-selection indication that wouldn't be too hairy,
but I'm having a hard time coming up witha real use case.

It would be a lot easier to write the applications to have positive
resopnse: that is, if the UAS understands the parameter in question and
the value makes sense, it says so affirmatively in the response.
Further, it might indicate which of several alternatives it preferred.
This provides a fail-safe, backward-compatible mechanism that gives
debugging feedback, but at much less complexity cost.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Jul 2009 11:41:49 -0400

> Sent: Monday, July 27, 2009 6:25 PM
> 
> Hadriel Kaplan wrote:
> >

Au contraire, mon ami.
I was not talking about the history of HTTP, nor do I care. (and to be fair, the "history" of HTTP goes back before the term URI was ever invented, if I recall).

I am talking about the request URI in SIP.  And I'm not talking about what can/cannot be there - you can put whatever you want in it - I'm talking about what we should semantically expect/prescribe to be there from a standards usage perspective.

> [snip]
> resource being addressed in any way. 

I disagree.  They are absolutely part of the resource being addressed.  They are not a filename/directory/route identifier, but that doesn't matter.

> Yet, they are encoded into the

And that's exactly it!  I cannot go around adding "/id/?doc=common" to the end of every HTTP URI/URL and expect anything to work.  Why?  Because it only has meaning to tools.ietf.org, the *target* of the HTTP request.  UUI is different.  I can go add the same UUI value to every request I send regardless of the target, because it's a property of, or based on, the *sender*. (well, mostly... it's proprietary of course, so who the heck knows what's in there)

And while *anyone* can go add "/id/?doc=common" to the tools.ietf.org URI, if it were on a business card, for example - the same is not true of a UUI's value.  You could not put the UUI's hex value as a param into a business card and have anyone/everyone use it to you and expect it to work right. (again, generally speaking, ignoring the fact it's a proprietary blob) 

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Jul 2009 18:49:28 -0500

Hadriel Kaplan wrote:

> And that's exactly it!  I cannot go around adding "/id/?doc=common"
> to the end of every HTTP URI/URL and expect anything to work.  Why?
> Because it only has meaning to tools.ietf.org, the *target* of the
> HTTP request.  UUI is different.  I can go add the same UUI value to
> every request I send regardless of the target, because it's a
> property of, or based on, the *sender*. (well, mostly... it's
> proprietary of course, so who the heck knows what's in there)

Horsefeathers. It has nothing to do with the sender (UAC). Understanding
the data is all up to the receiver (UAS). If UUI data were printed on a
business card and entered on my Nokia phone (which I assure you, doesn't
understand UUI)  it would still be delivered to the receiver. If the
receiver understands it, it can act on it with complete independence
from any property of the sender.

> And while *anyone* can go add "/id/?doc=common" to the tools.ietf.org
> URI, if it were on a business card, for example - the same is not
> true of a UUI's value.  You could not put the UUI's hex value as a
> param into a business card and have anyone/everyone use it to you and
> expect it to work right. (again, generally speaking, ignoring the
> fact it's a proprietary blob)

That sort of depends on the UUI application, doesn't it?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 21:14:16 -0400

Hadriel,

I don't understand what you are trying to say at all.

I *think* your are saying that UUI is like my scribbling any random 
garbage, in any notation I want, onto my business card and handing it to 
somebody, in expectation that they will be able to do something useful 
with it.

I indeed *might* be able to do that, if I know precisely who I am 
handing the card to, and what sorts of things they understand, and the 
notations they will be able to process. But of course in this case I 
have to put this info into the INVITE before I know who I will end up 
talking to.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Jul 2009 01:10:29 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 9:14 PM
> To: Dean Willis
> 
> Hadriel,

Nope, I said *if* we were to put it into the request-URI, then that's what it would be like.  I don't want to put it into the request-URI, because I think the req-URI is the wrong semantic.  Dean's saying we should put it in the req-uri, because HTTP would. 

> have to put this info into the INVITE before I know who I will end up

Yup.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Jul 2009 01:34:57 -0400

> Sent: Tuesday, July 28, 2009 7:49 PM
> To: Hadriel Kaplan
> 

Poppycock.  What's *in* the UUI can change based on who's sending it, even if it's accessing the same target resource.  The fact that the receiving UAS' application above SIP has to understand it to use it, doesn't mean a heck of a lot.  There's are plenty of existing SIP headers that I could enter into your Nokia phone (were it to let me) that its SIP stack needs to know nothing about to send the INVITE, that only the receiver has to understand.  Although I guess your point is that we were wrong to do that before, so we should stop doing it. (right?)

> That sort of depends on the UUI application, doesn't it?

Unfortunately yes. It's an opaque blob. It can have anything in it.  

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Jul 2009 08:05:06 -0500

Hadriel Kaplan wrote:
> 
> Poppycock.  What's *in* the UUI can change based on who's sending it,
> even if it's accessing the same target resource.  The fact that the
> receiving UAS' application above SIP has to understand it to use it,
> doesn't mean a heck of a lot.  There's are plenty of existing SIP
> headers that I could enter into your Nokia phone (were it to let me)
> that its SIP stack needs to know nothing about to send the INVITE,
> that only the receiver has to understand.  Although I guess your
> point is that we were wrong to do that before, so we should stop
> doing it. (right?)
> 

Right. We totally molested the poodle by putting so much
application-specific cruft into SIP extension header fields. HTTP has
been able to support new applications without having to make a protocol
extension for every new application because it does NOT put application
data into HTTP extensions. Rather, it uses HTTP as a transport for the
application data, which is what SIP should have done and what we really
meant to do back when starting SIP.

HTTP has two places to transport application-specific stuff: in the
request URI, and in payloads. Application parameters are generally sent
using the request URI.

We have two alternatives to choose from:

1) Fix SIP so that we can use HTTP-style request URI parameterization.
Currently, SIPCORE has consensus to do exactly this, using history-info.

2) Give up on using HTTP-style request-URI parameterization and develop
an alternative. Adding application-specific SIP extensions for every
different application is not a reasonable alternative. Dedicating a
specific new extension field for all user-to-user parameters might be,
and that's essentially what Alan has proposed.

Pick one and use it.

--
Dean

> 
>>> And while *anyone* can go add "/id/?doc=common" to the
>>> tools.ietf.org URI, if it were on a business card, for example -
>>> the same is not true of a UUI's value.  You could not put the
>>> UUI's hex value as a param into a business card and have
>>> anyone/everyone use it to you and expect it to work right.
>>> (again, generally speaking, ignoring the fact it's a proprietary
>>> blob)
>>