Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
Alissa Cooper <alissa@cooperw.in> Fri, 18 April 2014 21:09 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: cuss@ietfa.amsl.com
Delivered-To: cuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437A51A0495 for <cuss@ietfa.amsl.com>; Fri, 18 Apr 2014 14:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMB7AxZsmpJ9 for <cuss@ietfa.amsl.com>; Fri, 18 Apr 2014 14:09:26 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id D66121A043E for <cuss@ietf.org>; Fri, 18 Apr 2014 14:09:25 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7BA30217AD for <cuss@ietf.org>; Fri, 18 Apr 2014 17:09:21 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 18 Apr 2014 17:09:21 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=Es/2kvqqJVLIn5MvZ1VaAYAsGPc=; b=lXKESDIJ5ffNlFc+h8PSqblSmHzt c6TpVhUDZfQSaAo8eRSqCoWnb2a6zuOZBEo0zSBqDeT+ihUdmL++J+GPtGfPalYu 0zzeWcbedoLQTmtEQmhr8EO/c+kTmiSftuNuGgPTITmp3RH0KMC4vhKt2Nj11Ia8 8LwOkcLyT2Nb0DU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=Es/2kvqqJVLIn5MvZ1VaAY AsGPc=; b=Fj8XPDYo1A/7EDeghXOR1Jr6D86OUgMOgWMuOR8dhsP78ieQPQR7Rg yAHEWwCgvjR5t1riQKzgWY7gfEtnBAh7RrNpdyVJ8pXX74rexYicJFXV2tASWhL7 EN570mrfFq4T9R4vauBrzQyLbvb57WnD4AYufdV9O0O10MYBBKZM0=
X-Sasl-enc: 1LY8kR2zEOiSNg2r97tbBCroytLexOFGVdqcWFwmSzPo 1397855359
Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 86A40C0000C; Fri, 18 Apr 2014 17:09:18 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Fri, 18 Apr 2014 14:09:12 -0700
From: Alissa Cooper <alissa@cooperw.in>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Alan Johnston <alan.b.johnston@gmail.com>
Message-ID: <CF76E26E.34E6F%alissa@cooperw.in>
Thread-Topic: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
References: <533DDDE5.9030101@bell-labs.com> <533EC296.2080603@alum.mit.edu> <CAKhHsXFSXaY=Ch_YKfVN6AyYmF_UCVzy4wdoj-mBjLKXjHyGsQ@mail.gmail.com> <533F0885.7040503@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B1873A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534C9283.3010206@alum.mit.edu> <CAKhHsXECj+HsBNYju8kE8yUJ9-ijdvs6KTPnnO6wW_4A_UqRXw@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8B187709@FR712WXCHMBA11.zeu.alcatel-lucent.com> <534D8474.70403@alum.mit.edu> <03fd01cf58f2$03946320$0abd2960$@humancomm.com> <534E9FBC.3000508@alum.mit.edu> <CAKhHsXE2JsDmpwUmEOtAA9a5PN-qBu+UCYzoN01CLzjZ8qfmCA@mail.gmail.com> <534EB3BA.6070504@alum.mit.edu>
In-Reply-To: <534EB3BA.6070504@alum.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cuss/6m6zfpYSJ4eYJW2OXI4CwsAKK3c
Cc: "cuss@ietf.org" <cuss@ietf.org>
Subject: Re: [cuss] Ratification of "Standards Action" guideline for draft-ietf-cuss-sip-uui
X-BeenThere: cuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" <cuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cuss>, <mailto:cuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cuss/>
List-Post: <mailto:cuss@ietf.org>
List-Help: <mailto:cuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cuss>, <mailto:cuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Apr 2014 21:09:30 -0000
On 4/16/14, 9:45 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote: >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. >> >> Your proposal sounds very interesting for opening things up, and if >> published as a standards track document would allow for exactly what you >> want. > >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. This sounds like a reasonable resolution to me. Alissa > > Thanks, > Paul > >> - Alan - >> >> >> On Wed, Apr 16, 2014 at 10:20 AM, Paul Kyzivat <pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu>> wrote: >> >> 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 >> >> >> -----Original Message----- >> From: cuss [mailto:cuss-bounces@ietf.org >> <mailto:cuss-bounces@ietf.org>] On Behalf Of Paul Kyzivat >> Sent: Tuesday, April 15, 2014 3:12 PM >> To: DRAGE, Keith (Keith); Alan Johnston >> Cc: cuss@ietf.org <mailto:cuss@ietf.org> >> Subject: Re: [cuss] Ratification of "Standards Action" >>guideline for >> draft-ietf-cuss-sip-uui >> >> 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:alan.b.johnston@gmail.__com >> <mailto:alan.b.johnston@gmail.com>] >> *Sent:* 15 April 2014 03:44 >> *To:* Paul Kyzivat >> *Cc:* DRAGE, Keith (Keith); cuss@ietf.org >> <mailto:cuss@ietf.org> >> *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 >> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu> >> <mailto:pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu>>__> wrote: >> >> On 4/14/14 9:36 PM, DRAGE, Keith (Keith) wrote: >> >> 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. >> >> >> 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:cuss-bounces@ietf.org >> <mailto:cuss-bounces@ietf.org> >> <mailto:cuss-bounces@ietf.org >> <mailto:cuss-bounces@ietf.org>>__] On Behalf Of Paul Kyzivat >> Sent: 04 April 2014 20:31 >> To: Alan Johnston >> Cc: cuss@ietf.org <mailto:cuss@ietf.org> >> <mailto:cuss@ietf.org <mailto:cuss@ietf.org>> >> Subject: Re: [cuss] Ratification of >> "Standards Action" >> guideline for draft-ietf-cuss-sip-uui >> >> On 4/4/14 12:46 PM, Alan Johnston wrote: >> >> 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? >> >> >> 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 >> <pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu> <mailto:pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu>> >> <mailto:pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu> >> <mailto:pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu>>__>__> wrote: >> >> 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 >> >> On 4/3/14 6:17 PM, Vijay K. >> Gurbani wrote: >> >> 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 >> >> >> >> >> _____________________________________________________ >> cuss mailing list >> cuss@ietf.org <mailto:cuss@ietf.org> <mailto:cuss@ietf.org >> <mailto:cuss@ietf.org>> >> <mailto:cuss@ietf.org >> <mailto:cuss@ietf.org> <mailto:cuss@ietf.org >> <mailto:cuss@ietf.org>>> >> 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> >> >> <https://www.ietf.org/mailman/__listinfo/cuss >> <https://www.ietf.org/mailman/listinfo/cuss>>> >> >> >> >> >> ___________________________________________________ >> cuss mailing list >> cuss@ietf.org <mailto:cuss@ietf.org> <mailto:cuss@ietf.org >> <mailto:cuss@ietf.org>> >> 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>> >> >> >> >> >> _________________________________________________ >> cuss mailing list >> cuss@ietf.org <mailto:cuss@ietf.org> >> https://www.ietf.org/mailman/__listinfo/cuss >> <https://www.ietf.org/mailman/listinfo/cuss> >> >> >> >> > >_______________________________________________ >cuss mailing list >cuss@ietf.org >https://www.ietf.org/mailman/listinfo/cuss
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alissa Cooper
- Re: [cuss] Ratification of "Standards Action" gui… DRAGE, Keith (Keith)
- [cuss] Ratification of "Standards Action" guideli… Vijay K. Gurbani
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alan Johnston
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alan Johnston
- Re: [cuss] Ratification of "Standards Action" gui… DRAGE, Keith (Keith)
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alan Johnston
- Re: [cuss] Ratification of "Standards Action" gui… Paul Kyzivat
- Re: [cuss] Ratification of "Standards Action" gui… Alissa Cooper