Re: [martini] Proposed work split:tackletelephone-numberregistration first
"DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> Fri, 29 January 2010 20:17 UTC
Return-Path: <drage@alcatel-lucent.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024BA3A67D4 for <martini@core3.amsl.com>; Fri, 29 Jan 2010 12:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4SRc9f-Wshk for <martini@core3.amsl.com>; Fri, 29 Jan 2010 12:17:22 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 8D06C3A686C for <martini@ietf.org>; Fri, 29 Jan 2010 12:17:21 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o0TKHgBw001486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Jan 2010 21:17:42 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 29 Jan 2010 21:17:42 +0100
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: Eric Burger <eburger@standardstrack.com>, "bruno.chatras@orange-ftgroup.com" <bruno.chatras@orange-ftgroup.com>
Date: Fri, 29 Jan 2010 21:15:44 +0100
Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first
Thread-Index: Acqg8SOnJoy7PGNpQpqpCyGEkpv8MgALpOlQ
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE20ADFB9C8@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><D890DEF3-37DF-462B-955A-94005E1808B5@standardstrack.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <E9F685BC6F3D40B0A113F8198BD62BE3@china.huawei.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> <A9CEEB4B-3523-487D-ACBE-FE5E739F590F@standardstrack.com>
In-Reply-To: <A9CEEB4B-3523-487D-ACBE-FE5E739F590F@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84
Cc: "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 20:17:24 -0000
Is the market today 100% tel URIs or is it 100% telephone numbers masquerading as SIP URIs? regards Keith > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Friday, January 29, 2010 2:41 PM > To: bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work > split:tackletelephone-numberregistration first > > On the one hand, I agree we have to work on a general > mechanism to enable the SP to provision IP PBXen as well as > an efficient way for IP PBXen to register endpoints to an SP. > > On the other hand, are you willing to wait 3-5 years for the > general mechanism? More especially so given the industry > today is 99.9% E.164 numbers and needs a solution last year? > This is a serious question: if service providers are saying, > "This is going to be important, but we really do not need a > solution in 3-5 years," then that informs our > work: we can relax and engineer the perfect solution. > However, almost all of the service providers I speak with > say, "A solution to this problem is already a year late. If > we do not see something soon [2-3 months] we are going to > codify and deploy the (admittedly broken) REGISTER method > that we are already using, with or without the IETF. > It would be nice if we could have a not-so-broken mechanism, > but the market has lost its patience." > > Again, doing the E.164-only solution today does not mean we > ignore the long-term problem. > > Does this work for you? > > On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: > > > Hi, Bruno, > > > > My apologies for not snapping when I saw your e-mail address - I'm > > currently chairing three working groups, and things are getting a > > little blurry (MEDIACTRL *really* needs to finish soon!). > > > > Thanks for the input - it's helpful. > > > > Spencer > > > > ----- Original Message ----- From: > <bruno.chatras@orange-ftgroup.com> > > To: <spencer@wonderhamster.org>; <blindsay@nortel.com>; > > <eburger@standardstrack.com > > >; <dean.willis@softarmor.com> > > Cc: <martini@ietf.org> > > Sent: Friday, January 29, 2010 7:39 AM > > Subject: RE: [martini] Proposed work split:tackletelephone- > > numberregistration first > > > > > > Hi Spencer, > > > > I have seen you request on the sip-ops list where you noted that > > MARTINI is not getting inputs from other operators (than CableLabs). > > I'm actually representing a fixed and mobile operator > (France Telecom > > - Orange) and as you can guess from my previous posts we support a > > REGISTER-based solution and believe that a solution > restricted to Tel > > URIs would be of limited interest. > > > > /BC > > > > > > > >> -----Message d'origine----- > >> De : martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > >> Envoyé : jeudi 28 janvier 2010 22:59 > >> À : Brian Lindsay; Eric Burger; Dean Willis > >> Cc : martini@ietf.org > >> Objet : Re: [martini] Proposed work > >> split:tackletelephone-numberregistration first > >> > >> Hi, Brian, > >> > >> Thanks for the quick feedback. I'm mostly asking if I'm > >> reading where we are going correctly (I GOTTA get the draft > >> minutes out from that call!). > >> > >> This is kind of twisty-little-passages-all-alike/different > >> (for those of you that remember the "adventure" game in the > >> early 1980s), but I'm trying to follow the chain. Where I > >> thought we were, was that we didn't have a coherent story for > >> how we get a call from outside the service provider, to the > >> service provider, to the SIP-PBX, and I've heard a bunch of > >> smart guys talk for a long time on a number of occasions > >> about how that might work/not work, usually ending with "but > >> if this was limited to E.164 numbers, a lot of these problems > >> would go away". > >> > >> So I'm trying to laces comments from the call that I remember > >> together, and see what the resulting tapestry looks like. > >> > >> Tell you what. I'll go work on draft minutes and stop typing > >> e-mail, and we'll see if that works better :D > >> > >> Spencer > >> > >> ----- Original Message ----- > >> From: "Brian Lindsay" <blindsay@nortel.com> > >> To: "Spencer Dawkins" <spencer@wonderhamster.org>; "Eric Burger" > >> <eburger@standardstrack.com>; "Dean Willis" > >> <dean.willis@softarmor.com> > >> Cc: <martini@ietf.org> > >> Sent: Thursday, January 28, 2010 3:48 PM > >> Subject: RE: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> > >> Hi Spencer, > >> > >> I am not sure if this is going down the path that the > >> actual register > >> request uses a Tel: URI. > >> > >> If so, I don't see why that needs to be the case. The > >> REGISTER itself > >> can still be done per Martini-Shaken with a SIP URI > >> representing the SIP > >> PBX. In fact, I am not sure too much has to change with Martini- > >> Shaken > >> unless you want to enforce use of a Tel URI format for > requests sent > >> towards the SIP PBX. > >> > >> Thanks > >> Brian > >> > >> > >> > >> -----Original Message----- > >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > >> Behalf Of Spencer Dawkins > >> Sent: Thursday, January 28, 2010 4:39 PM > >> To: Eric Burger; Dean Willis > >> Cc: martini@ietf.org > >> Subject: Re: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> OK, this discussion continues to be lovely. Thanks again for > >> listening > >> to the people you're talking to ("plays well with others" is > >> under-appreciated, once we get out of primary school, but *I* > >> appreciate > >> it!) > >> > >> After reading this thread down through Eric's note below, > I have a > >> few > >> requests, as co-chair. > >> > >> We're talking about E.164 numbers like we can easily > identify them. > >> My > >> understanding from Tuesday's call was that people on the > call thought > >> the only way we could unambiguously know that we had an E.164 > >> number was > >> if we had a tel: URI. If people on this list want to challenge that > >> assertion, this would be a great time to say so - please push > >> back Real > >> Soon Now. > >> > >> If that's true, we're talking about using Tel: URIs. Dean has > >> asserted > >> that this would require an update to 3261. I'm not a genius > >> of 3261, but > >> some of you guys are - could you point us to what you think > >> needs to be > >> updated? > >> > >> My quick read turned up this text in Section 4, page 17: > >> > >> Registration is another common operation in SIP. > >> Registration is one > >> way that the biloxi.com server can learn the current > >> location of Bob. > >> Upon initialization, and at periodic intervals, Bob's SIP > >> phone sends > >> REGISTER messages to a server in the biloxi.com domain > >> known as a SIP > >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI > >> (sip:bob@biloxi.com) with the machine into which he is currently > >> logged (conveyed as a SIP or SIPS URI in the Contact > header field). > >> > >> Dean, Is this what you were thinking of? Are there other > places that > >> also need to change? > >> > >> As I read http://www.ietf.org/id/draft-peterson-rai- > >> rfc3427bis-04.txt, > >> Section 2.1, this change would have to go through SIPCORE, > >> because it's > >> an update to 3261. If you know of obvious land mines that > we would be > >> walking into if we propose this change, please say so Real > Soon Now. > >> (One obvious land mine is that DISPATCH isn't meeting in > >> Anaheim, so the > >> proposal would have to be DISPATCHed on the mailing list in > >> order to do > >> something before IETF 78 - are there OTHERS?) > >> > >> Finally, if you believe that embracing tel: URIs is the > wrong thing > >> to > >> do, please say so, Real Soon Now. > >> > >> The milestones that we committed to in > >> http://tools.ietf.org/wg/martini/charters have us adopting > a working > >> group SOLUTION draft in January. We're not late yet, but it's the > >> 28th > >> of January in my time zone. If we are late, where late is > measured in > >> days, I can live with that, but if we are late, where late is > >> measured > >> in IETF meeting cycles, that's going to be a problem. > >> > >> Thanks, > >> > >> Spencer, as co-chair > >> > >> ----- Original Message ----- > >> From: "Eric Burger" <eburger@standardstrack.com> > >> To: "Dean Willis" <dean.willis@softarmor.com> > >> Cc: <martini@ietf.org> > >> Sent: Thursday, January 28, 2010 12:32 PM > >> Subject: Re: [martini] Proposed work split: tackle > >> telephone-numberregistration first > >> > >> > >> > If you ask me (why can't I stay in retirement?), the E.164 > >> situation > >> is > >> > not only a simplification, but just about the only thing that is > >> sensible > >> > for MARTINI to work on. > >> > > >> > The E.164 situation is a clear, present, > industry-is-begging-for-a- > >> > solution problem. It is so pressing, the industry will tell us > >> (the > >> > IETF) to get stuffed and do something stupid if we cannot deliver > >> > something that is not at its core fundamentally broken. > >> > > >> > I do not think anyone can have an issue with mechanisms > >> that translate > >> a > >> > string of digits into an AOR that might cross domain boundaries. > >> This is > >> > the E.164 problem statement. > >> > > >> > If think everyone (with a brain) SHOULD have issues with a > >> mechanism > >> that > >> > magically mungs "sip:eburger@neustar.biz" into > >> "sip:5350@pbx.example.net " > >> > while at the same time www.neustar.biz is really a neustar.biz > >> domain. > >> > That really would be creating a parallel DNS, which, as > one of the > >> major > >> > DNS operators, would really, really be "less than ideal" and > >> have a > >> whole > >> > host of security and integrity issues. > >> > > >> > THEREFORE, I would propose that we split this work into > two phases: > >> > Phase 1: Deliver an E.164 solution, preferably in the next few > >> months, > >> > so the industry does not ignore the IETF. > >> > > >> > Phase 2: Deliver the generic solution in the normal, 3-5 year > >> IETF > >> > cycle. This generic solution may or may not encompass > >> E.164 numbers. > >> As > >> > Doug Sauder points out, E.164 numbers and their > infrastructure are > >> > different. Thus a different E.164 registration model from > >> generic SIP > >> > URI provisioning models would neither be a burden on industry nor > >> create > >> > backwards-compatibility issues for the generic solution. > >> > > >> > Note that if we do not deliver Phase 1 in a very, very > >> timely manner, > >> the > >> > less-than-idea industry solution just might blow up the > >> possibility > >> for > >> > the generic solution, which would be considerably less > than ideal. > >> > > >> > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> > > >> >> > >> >> We seem to have an urgent need for a near-term solution for > >> dealing > >> with > >> >> the subset of the MARTINI problem that, loosely defined, > >> covers the > >> >> "telephone number" problem. > >> >> > >> >> The typical scenario here is SIP trunking, wherein a SIP Service > >> >> Provider (SSP) provides an ISDN-PRI like service over IP to a > >> customer's > >> >> PBX (or PBXes). In this model, the SSP maps a whole bunch > >> of phone > >> >> numbers to the PBXes. This mapping is somewhat dynamic, > >> because the > >> >> PBXes usually have DHCP addresses, and don't have DNS entries > >> that > >> point > >> >> A records at the PBX in any sort of particularly useful way > >> (maybe > >> >> something like dhcp-10-1-2-3- example.com). > >> >> > >> >> So what we need is a way for a PBX, when it reboots (or perhaps > >> >> periodically) to say to the SSP "Here I Am; You may now send any > >> calls > >> >> for my assigned phone numbers to my current Contact." > >> >> > >> >> This is indeed a "registration" problem, but it isn't > >> necessarily a > >> >> "domain registration problem". The only reason domains get mixed > >> into > >> >> this scenario at all is that we sometimes encode telephone > >> numbers > >> as > >> >> the user parts of SIP URIs, and those SIP URIs have a > domain part > >> >> attached to them. > >> >> > >> >> More interestingly, this problem is a tiny subset of the whole > >> MARTINI > >> >> dynamic binding problem, and it potentially can be solved > >> much more > >> >> simply than the general problem. > >> >> > >> >> On today's Interim II call, Richard, Adam and I raised > the idea of > >> >> dividing our problem space, and taking on a near-term > milestone > >> for > >> >> delivering a MARTINI solution for registering contacts > to a proxy, > >> where > >> >> that proxy maps one or more telephone numbers to the contact. > >> >> > >> >> We certainly intend to go on and tackle the more general domain- > >> >> registration problem, but I (and I believe Adam and > >> Richard) believe > >> >> that we get a lot out of tackling the telephone-number > >> subset first. > >> >> > >> >> In particular, we believe that this approach solves many of the > >> domain > >> >> "responsibility" questions, simplifies the TLS keying/ > >> certification > >> >> model immensely, eliminates the cognitive overload of > >> using REGISTER > >> to > >> >> bind a "domain" to a Contact, "route authentication", > and a good > >> many > >> >> other open issues that plague our current drafts. > >> >> > >> >> > >> >> Open questions relating to this approach include: > >> >> > >> >> 1) Do we deal only with E.164 numbers, or do we need to > deal with > >> >> private-number "phone contexts"? > >> >> > >> >> 2) D owe need to explicitly encode the telephone numbers being > >> >> registered in the REGISTER request (either directly or through > >> some > >> sort > >> >> of regexp), or is it adequate to rely on provisioning of > >> the SSP and > >> PBX > >> >> (and any UAs) to statically bind the numbers to the PBX > identity, > >> and > >> >> then dynamically only register the PBX identity to the > >> PBX contact? > >> >> > >> >> 3) Can we "register" with a tel: URI as the "To" value? (this > >> seems > >> to > >> >> require extending RFC 3261)? Note that "tel:" can express > >> both E. 164 > >> >> numbers and private phone-contexts in one format. > >> >> > >> >> 4) What happens with GRUUs? > >> >> > >> >> I believe all of these issues are quite tractable, if > we accept > >> the > >> >> fundamental idea of splitting the phone-number problem > off from > >> the > >> more > >> >> general domain-registration, and recognize the possibility > >> that the > >> >> solutions to the two problem may reasonably be quite > >> different from > >> each > >> >> other. > >> >> > >> >> So, what do you people think? Is it worth trying to drink the > >> MARTINI > >> >> elephant one sip at a time, or are we going to treat the > >> whole thing > >> >> like a tequila shot and just slam it down? > >> >> > >> >> -- > >> >> Dean > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> martini mailing list > >> >> martini@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/martini > >> > > >> > _______________________________________________ > >> > martini mailing list > >> > martini@ietf.org > >> > https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > > > ********************************* > > This message and any attachments (the "message") are confidential > > and intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if > altered, > > changed or falsified. > > If you are not the intended addressee of this message, > please cancel > > it immediately and inform the sender. > > ******************************** > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >
- Re: [martini] Proposed work split: tackle telepho… Eric Burger
- [martini] Proposed work split: tackle telephone-n… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Sanjay Sinha (sanjsinh)
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Doug Sauder
- Re: [martini] Proposed work split: tackle telepho… bruno.chatras
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Doug Sauder
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackletelephon… Brian Lindsay
- Re: [martini] Proposed work split: tackletelephon… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… DRAGE, Keith (Keith)
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split: tackle telepho… eburger
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… bruno.chatras
- Re: [martini] Proposed work split:tackletelephone… bruno.chatras
- Re: [martini] Proposed work split:tackletelephone… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split:tackletelephone… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split:tackle telephon… Spencer Dawkins
- Re: [martini] Proposed work split:tackle telephon… Adam Roach
- Re: [martini] Proposed work split:tackle telephon… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split:tackletelephone… bruno.chatras
- Re: [martini] Proposed work split:tackletelephone… Adam Roach
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed worksplit: tackle telephon… Brian Lindsay
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed worksplit: tackle telephon… Richard Shockey
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split:tackletelephone… DRAGE, Keith (Keith)
- Re: [martini] Proposed work split:tackletelephone… Richard Shockey
- Re: [martini] Proposed work split:tackletelephone… Xavier Marjou
- Re: [martini] Proposed work split:tackletelephone… Christer Holmberg
- Re: [martini] Proposed work split:tackletelephone… DRAGE, Keith (Keith)
- Re: [martini] Proposed work split: tackle telepho… Adam Roach
- Re: [martini] Proposed work split:tackletelephone… Eric Burger
- Re: [martini] Proposed worksplit:tackletelephone-… Spencer Dawkins
- Re: [martini] Proposed worksplit:tackletelephone-… Eric Burger
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] the MARTINI conundrum Bernard Aboba
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Bernard Aboba
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackletelephon… DOLLY, MARTIN C (ATTLABS)
- Re: [martini] Proposed work split: tackletelephon… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Hadriel Kaplan
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Culling tel URIs Adam Roach
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split: tackle telepho… Richard Shockey
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- [martini] Culling tel URIs (was: Re: Proposed wor… Spencer Dawkins
- Re: [martini] Culling tel URIs Richard Shockey
- Re: [martini] Proposed work split: tackletelephon… Richard Shockey
- Re: [martini] Culling tel URIs Spencer Dawkins
- Re: [martini] Culling tel URIs Paul Kyzivat
- Re: [martini] Culling tel URIs Adam Roach
- Re: [martini] Culling tel URIs Spencer Dawkins
- Re: [martini] Culling tel URIs Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Paul Kyzivat
- Re: [martini] Proposed work split: tackle telepho… Christer Holmberg
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Dean Willis
- Re: [martini] Culling tel URIs (was: Re: Proposed… Dean Willis
- Re: [martini] Culling tel URIs Dean Willis
- Re: [martini] Proposed work split: tackletelephon… Dean Willis
- Re: [martini] Culling tel URIs Dean Willis
- Re: [martini] Culling tel URIs Dean Willis
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Culling tel URIs (was: Re: Proposed… Spencer Dawkins
- Re: [martini] Proposed work split: tackle telepho… DRAGE, Keith (Keith)
- Re: [martini] Culling tel URIs Paul Kyzivat
- Re: [martini] Culling tel URIs Adam Roach
- Re: [martini] Culling tel URIs Spencer Dawkins
- Re: [martini] Proposed work split: tackletelephon… Richard Shockey
- Re: [martini] Proposed work split: tackle telepho… Elwell, John
- Re: [martini] Proposed work split:tackle telephon… Richard Shockey