Subject: [Sipping] question on draft-johnston-sipping-cc-uui

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 17:01:39 -0400

This draft proposes to standardize a header field for carrying 
information between an ACD and a call handler in a call center.

What I dont understand is, unless you are also going to standardize the 
content of the header field, why is there is a need to standardize on a 
header vs. mime body? In other words, without standardization of the 
format of the data, the ACD and call taker applications need to be from 
the same vendor anyway.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Wed, 13 Sep 2006 17:17:26 -0500

Jonathan,

Thanks for the comments on the draft.

Today, these components are rarely from the same vendor.  What is 
required is coordination between the devices on what information is 
passed in the UUI.  For example, is it a telephone number, account 
number, or other string.  There is already a large amount of 
coordination and configuration among the system components, so this is a 
small detail.  However, having both devices utilize the same SIP header 
field is an important interoperability issue.  Not having this 
standardized is a serious impediment to building SIP enabled call 
centers.  I think SIP is an ideal fit for this space if we do a little work.

However, it might make sense to also attempt to standardize the content 
of the header field.  I'm still learning about this complex application 
and about the types of UUI information exchanged.  It would be great to 
hear from others who are experienced in this space about whether 
standardizing the format also makes sense.

Thanks,
Alan

Jonathan Rosenberg wrote:
> What I dont understand is, unless you are also going to standardize 
> the content of the header field, why is there is a need to standardize 
> on a header vs. mime body? In other words, without standardization of 
> the format of the data, the ACD and call taker applications need to be 
> from the same vendor anyway.
>
> -Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Wed, 13 Sep 2006 20:33:31 -0500

> standardizing the format also makes sense.

My instincts here are with Jonathan, in that I think that if we 
standardize the format, we must either standardize the content or 
provide a straightforward process for that standardization.

So we're left with two choices here, as I see it. Either:

1) This draft defines a set of constraints on and process for 
standardizing related header field values, with the actual determination 
of those values left to future work. The clear expectation of that 
future work and a statement that the header field alone is meaningless 
and does not contribute adequately to interoperable standards in the 
absence of standard values is needed.

or

2) As in #1, except that this document would also define any "glaringly 
obvious" header field values known to current practitioners.

of course, a 3rd choice is to simply defer the specification until 
somebody comes forward with a reasonable set of starter values.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Sep 2006 10:07:39 -0400

Hi Alan,

It would be helpful if this draft defined what is meant by User to User 
Information.

I infer from the examples that it is information gathered by the ACD, or 
perhaps info the ACD derives based on what it can gather during its 
early dialog, that it wants to convey to the Terminator. So in this case 
the first user is the ACD and the 2nd user is the Terminator.

The use of header parameters in the Contact or Refer-To, while it might 
work in theory, seems questionable in practice. The passing of such 
parameters is optional, and likely not to be honored in many cases. At 
least that isn't needed when the ACD acts as a proxy.

I would think another issue about the cases where the information is 
relayed via the Originator is that it then gives the originator an 
opportunity to examine and modify it - which may not be desirable.

The syntax of the proposed header seems pretty restrictive. I'd be 
inclined to at least include standard comma syntax so that the header 
can be repeated to allow multiple tokens. And since there really isn't 
any way to negotiate between the sender and the recipient, it might be 
useful to have a way to denote the namespace of the value so that there 
isn't a question about how they it is interpreted. For this application 
I would expect that unambiguous namespace identifiers should be easily 
minted by those deploying the system. Perhaps URNs would fill the bill 
for that.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Sep 2006 13:16:33 -0400

I don't know if it is feasible to standardize all the info that might 
want to be conveyed in this way. Its my impression that the specific 
data to be conveyed from the ACD vary according to the provisioning of 
the ACD, and are related to the specific downstream application that 
will consume the data. The people doing the provisioning won't be in any 
position, or desire to create standards about this. Maybe in one 
deployment there will be an SSN, in another an account number and a 
name, ...

In that case the source and destination are hopefully configured in a 
consistent way regarding what data is passed. And that is enough as long 
as nothing goes wrong, the request ends up where the source thought, and 
it is in fact at a consistent revision level, etc. But things do go 
wrong. Maybe the intended server is down and some forwarding rules take 
the request elsewhere, that has different conventions about what the 
data means.

This *could* be left to the applications in question. They could 
establish their own conventions for encoding the data so that the wrong 
data won't be accepted and misinterpreted.

