Subject: [cuss] Definition of "application"

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2011 14:41:05 -0400

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

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 22 Sep 2011 19:20:13 +0000

Paul

Application is the "user" of the UUI information.
This a capability, not a "service", so I not sure what you are digging for here

Martin
Martin C. Dolly
Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible.
+1.609.903.3360

----- Original Message -----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, September 22, 2011 02:41 PM
To: [email-masked] <[email-masked]>
Subject: [cuss] Definition of "application"

	Thanks,
	Paul
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2011 17:16:46 -0400

> This a capability, not a "service", so I not sure what you are digging for here

My point is that if each deployment is a different application, using 
different content formats, then an IANA registration model for 
application and content doesn't really work, and we should be looking 
for something else.

Alternately, we need to consider if there is a way applications and 
content of a sort suitable for iana registration provide a useful model 
for how to use this mechanism.

OR, we just forget about application and content definitions. In which 
case we don't need to mention applications at all.

	Thanks,
	Paul

> To: [email-masked]<[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 23 Sep 2011 12:49:18 +0200

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

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.

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]