Subject: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 03 Apr 2014 17:17:09 -0500

All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to ratify the
"Standards Action" guideline for defining UUI packages and registering
new IANA elements for the parameter tables for purpose, encoding and
content.

The draft authors note that the original concern when the work
was coming out of Dispatch was that the UUI not become a "wildcard"
header to be used for a wide variety of purposes.  Hence the direction
toward requiring a standards track RFC.  However, a lesser standard
such as "Specification Required" might suffice and offer more
flexibility for additional use cases, while not opening up the process
totally as would be the case for "First Come First Serve."

The IESG will like to revisit this decision to confirm that the WG
decisions remains "Standards Action".

To that end, Enrico and I will like to open up a 2-week period to ratify
this decision to remain at "Standards Action" or to move to something
other designation.

The 2-week period ends on close of business (US Central Time) April 17,
2014.  Please express an opinion; if you are for keeping status quo,
please send a one-liner to the cuss WG mailing list.  If you are of the
opinion that we should relax the burden, please state so and a short
reason on why we should do so.

Thank you all.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2014 10:32:54 -0400

Interesting to see this come back.

My original opinion was (and still is) that for these to be useful, it 
must be possible for using enterprises to assign new values for each 
distinct deployment of an application. IMO even FCFS might be too high a 
bar for this.

E.g., if I create a particular VXML application that captures some data 
and communicates it to a call center agent application via UUI, then the 
format of that data is likely to be unique.

Lowering the bar below FCFS would require a naming scheme that 
guarantees uniqueness without registration.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Fri, 4 Apr 2014 11:46:03 -0500

Paul,

I know you've explained this before.  But you haven't explained how the
requirements in Section 5. Guidelines for UUI Packages can be enforced if
there isn't any review.  Can you elaborate on this?

- Alan -

On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <[email-masked]> wrote:

> Lowering the bar below FCFS would require a naming scheme that guarantees
> uniqueness without registration.
>
>         Thanks,
>         Paul
>
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2014 15:31:17 -0400

On 4/4/14 12:46 PM, Alan Johnston wrote:
> requirements in Section 5. Guidelines for UUI Packages can be enforced
> if there isn't any review.  Can you elaborate on this?

With no review these couldn't be enforced.
They could still remain as guidelines.

	Thanks,
	Paul

> - Alan -
>
>
> On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     My original opinion was (and still is) that for these to be useful,
>     it must be possible for using enterprises to assign new values for
>     each distinct deployment of an application. IMO even FCFS might be
>     too high a bar for this.
>
>     E.g., if I create a particular VXML application that captures some
>     data and communicates it to a call center agent application via UUI,
>     then the format of that data is likely to be unique.
>
>     _________________________________________________
>     cuss mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/cuss
>     <https://www.ietf.org/mailman/listinfo/cuss>
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 14 Apr 2014 10:34:21 -0700

There have not been many responses to Vijay¹s request below. Please send
your opinion to this list, even if it is ³no changes needed.²

Thanks,
Alissa

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Apr 2014 01:36:12 +0000

I believe we would want the guidelines enforced. 

I also expect that we would want to do a further review of the guidelines if they are the sole basis for allowing packages in or not, before we allowed a relaxation of the approval regime.

Regards

Keith 