But I think it would be a better idea to establish conventions for 
identifying the context of the data so accidents don't happen. E.g.

    User-to-User: banking.acme.com;acct="332-998544-4321";service="gold"

    User-to-User: cust-serv.irs.gov;ssn="333-88-5555";wait-time=27

(Just incidentally, once that is done, that data in the header could be 
used as a criterion for routing the request to a destination that will 
understand it.)

Dean Willis wrote:
>> coordination and configuration among the system components, so this is 
>> a small detail.  However, having both devices utilize the same SIP 
>> header field is an important interoperability issue.  Not having this 
>> However, it might make sense to also attempt to standardize the 
>> content of the header field.  I'm still learning about this complex 
>> application and about the types of UUI information exchanged.  It 
>> would be great to hear from others who are experienced in this space 
>> about whether standardizing the format also makes sense.
>>
>

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 14 Sep 2006 13:50:37 -0500

This would seem better fit in a MIME body, and being one already exists
(register years ago by Cisco), why don't we use it. In addition, it has
defined syntax for any/all narrowband information, including UUI.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 1:17 PM
To: Dean Willis
Cc: IETF Sipping List
Subject: Re: [Sipping] question on draft-johnston-sipping-cc-uui

>> centers.  I think SIP is an ideal fit for this space if we do a
little 
>> work.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 14 Sep 2006 14:36:31 -0500

Alan,

This draft seems somewhat bizarre to me as it tries to be ACD-specific
and
general at the same time.

At a high, it seems that the requirement is for a way to have 
redirection from one target to another, with the redirecting
entity being able to add "information" that needs to be 
provided to the retargeted-to entity.

The conclusion that it should be done using a new Header completely
baffles me. Especially since the proper way to do this is already
included in section 3.4, i.e., to use a URI parameter.

This is exactly what RFC 4240 (Netann) is for.

The real question in my mind is do we need to standardized the 
URI parameters themselves.

We already have some precedents for this. In fact, RFC 3087 and RFC 4458

describes SOME of the parameters that you would be likely to use in an
ACD application. And it goes at great length to explain the
"coordination" aspects that you are talking about.

I'd also like to understand what are the parameters that are
believed to be important.

So, while I think standardizing parameters for applications like 
ACD probably make sense for inter-vendor compatibility, I don't see
any reason to deviate from things like RFC 3087, RFC 4240 and RFC 4458.

> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Wednesday, September 13, 2006 3:17 PM
> To: Jonathan Rosenberg
> Cc: IETF Sipping List
> Today, these components are rarely from the same vendor.  
> What is required is coordination between the devices on what 
> information is passed in the UUI.  For example, is it a 
> telephone number, account number, or other string.  There is 
> already a large amount of coordination and configuration 
> among the system components, so this is a small detail.  
> However, having both devices utilize the same SIP header 
> field is an important interoperability issue.  Not having 
> this standardized is a serious impediment to building SIP 
> enabled call centers.  I think SIP is an ideal fit for this 
> space if we do a little work.
> 
> However, it might make sense to also attempt to standardize 
> the content of the header field.  I'm still learning about 
> this complex application and about the types of UUI 
> information exchanged.  It would be great to hear from others 
> who are experienced in this space about whether standardizing 
> the format also makes sense.
> 
> Thanks,
> Alan
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 14 Sep 2006 15:35:08 -0500

That was my first reaction, before I realized that the information is
really provided by the initial target instead of the originator. 

> From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 11:51 AM
> To: Paul Kyzivat; Dean Willis
> Cc: IETF Sipping List
> Subject: RE: [Sipping] question on draft-johnston-sipping-cc-uui
> 
> This would seem better fit in a MIME body, and being one 
> already exists (register years ago by Cisco), why don't we 
> use it. In addition, it has defined syntax for any/all 
> narrowband information, including UUI.
> 
> I don't know if it is feasible to standardize all the info 
> that might want to be conveyed in this way. Its my impression 
> that the specific data to be conveyed from the ACD vary 
> according to the provisioning of the ACD, and are related to 
> the specific downstream application that will consume the 
> data. The people doing the provisioning won't be in any
> 
> position, or desire to create standards about this. Maybe in 
> one deployment there will be an SSN, in another an account 
> number and a name, ...
> 
> In that case the source and destination are hopefully 
> configured in a consistent way regarding what data is passed. 
> And that is enough as long
> 
> it is in fact at a consistent revision level, etc. But things 
> do go wrong. Maybe the intended server is down and some 
> forwarding rules take the request elsewhere, that has 
> different conventions about what the data means.
> 
> This *could* be left to the applications in question. They 
> could establish their own conventions for encoding the data 
> so that the wrong data won't be accepted and misinterpreted.
> 
> But I think it would be a better idea to establish 
> conventions for identifying the context of the data so 
> accidents don't happen. E.g.
> 
>     User-to-User: 
> banking.acme.com;acct="332-998544-4321";service="gold"
> 
> (Just incidentally, once that is done, that data in the 
> header could be used as a criterion for routing the request 
> to a destination that will understand it.)
> 
> Dean Willis wrote:
> > Alan Johnston wrote:
> >> Jonathan,
> >>
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
>

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 14 Sep 2006 16:10:26 -0500

