Subject: Re: [cuss] Definition of "application"

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Oct 2011 16:53:30 -0400

On 9/23/11 6:49 AM, DRAGE, Keith (Keith) wrote:
> I suspect we need two separate and distinct terms.
>
> 1)	To represent the entity above the SIP later which is the consumer and generator of the UUI information, and which in many cases will not be a SIP user. This entity has responsibility for the format and content of the payload (including the ISDN protocol discriminator).

Are you presuming there is a single (distributed) entity that both 
generates and consumes the UUI info? Or shall we treat the generator and 
the consumer as independent entities?

In any case, while we probably do need some terminology for this, it can 
be a little loose, because I don't think there are any normative 
requirements on it - its only descriptive.

> 2)	To represent the different usage documents, where a different<term>  maps to each different value of the "app" header field parameter. The value of the "app" header field parameter defines what values are legitimate in the "content" header field parameter and the "encoding" header field parameter.

This is more what I was concerned about. But I do think there is a tight 
relationship between this, and the consuming entity.

What concerns me is the granularity of these, who deals with them, how 
often do they change. The registration model must be realistic relative 
to these characteristics.

For instance, IIUC, each distinct call center that deploys a suite of 
call center applications is likely to have its own set of content 
descriptions, and a unique "app" to identify them. But I also think its 
unrealistic to expect that each call center deployment will do a unique 
IANA registration.

	Thanks,
	Paul

> Suggestions welcome.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Paul Kyzivat
>> Sent: 22 September 2011 19:41
>> To: [email-masked]
>> Subject: [cuss] Definition of "application"
>>
>> In the meeting the other day I expressed confusion over the use of
>> "application" in cuss. IMO its far from clear what is intended, and it
>> may be ambiguous. Here are some examples of usage of this term in the
>> mechanism doc:
>>
>>     Individual applications using the UUI mechanism will
>>     utilize media feature tags to indicate that a UA supports a particular
>>     application user of UUI. [Section 1]
>>
>>     All applications using this SIP UUI mechanism must publish a
>>     standards track RFC which describes the usage.  The SIP UUI mechanism
>>     is applicable in the following situations:
>>
>>         1.  The information is generated and consumed by an application
>>         during session setup using SIP, but the application is not
>>         necessarily SIP aware.
>>         ...
>>     [Section 5]
>>
>>     The "app" parameter identifies the application which generates and
>>     consumes the UUI information. [Section 4]
>>
>> My confusion is whether "application" means:
>>
>> 1) A particular conceptual function (or maybe "business process")
>>      made of components that communicate using sip, that could be
>>      implemented and instantiated multiple times. (E.g. "call center".)
>>
>> 2) A particular implementation of (1) as specific server code,
>>      but which still can be instantiated multiple times. (E.g.
>>      "Example Corp distributed call center product")
>>
>> 3) A particular deployment of (1) or (2). (E.g. the ABC Corp.
>>      deployment of the Example Corp distributed call center product,
>>      including configuration of the data gathered by an IVR and
>>      passed via UUI.)
>>
>> The reason I ask is because its my impression that common practice today
>> is for the format of data passed via UUI to be customized per
>> deployment. Thus "content" would need to be defined per deployment. And
>> then, since applications define the allowed content, the applications
>> also need to be defined per-deployment. (What I describe as (3) above.)
>> BUT, IMO its unreasonable to expect that individual deployments would do
>> such registration.
>>
>> But IMO it would be good to use app= and content= to identify the
>> significance of the UUI data. Doing so would potentially prevent
>> mistakes due to misconfiguration, and would help in analysis of network
>> traffic. It also could potentially be used for message routing.
>>
>> It *may* be possible that standards could be defined for "content",
>> consistent with application definitions (1) and/or (2) above. But that
>> remains to be demonstrated - it may not turn out to be true in practice.
>>
>> If applications of UUI fall into definition (3) above, then I think the
>> naming for applications and content needs to be relaxed so that no
>> registration is required. That probably means identifiers that are
>> naturally unique.
>>
>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> cuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 3 Oct 2011 15:15:47 +0200

1)	As far as the ISDN package is concerned, it is just something above from which I receive and to which I deliver UUI. I don't believe we make any assumptions about how it is structured, not at the moment do I see a need to. The payload may well place requirements on that, but the payload contents is out of scope of the package.

Essentially the "package" (new name for "app") header field parameter, and the "content" header field parameter define all the information that is available to determine the contents of the UUI payload.

The intention is to make values of these header field parameters RFC defined and registered.

Therefore if a vendor wants to use package x, and wants other indications that it is version A in the payload versus version B in the payload then one of:

1)	Use part of the payload to define the appropriate versioning

2)	Write an RFC to define new values of content or whatever.

3)	Assume some a priori agreement between the sender and receiver as to what the contents of this payload really mean. This is what happens in the ISDN, and is I believe what we are currently assuming will happen generally in UUI.

Regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 02 October 2011 21:54
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [cuss] Definition of "application"
> 
> > 1)	To represent the entity above the SIP later which is the consumer
> and generator of the UUI information, and which in many cases will not be
> a SIP user. This entity has responsibility for the format and content of
> the payload (including the ISDN protocol discriminator).
> 
> > 2)	To represent the different usage documents, where a different<term>
> maps to each different value of the "app" header field parameter. The
> value of the "app" header field parameter defines what values are
> legitimate in the "content" header field parameter and the "encoding"
> header field parameter.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Oct 2011 22:32:00 -0400

> 3)	Assume some a priori agreement between the sender and receiver as to what the contents of this payload really mean. This is what happens in the ISDN, and is I believe what we are currently assum…

Well, to use anything other than ISDN, there would have to be at least 
one new package and content defined. If (3) is the expected usage, then 
I guess we should include one such definition as part of this work, for 
a content that allows anything and a package that calls for that 
content. And then we can more or less assume that is all there will ever be.

But if that is the case, then there is no point in defining package and 
content at all, which is why I am asking the question.

ISTM that it would be better if each distinct usage had its own unique 
package name. But if individual deployments of applications have their 
own content definitions, then RFC registration of a package for each is 
unrealistic. So maybe we need a way to identify unique package names and 
content names without need of a formal registration process, such as is 
allowed for callee capabilities.

Having this would ensure that if uui arrives at a place that won't 
understand the content, that will be recognized.

	Thanks,
	Paul