> -----Original Message-----
> From: cuss [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 04 April 2014 20:31
> To: Alan Johnston
> Cc: [email-masked]
> Subject: Re: [cuss] Ratification of "Standards Action" 
> guideline for draft-ietf-cuss-sip-uui
> 
> > I know you've explained this before.  But you haven't explained how 
> > the requirements in Section 5. Guidelines for UUI Packages can be 
> > enforced if there isn't any review.  Can you elaborate on this?
> 
> >         flexibility for additional use cases, while not 
> opening up the
> >         process
> >         To that end, Enrico and I will like to open up a 
> 2-week period
> >         to ratify
> >         The 2-week period ends on close of business (US 
> Central Time)
> >         April 17,
> >         please send a one-liner to the cuss WG mailing 
> list.  If you are
> >         of the

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Apr 2014 21:59:31 -0400

> I also expect that we would want to do a further review of the guidelines if they are the sole basis for allowing packages in or not, before we allowed a relaxation of the approval regime.

I think the effect of the registration rules will be that no new 
registrations are made, and the default will be used by everyone, as is 
currently the case. That means that everyone depends upon configuration 
to ensure that client and server agree on usage.

If you are running a call center, and decide what information you need 
to communicate from your IVR to your ACD, are you going to publish an 
RFC to register the format for that? I think not. Even a FCFS 
registration is probably too much. Yet it would still be good to ensure 
that client and server are using the same formats.

When I raised this issue early on, I got no traction for it, so I 
decided to let it go until people had deployment experience. Then they 
could figure out they need something different. But now it has come up 
again.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Mon, 14 Apr 2014 21:44:14 -0500

Paul,

Keith and I have been discussing this in terms of new packages, which can
define all new SIP semantics, but I notice in your response you are mainly
talking about contents.  Perhaps we could have different requirements for
these: the specification required for new packages, but something lower for
contents.  I'm not completely sure where encodings would fit in this scheme.

What do you think?

- Alan -

On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <[email-masked]> wrote:

>> I also expect that we would want to do a further review of the guidelines
>> if they are the sole basis for allowing packages in or not, before we
>> allowed a relaxation of the approval regime.
>>
>
> currently the case. That means that everyone depends upon configuration to
> ensure that client and server agree on usage.
>
> If you are running a call center, and decide what information you need to
> communicate from your IVR to your ACD, are you going to publish an RFC to
> register the format for that? I think not. Even a FCFS registration is
> probably too much. Yet it would still be good to ensure that client and
> server are using the same formats.
>
> When I raised this issue early on, I got no traction for it, so I decided
> to let it go until people had deployment experience. Then they could figure
> out they need something different. But now it has come up again.
>
>         Thanks,
>         Paul
>
>  Regards
>>
>> Keith
>>
>>>>      My original opinion was (and still is) that for these
>>>>
>>> to be useful,
>>>
>>>>      it must be possible for using enterprises to assign new
>>>>
>>> values for
>>>
>>>>      each distinct deployment of an application. IMO even
>>>>
>>> FCFS might be
>>>
>>>>      too high a bar for this.
>>>>
>>>>      E.g., if I create a particular VXML application that
>>>>
>>> captures some
>>>
>>>>      data and communicates it to a call center agent
>>>>
>>> application via UUI,
>>>
>>>>          new IANA elements for the parameter tables for
>>>>
>>> purpose, encoding and
>>>
>>>>          content.
>>>>
>>>>          The draft authors note that the original concern
>>>>
>>> when the work
>>>
>>>>          was coming out of Dispatch was that the UUI not
>>>>
>>> become a "wildcard"
>>>
>>>>          toward requiring a standards track RFC.  However, a
>>>>
>>> lesser standard
>>>
>>>>          such as "Specification Required" might suffice and
>>>>
>>> offer more
>>>
>>>>          The IESG will like to revisit this decision to
>>>>
>>> confirm that the WG
>>>
>>>>          2014.  Please express an opinion; if you are for
>>>>
>>> keeping status quo,
>>>
>>>>          opinion that we should relax the burden, please
>>>>
>>> state so and a short
>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Apr 2014 08:24:19 +0000

In the use cse Paul had been giving, I have an assumption that the ISDN package would be used (because call centers) are connected to the PSTN as well. This would be effectively a privately defined protocol running over the top, and signalled as such.

If you want a public protocol (i.e. standardised) running over the top, the package definition, or any other UUI parameters, could be coupled with the RFC that defines it.

Keith

________________________________
From: Alan Johnston [mailto:[email-masked]]
Sent: 15 April 2014 03:44
To: Paul Kyzivat
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui

Paul,

Keith and I have been discussing this in terms of new packages, which can define all new SIP semantics, but I notice in your response you are mainly talking about contents.  Perhaps we could have different requirements for these: the specification required for new packages, but something lower for contents.  I'm not completely sure where encodings would fit in this scheme.

What do you think?

- Alan -

On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote:
I believe we would want the guidelines enforced.

I think the effect of the registration rules will be that no new registrations are made, and the default will be used by everyone, as is currently the case. That means that everyone depends upon configuration to ensure that client and server agree on usage.

If you are running a call center, and decide what information you need to communicate from your IVR to your ACD, are you going to publish an RFC to register the format for that? I think not. Even a FCFS registration is probably too much. Yet it would still be good to ensure that client and server are using the same formats.

When I raised this issue early on, I got no traction for it, so I decided to let it go until people had deployment experience. Then they could figure out they need something different. But now it has come up again.

        Thanks,
        Paul

Regards

Keith

-----Original Message-----
From: cuss [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Kyzivat
Sent: 04 April 2014 20:31
To: Alan Johnston
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [cuss] Ratification of "Standards Action"

        Thanks,
        Paul

- Alan -

On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

              Thanks,
              Paul

         All: The IESG has sent draft-ietf-cuss-sip-uui to the WG to
         ratify the
         "Standards Action" guideline for defining UUI packages and
         registering
         new IANA elements for the parameter tables for
purpose, encoding and
         content.

         header to be used for a wide variety of purposes.  Hence the
         direction

         To that end, Enrico and I will like to open up a
2-week period
         to ratify
         this decision to remain at "Standards Action" or to move to
         something
         other designation.

         Thank you all.

         - vijay

     _________________________________________________
     cuss mailing list
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
     https://www.ietf.org/mailman/__listinfo/cuss
     <https://www.ietf.org/mailman/listinfo/cuss>

_______________________________________________
cuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cuss

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2014 12:33:00 -0400

On 4/14/14 10:44 PM, Alan Johnston wrote:
> Paul,
>
> Keith and I have been discussing this in terms of new packages, which
> can define all new SIP semantics, but I notice in your response you are
> mainly talking about contents.  Perhaps we could have different
> requirements for these: the specification required for new packages, but
> something lower for contents.  I'm not completely sure where encodings
> would fit in this scheme.
>
> What do you think?

Well, if you want to do anything new then you need to define a new 
package. That must have a new purpose, and may have new content and/or 
encoding defs.

There is little in the draft that explains how those should be used 
other than the general meaning of the words "purpose", "content", and 
"encoding". The draft references the isdn draft as an example, but that 
isn't very useful for defining something more specific.

So one question is where to draw the line between purpose and content.
For instance, content might be "CSV", or it might be 
"CallCenter123.example.com". And purpose might be "CallCenter", or it 
might be "CallCenter123.example.com".

The one that is probably the least volatile is "encoding", since we are 
talking about encoding of byte strings. We probably won't need a whole 
lot of those. Maybe "CSV" would be a useful encoding, rather than a 
content. Or maybe TLV. Unfortunately we haven't set a path, so we are 
leaving it to others to decide.

In my mind, the point is that the combination used in a UUI header ought 
to be sufficient so that a receiver can determine if it understands what 
it has received. And I think in general the stuff shared between 
components of one application deployment won't work with some other 
application deployment.

	Thanks,
	Paul

>         I also expect that we would want to do a further review of the
>         guidelines if they are the sole basis for allowing packages in
>         or not, before we allowed a relaxation of the approval regime.
>
>
>     registrations are made, and the default will be used by everyone, as
>     is currently the case. That means that everyone depends upon
>     configuration to ensure that client and server agree on usage.
>
>     If you are running a call center, and decide what information you
>     need to communicate from your IVR to your ACD, are you going to
>     publish an RFC to register the format for that? I think not. Even a
>     FCFS registration is probably too much. Yet it would still be good
>     to ensure that client and server are using the same formats.
>
>     decided to let it go until people had deployment experience. Then
>     they could figure out they need something different. But now it has
>     come up again.
>
>              Thanks,
>              Paul
>
>         Regards
>
>         Keith
>
>             From: cuss [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of Paul Kyzivat
>             Cc: [email-masked] <mailto:[email-masked]>
>                 On Fri, Apr 4, 2014 at 9:32 AM, Paul Kyzivat
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>__> wrote:
>
>                       ___________________________________________________
>                       cuss mailing list
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 https://www.ietf.org/mailman/____listinfo/cuss
>                 <https://www.ietf.org/mailman/__listinfo/cuss>
>                       <https://www.ietf.org/mailman/__listinfo/cuss
>                 <https://www.ietf.org/mailman/listinfo/cuss>>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2014 15:11:48 -0400

On 4/15/14 4:24 AM, DRAGE, Keith (Keith) wrote:
> In the use cse Paul had been giving, I have an assumption that the ISDN
> package would be used (because call centers) are connected to the PSTN
> as well. This would be effectively a privately defined protocol running
> over the top, and signalled as such.
> If you want a public protocol (i.e. standardised) running over the top,
> the package definition, or any other UUI parameters, could be coupled
> with the RFC that defines it.

It doesn't matter if the call center is connected to the PSTN. What 
matters is the source and destination of the UUI. There is a pretty good 
chance that those will be connected with sip - probably within the same 
enterprise.

Everybody using the ISDN package is a *problem*, because it has no way 
to distinguish different usages that don't interoperate.

The point I'm making is that most of the usages *won't* be public. (Are 
there *any* that *are*?)

I write a VXML application for my business. It collects some 
information, and then forwards the call to an ACD, passing the collected 
information via UUI. The format and purpose of that data is specific to 
my particular VXML app and the application the call center operators 
use. Who is going to write an RFC to define that? (Nobody!) If that 
accidentally ends up at the "wrong" app, how will it be detected that it 
is wrong? (Hopefully by the purpose and content attributes of the UUI.)

How do you imagine purpose and content being used, such that somebody 
would be in a position to write an RFC to define them?

	Thanks,
	Paul

> Keith
>
>     ------------------------------------------------------------------------
>     *From:* Alan Johnston [mailto:[email-masked]]
>     *Sent:* 15 April 2014 03:44
>     *To:* Paul Kyzivat
>     *Cc:* DRAGE, Keith (Keith); [email-masked]
>     *Subject:* Re: [cuss] Ratification of "Standards Action" guideline
>     for draft-ietf-cuss-sip-uui
>
>     Paul,
>
>     Keith and I have been discussing this in terms of new packages,
>     which can define all new SIP semantics, but I notice in your
>     response you are mainly talking about contents.  Perhaps we could
>     have different requirements for these: the specification required
>     for new packages, but something lower for contents.  I'm not
>     completely sure where encodings would fit in this scheme.
>
>     What do you think?
>
>     - Alan -
>
>
>             I also expect that we would want to do a further review of
>             the guidelines if they are the sole basis for allowing
>             packages in or not, before we allowed a relaxation of the
>             approval regime.
>
>
>         registrations are made, and the default will be used by
>         everyone, as is currently the case. That means that everyone
>         depends upon configuration to ensure that client and server
>         agree on usage.
>
>         If you are running a call center, and decide what information
>         you need to communicate from your IVR to your ACD, are you going
>         to publish an RFC to register the format for that? I think not.
>         Even a FCFS registration is probably too much. Yet it would
>         still be good to ensure that client and server are using the
>         same formats.
>
>         When I raised this issue early on, I got no traction for it, so
>         I decided to let it go until people had deployment experience.
>         Then they could figure out they need something different. But
>         now it has come up again.
>
>                  Thanks,
>                  Paul
>
>             Regards
>
>             Keith
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Apr 2014 11:20:28 -0400

On 4/15/14 5:30 PM, James Rafferty wrote:
> Hi,
>
> As Alan noted, we seem to be having two discussions here.  What I thought
> we'd be talking about is what level of IANA action is needed.  Recent drafts
> set that bar at "Standards Action."  I'm personally open to the less
> rigorous definition of "Specification Required," which would allow
> organizations outside of the IETF to define packages, but would still imply
> that the guidelines in Section 5 would continue to be enforced.  However,
> there hasn't been any discussion about such a middle ground.
>
> Paul, would lowering the bar to "Specification Required" help offer some of
> the flexibility you want?  This would allow other packages to be defined --
> inside or outside the IETF -- but would still imply adherence to the
> guidelines in section 5.  This would also bring a "designated expert" into
> play, in order to provide review of the proposed specification.

I don't think reducing to "Specification Required" would address my 
concerns in any way. I don't even think reducing to FCFS would do that.

Frankly, *for now* I am satisfied to leave the requirement at Standards 
Action, with the understanding that this is just temporary to get the 
basic mechanism (with the ISDN package) published. That allows us to 
keep control and so prevent something stupid being done.

Then I think there should be further discussion about how purpose, 
content, and encoding *should* be used, and what sorts of registration 
policies would facilitate that.

My thinking is that it should be something like feature tags, with the 
namespace partitioned, so there can be some values with standardized 
values, and another part of the namespace that can be used by individual 
enterprises without need of registration while still preventing collision.

> On some of the other points:
>
> -- Encodings -- I would not expect too many of those to be defined; my
> former company  supported the current binary definition and an earlier ASCII
> encoding

Yes. Me too. But it would be useful to have a discussion of what might 
be other meaningful values.

I personally would have liked to also see a "text" (or "ascii" or 
whatever) encoding. I think many uses would find this sufficient, and it 
would be much more readable for diagnosing call flows, for examples, etc.

Beyond that I don't know. It depends on how the line is drawn between 
content and encoding.

> -- Purpose -- This is the rationale behind having a separate package

Once we get beyond ISDN, I see Purpose as being the primary mechanism 
for ensuring that sender and receiver are compatible.

> -- Content -- allows for further elaboration on what kinds of semantic
> information are supported; see section 5.1 on extensibility

I think it is likely that there would be only one content per purpose, 
and so it will be redundant. OTOH, the purpose could be treated as a 
sort of interface, with the content naming individual messages within 
the interface.

	Thanks,
	Paul

> James
> Sent: Tuesday, April 15, 2014 3:12 PM
> To: DRAGE, Keith (Keith); Alan Johnston
> Cc: [email-masked]
>> In the use cse Paul had been giving, I have an assumption that the
>> ISDN package would be used (because call centers) are connected to the
>> PSTN as well. This would be effectively a privately defined protocol
>> running over the top, and signalled as such.
>> If you want a public protocol (i.e. standardised) running over the
>> top, the package definition, or any other UUI parameters, could be
>> coupled with the RFC that defines it.
>
> It doesn't matter if the call center is connected to the PSTN. What matters
> is the source and destination of the UUI. There is a pretty good chance that
> those will be connected with sip - probably within the same enterprise.
>
> Everybody using the ISDN package is a *problem*, because it has no way to
> distinguish different usages that don't interoperate.
>
> I write a VXML application for my business. It collects some information,
> and then forwards the call to an ACD, passing the collected information via
> UUI. The format and purpose of that data is specific to my particular VXML
> app and the application the call center operators use. Who is going to write
> an RFC to define that? (Nobody!) If that accidentally ends up at the "wrong"
> app, how will it be detected that it is wrong? (Hopefully by the purpose and
> content attributes of the UUI.)
>
> How do you imagine purpose and content being used, such that somebody would
> be in a position to write an RFC to define them?
>
> 	Thanks,
> 	Paul
>
>> Keith
>>
>>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 16 Apr 2014 11:11:47 -0500

Paul,

So we are in agreement, then.  Keep this draft at Standards Action for new
packages so we can keep control over how this mechanism is used.

Your proposal sounds very interesting for opening things up, and if
published as a standards track document would allow for exactly what you
want.

- Alan -

On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat <[email-masked]>wrote:

> Action, with the understanding that this is just temporary to get the basic
> mechanism (with the ISDN package) published. That allows us to keep control
> and so prevent something stupid being done.
>
> Yes. Me too. But it would be useful to have a discussion of what might be
> other meaningful values.
>
> Once we get beyond ISDN, I see Purpose as being the primary mechanism for
> ensuring that sender and receiver are compatible.
>
> I think it is likely that there would be only one content per purpose, and
> so it will be redundant. OTOH, the purpose could be treated as a sort of
> interface, with the content naming individual messages within the interface.
>
>         Thanks,
>         Paul
>
>  James
>>
>>
>> matters
>> would
>>>      On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat <
>>> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Apr 2014 12:45:46 -0400

On 4/16/14 12:11 PM, Alan Johnston wrote:
> Paul,
>
> So we are in agreement, then.  Keep this draft at Standards Action for
> new packages so we can keep control over how this mechanism is used.
>

Perhaps, to resolve the IESG concern over the use of Standards Action, 
we could add some text indicating that this is conservative choice made 
while we if and how to open it up.

	Thanks,
	Paul

> - Alan -
>
>
> On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat <[email-masked]
>     Frankly, *for now* I am satisfied to leave the requirement at
>     Standards Action, with the understanding that this is just temporary
>     to get the basic mechanism (with the ISDN package) published. That
>     allows us to keep control and so prevent something stupid being done.
>
>     content, and encoding *should* be used, and what sorts of
>     registration policies would facilitate that.
>
>     My thinking is that it should be something like feature tags, with
>     the namespace partitioned, so there can be some values with
>     standardized values, and another part of the namespace that can be
>     used by individual enterprises without need of registration while
>     still preventing collision.
>
>     Yes. Me too. But it would be useful to have a discussion of what
>     might be other meaningful values.
>
>     whatever) encoding. I think many uses would find this sufficient,
>     and it would be much more readable for diagnosing call flows, for
>     examples, etc.
>
>     Beyond that I don't know. It depends on how the line is drawn
>     between content and encoding.
>
>     Once we get beyond ISDN, I see Purpose as being the primary
>     mechanism for ensuring that sender and receiver are compatible.
>
>     I think it is likely that there would be only one content per
>     purpose, and so it will be redundant. OTOH, the purpose could be
>     treated as a sort of interface, with the content naming individual
>     messages within the interface.
>
>              Thanks,
>              Paul
>
>         James
>
>
>         information,
>         ------------------------------__------------------------------__------------
>
>                   *From:* Alan Johnston
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             <mailto:[email-masked]>
>                   On Mon, Apr 14, 2014 at 8:59 PM, Paul Kyzivat
>             <mailto:[email-masked]>
>                               <mailto:[email-masked]
>             <mailto:[email-masked]>>__] On Behalf Of Paul Kyzivat
>                                   I know you've explained this before.
>               But you
>                                   haven't explained how
>                                   the requirements in Section 5.
>             Guidelines for UUI
>                                   Packages can be
>                                   enforced if there isn't any review.
>               Can you
>                                   elaborate on this?
>
>
>                                   <[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>>__>__> wrote:
>
>                                         My original opinion was (and
>             still is) that
>                                   for these
>
>                               to be useful,
>
>                                         it must be possible for using
>             enterprises to
>                                   assign new
>
>                               values for
>
>                                         each distinct deployment of an
>             application.
>                                   IMO even
>
>                               FCFS might be
>
>                                         too high a bar for this.
>
>                                         data and communicates it to a
>             call center
>             agent
>
>                               application via UUI,
>
>                                         then the format of that data is
>             likely to be
>                                   unique.
>
>                                         Lowering the bar below FCFS
>             would require a
>                                   naming scheme that
>                                             "Standards Action" guideline
>             for defining
>                                   UUI packages and
>                                             registering
>                                             new IANA elements for the
>             parameter
>             tables for
>
>                               purpose, encoding and
>
>                                             content.
>
>                                             The draft authors note that
>             the original
>                                   concern
>
>                               when the work
>
>                                             was coming out of Dispatch
>             was that the
>                                   UUI not
>
>                               become a "wildcard"
>
>                                             header to be used for a wide
>             variety of
>                                   purposes.  Hence the
>                                             direction
>                                             toward requiring a standards
>             track RFC.
>                                     However, a
>
>                               lesser standard
>
>                                             such as "Specification
>             Required" might
>                                   suffice and
>
>                               offer more
>
>                                             flexibility for additional
>             use cases,
>                                   while not
>
>                               opening up the
>
>                                             process
>                                             totally as would be the case
>             for "First
>                                   Come First Serve."
>
>                                             The IESG will like to
>             revisit this
>             decision to
>
>                               confirm that the WG
>
>                                             To that end, Enrico and I
>             will like to
>                                   open up a
>
>                               2-week period
>
>                                             to ratify
>                                             this decision to remain at
>             "Standards
>                                   Action" or to move to
>                                             something
>                                             other designation.
>
>                                             The 2-week period ends on
>             close of
>                                   business (US
>
>                               Central Time)
>
>                                             April 17,
>                                             2014.  Please express an
>             opinion; if you
>                                   are for
>
>                               keeping status quo,
>
>                                             please send a one-liner to
>             the cuss WG
>             mailing
>
>                               list.  If you are
>
>                                             of the
>                                             opinion that we should relax
>             the burden,
>                                   please
>
>                               state so and a short
>
>               _____________________________________________________
>                                         cuss mailing list
>             [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>                                   <mailto:[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>>
>             https://www.ietf.org/mailman/______listinfo/cuss
>             <https://www.ietf.org/mailman/____listinfo/cuss>
>
>               <https://www.ietf.org/mailman/____listinfo/cuss
>             <https://www.ietf.org/mailman/__listinfo/cuss>>
>
>               <https://www.ietf.org/mailman/____listinfo/cuss
>             <https://www.ietf.org/mailman/listinfo/cuss>>>
>
>
>
>
>             [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 18 Apr 2014 14:09:12 -0700

>while we if and how to open it up.

This sounds like a reasonable resolution to me.
Alissa

>>                                         E.g., if I create a particular
>>VXML
>>                                   application that
>>
>>                               captures some
>>