The MIME'd syntax would address this scenario, as will as provide the
capability for communicating other information using the same syntax,
all of which is defined.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 15 Sep 2006 12:15:47 -0500

Paul,

These are all good suggestions.  I agree that it would be good to mark 
the information.  Also, it might be useful to indicate who added the 
information.

And, the use of the information in the header field to route the call to 
a particular destination is exactly one of the most important usages.

Thanks,
Alan

Paul Kyzivat wrote:
> will consume the data. The people doing the provisioning won't be in 
> any position, or desire to create standards about this. Maybe in one 
> consistent way regarding what data is passed. And that is enough as 
> long as nothing goes wrong, the request ends up where the source 
> thought, and it is in fact at a consistent revision level, etc. But 
> things do go wrong. Maybe the intended server is down and some 
> forwarding rules take the request elsewhere, that has different 
> conventions about what the data means.
>
> establish their own conventions for encoding the data so that the 
> wrong data won't be accepted and misinterpreted.
>
> (Just incidentally, once that is done, that data in the header could 
> be used as a criterion for routing the request to a destination that 
> will understand it.)
>
> Dean Willis wrote:
>> Alan Johnston wrote:
>>> Jonathan,
>>>
>>> coordination and configuration among the system components, so this 
>>> is a small detail.  However, having both devices utilize the same 
>>> SIP header field is an important interoperability issue.  Not having 
>>> this standardized is a serious impediment to building SIP enabled 
>>> call centers.  I think SIP is an ideal fit for this space if we do a 
>>> little work.
>>>
>> standardizing related header field values, with the actual 
>> determination of those values left to future work. The clear 
>> expectation of that future work and a statement that the header field 
>> alone is meaningless and does not contribute adequately to 
>> interoperable standards in the absence of standard values is needed.
>>
>> or
>>
>> 2) As in #1, except that this document would also define any 
>> "glaringly obvious" header field values known to current practitioners.
>>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 15 Sep 2006 12:15:24 -0500

Paul,

Thanks,
Alan

Paul Kyzivat wrote:
> (Just incidentally, once that is done, that data in tRe:draft-johnston-sipping-cc-uui-00.txt
Cc: sipping <[email-masked]>

Paul,

I will add text to better describe the applications that could benefit 
from this mechanism.  It is true that not all UAs handle escaped header 
fields in URIs, although the use of this in common applications such as 
transfer is spreading.

I'll fix the syntax issues so the header can be repeated.

Thanks,
Alan

Paul Kyzivat wrote:
> Hi Alan,
>
> It would be helpful if this draft defined what is meant by User to 
> User Information.
>
> I infer from the examples that it is information gathered by the ACD, 
> or perhaps info the ACD derives based on what it can gather during its 
> early dialog, that it wants to convey to the Terminator. So in this 
> case the first user is the ACD and the 2nd user is the Terminator.
>
> The use of header parameters in the Contact or Refer-To, while it 
> might work in theory, seems questionable in practice. The passing of 
> such parameters is optional, and likely not to be honored in many 
> cases. At least that isn't needed when the ACD acts as a proxy.
>
> useful to have a way to denote the namespace of the value so that 
> there isn't a question about how they it is interpreted. For this 
> application I would expect that unambiguous namespace identifiers 
> should be easily minted by those deploying the system. Perhaps URNs 
> would fill the bill for that.
>
>     Paul
>

he header could

---

From: Alan Johnston <[email-masked]>
Date: Fri, 15 Sep 2006 12:15:24 -0500

Paul,

Thanks,
Alan

---

From: Alan Johnston <[email-masked]>
Date: Fri, 15 Sep 2006 12:24:34 -0500

Francois,

While the motivation and application of this header is call centers and 
ACDs, I am hopeful that we can define a more general mechanism usable 
for other applications.

You are correct in saying that there are some similarities to RFC 4240 
and that is why I described the URI parameter approach in the draft.

However, this URI approach does not survive retargeting.  For example, 
lets say I want to pass some UUI to you.  If I send it to 
sips:[email-masked];uui=stuff, your proxy will retarget to 
sips:[email-masked] based on your registration and the UUI is 
lost.  Of course, we could make this URI parameter like the grid 
parameter in GRUU, but that would mean using Proxy-Require to be sure it 
gets through.

I'd be happy to use a URI parameter approach as it is simpler than a 
separate header field, but it would need to overcome the retargeting 
problem without special support in proxies.

Thanks,
Alan

Francois Audet wrote:
>>> the content of the header field, why is there is a need to 
>>>       
>> standardize 
>>     
>>> on a header vs. mime body? In other words, without 
>>>       
>> standardization of 
>>     
>>> the format of the data, the ACD and call taker applications 
>>>       
>> need to be 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 13:40:13 -0400

Alan Johnston wrote:
> from this mechanism. 

Does that mean explaining what UUI means? Your existing examples all 
show the value being an opaque string. Is this because it is an 
encoding? If so, is it widely understood, or is that an agreement 
between source and destination?

Because there is only *one* string, I am left assuming that there might 
be several data elements hiding inside the encoding. If that is the 
intended usage it would be helpful for that to be clear. Maybe an 
example could show the real data, an then how that data is conveyed in 
encoded form. Unless there is a good reason for encoding then it might 
be better to pass multiple parameters that are not encoded.

> It is true that not all UAs handle escaped header 

I'm also curious about the security issues of passing the data via the 
UAC. Could you address that in some way? Maybe there is no concern, and 
it is ok for the UAC to read and update the values. Or maybe the 
assumption is that the data is encrypted so that the UAC cannot 
understand or change it, and that the recipient will be able to know if 
it has been removed entirely. But whatever it is, would be helpful to 
have explanation.

	Thx,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 15 Sep 2006 12:40:47 -0500

Yeah, let's think about this some more.

I'd like to have a better understand of the information you want to
convey
itself. Seems useful to me.

I'd really like to find a way not to re-invent the wheel. Seems we have
a lot
of URI-parameter based work that is perfect for this (provided we find a

solution to the retargeting problem).

If I understand correctly, the ultimate enpoints in the scenario you are
looking
at are not in the same domain as the ACD, and therefore, you are
intending to
use AORs instead of a contact, and worried that the URI parameters won't
be
preserved.

> Sent: Friday, September 15, 2006 10:25 AM
> To: Audet, Francois (SC100:3055)
> Cc: IETF Sipping List
> While the motivation and application of this header is call 
> centers and ACDs, I am hopeful that we can define a more 
> general mechanism usable for other applications.
> 
> You are correct in saying that there are some similarities to 
> RFC 4240 and that is why I described the URI parameter 
> approach in the draft.
> 
> However, this URI approach does not survive retargeting.  For 
> example, lets say I want to pass some UUI to you.  If I send 
> it to sips:[email-masked];uui=stuff, your proxy will 
> retarget to sips:[email-masked] based on your 
> registration and the UUI is lost.  Of course, we could make 
> this URI parameter like the grid parameter in GRUU, but that 
> would mean using Proxy-Require to be sure it gets through.
> 
> I'd be happy to use a URI parameter approach as it is simpler 
> than a separate header field, but it would need to overcome 
> the retargeting problem without special support in proxies.
> 
> Thanks,
> Alan
> 
> Francois Audet wrote:
> > Alan,
> >
> > and general at the same time.
> >
> > redirection from one target to another, with the redirecting entity 
> > being able to add "information" that needs to be provided to the 
> > retargeted-to entity.
> >
> > The real question in my mind is do we need to standardized the URI 
> > parameters themselves.
> >
> > I'd also like to understand what are the parameters that 
> are believed 
> > to be important.
> >
> >
> > So, while I think standardizing parameters for applications 
> like ACD 
> > probably make sense for inter-vendor compatibility, I don't see any 
> > reason to deviate from things like RFC 3087, RFC 4240 and RFC 4458.
> >
> >
> >   
> >> information is passed in the UUI.  For example, is it a telephone 
> >> number, account number, or other string.  There is already a large 
> >> amount of coordination and configuration among the system 
> components, 
> >> so this is a small detail.
> field is an 
> >> important interoperability issue.  Not having this 
> standardized is a 
> >> serious impediment to building SIP enabled call centers.  
> I think SIP 
> >> is an ideal fit for this space if we do a little work.
> >>
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping