Received: from ietf.org by ietf.org id aa26390; 1 May 97 15:10 EDT Received: from cnri by ietf.org id aa26271; 1 May 97 15:09 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10359; 1 May 97 15:09 EDT Received: from mailer.dir.org by venera.isi.edu (5.65c/5.61+local-27) id ; Thu, 1 May 1997 12:05:46 -0700 Received: from CISPPP by mailer.dir.org (8.6.12/8.6.9) with SMTP id NAA00450; Thu, 1 May 1997 13:39:20 -0400 Message-Id: <3368F0A6.41AF@dir.org> Date: Thu, 01 May 1997 15:36:06 -0400 Sender:ietf-request@ietf.org From: Press Office Reply-To: press@dir.org Organization: Directory Corporation X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: iar@helix.xiii.com, ibb@boursy.news.erols.com, ibm@svpal.svpal.org, ic1@fdma.fdma.com, icd@ionews.ionet.net, icm@news1.iamerica.net, id7@twwells.com, ietf@isi.edu, if3@chronicle.concentric.net, iff@grog.ric.edu, ifg@chronicle.concentric.net, igeldard@capital.demon.co.uk, ihi@natasha.rmii.com, iiiybrmahzewso@harding.demon.co.uk, iimagine@onramp.net, ik2@murrow.corp.sgi.com, il@taunivm.tau.ac.il, ilu@twwells.com, ima@twwells.com, imalunatic@the.aslyum, in@individual.net, inezewcm@ferjani.demon.co.uk, inf@iname.com, inkygrr@airmail.net, inoctavo@mail.dotcom.fr, interest@relay.sgi.com, internet@munnari.oz.au, ion@pacbell.net, ip3spwauwqkzewhj@harding.demon.co.uk, ipf@newsops.execpc.com, ipsnake@redline.ru, ir0@geolabserver.geo, irelandurby1_7m8@maestro.clari.net Subject: Directory Corporation signs IAHC gTLD Geneva, May 1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Source-Info: From (or Sender) name not authenticated. YOUR READERS ARE INVITED TO JOIN THE CONTACTS DIRECTORY AT _NO_ CHARGE The Directory Corporation is pleased to support proposals to expand the global Top Level Domain Space. Since the inception of the IAHC, officers from this organization have participated in some of the many discussions, which have now been concluded in this Memorandum of Understanding. Mr John Harvey, Director of Online Information Services said "This proposal to allows competing companies to register in Generic Top Level Internet Domain names other than ".COM". The IAHC has moved quickly to address the issues of expanding the Name Space and has formulated this workable solution based on policies supported by internationally recognized institutions. To assist end-users identify the web sites of Domain Name owners in the "expanded" DNS, it is important for customers to be able to use non-discriminatory listing facilities, such as ours, as a "bridge" between the various competing operators, domains and registries. Like an internet phonebook accessible to all, the Contacts Directory (http://www.dir.org) enables end-users to search for Email and web addresses as well as fax, cellular, satellite, mobile, videoconferencing telephone numbers for companies and individuals, at work and home. The facility is free to search and Telcos and ISPs are charged a nominal fee for their customers who submit details to the service. From the operators perspective additional call revenue is generated and customer satisfaction increased. All ISPs and their customers are invited to use this world unique facility. End users are in complete control of their communications accessibility. They enter their own details to provide up-to-the-minute accuracy and the level of privacy desired. As at April 28, the Contacts Directory had received 741,039 voluntary entries. All companies and individulas connectged to the Internet may submit their details for publication in the Contacts Directory, free to end-users. As a promotional offer, Telcos and ISPs will not be charged until 1 million entries have been received. Who is the Directory Corporation? The Directory Corporation is a non-profit making international organization, based in the Commonwealth of the Bahamas. As a developing economy unattached to any of the main trading blocks, the Bahamas provides an impartial environment in which to promote the non-discriminatory exchange of information whilst having excellent communication links with the North America, Europe and the Far East. Questions may be addressed to John Harvey (John.Harvey@DIR.org) and additional information is available from the Press Office (press@dir.org). The Directory Corporation. Street Address: Universal House, Elizabeth Avenue, Nassau. Bahamas. Postal Address: P.O. Box N-3401 Fax:+1242 326 4105 Email: Press@dir.org   Received: from ietf.org by ietf.org id aa22845; 5 May 97 12:48 EDT Received: from cnri by ietf.org id aa22731; 5 May 97 12:44 EDT Received: from comsun.comm.utoronto.ca by CNRI.Reston.VA.US id aa14308; 5 May 97 12:44 EDT Received: by comsun.comm.toronto.edu id <33833>; Mon, 5 May 1997 12:38:23 -0400 Sender:ietf-request@ietf.org From: Irene Katzela To: enternet@bbn.com, cnom@maestro.bellcore.com, comsoc.bog@tab.ieee.org, sigmedia@bellcore.com, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, testnet@canarie.ca, ietf@CNRI.Reston.VA.US, itc@fokus.gmd.de, comsoc-tcii@ieee.com, dbworld@cs.wisc.edu, ieeetcpc@ccvm.sunysb.edu, comsoc-chapter@ieee.org Subject: Call for Papers - MC2R ,3rd Issue REMINDER!!! Cc: irene@comm.toronto.edu Content-Type: X-sun-attachment Message-Id: <97May5.123823edt.33833@comsun.comm.toronto.edu> Date: Mon, 5 May 1997 12:37:37 -0400 Source-Info: From (or Sender) name not authenticated. ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 121 I apologize if you receive this mail more than once. *********************************************************************** CALL FOR PAPERS (3rd Issue) Mobile Computing and Communications Review (A publication of the ACM SIGMOBILE society) with guest editor Irene Katzela University of Toronto Canada PUBLICATION PURPOSE The wireless communication revolution is bringing fundamental changes to telecommunication and computing. Wide-area cellular systems and wireless LANs promise to make integrated networks a reality and provide fully distributed and ubiquitous mobile computing and communications, thus bringing an end to the tyranny of geography. Furthermore, services for the mobile user are maturing and are poised to change the nature and scope of communication. This publication serves to enhance the ability of ACM SIGMOBILE members to keep up-to-date in this rapidly moving field, as well as serve as a major focal point for the discussion of new directions of portable computation and mobile networks for both the research and market-driven communities. TOPICS Technical papers describing original research are solicited on topics at the link layer and above. Topics will include, but are not limited to: - Network management and control for wireless and mobile networks: network management architectures and planning; signalling, routing, and handoff management; resource allocation; mobile tracking and location - Integration of wired and wireless networks: internetworking and interoperability issues; service integration - Protocols to cope with mobility, limited bandwidth, or intermittent connectivity. - Wireless networking standards - Future trends in mobile and wireless networks, economic and business impact - Multimedia and wireless: support for multimedia applications over wireless; multimedia services and mobility; design of multimedia wireless terminals - ATM and wireless: Wireless ATM LANs; integrated services and wireless ATM. - Security and reliability issues for mobile/wireless systems HOW TO SUBMIT Paper submission will be handled electronically. Authors should Email a PostScript version of their full paper to: editors@bcn.bu.edu Detailed submission instructions can be found on the MC2R web page: http://bcn.bu.edu/MC2R SUBMISSION DUE : May 15, 1997 NOTIFICATION OF ACCEPTANCE: July 15, 1997 FOR MORE INFORMATION Please contact Irene Katzela at irene@comm.utoronto.ca, or the editors of MC2R at editors@bcn.bu.edu GUEST EDITOR EDITOR-IN-CHIEF Irene Katzela Victor Bahl University of Toronto, ECE Digital Equipment Corporation 10 King's College Road 110 Spitbrook Road, ZK1-1/E37 GB204, Toronto, Ontario Corporate Research M5S 3G4, Canada Nashua, NH 03062-2698, USA Tel: 416 946 312 Tel: (603) 881-2321 Fax: 416 971 3020 Fax: (603) 881-0585 e-mail: irene@comm.utoronto.edu email: bahl@samson.enet.dec.com ASSOCIATE EDITOR ASSOCIATE EDITOR Charles Perkins (IBM) Jason Redi (BCN) **************************************************************************** ----- End Included Message ----- ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: sigm.txt X-Sun-Content-Lines: 111 X-Sun-Charset: us-ascii *********************************************************************** CALL FOR PAPERS (3rd Issue) Mobile Computing and Communications Review (A publication of the ACM SIGMOBILE society) with guest editor Irene Katzela University of Toronto Canada PUBLICATION PURPOSE The wireless communication revolution is bringing fundamental changes to telecommunication and computing. Wide-area cellular systems and wireless LANs promise to make integrated networks a reality and provide fully distributed and ubiquitous mobile computing and communications, thus bringing an end to the tyranny of geography. Furthermore, services for the mobile user are maturing and are poised to change the nature and scope of communication. This publication serves to enhance the ability of ACM SIGMOBILE members to keep up-to-date in this rapidly moving field, as well as serve as a major focal point for the discussion of new directions of portable computation and mobile networks for both the research and market-driven communities. TOPICS Technical papers describing original research are solicited on topics at the link layer and above. Topics will include, but are not limited to: - Network management and control for wireless and mobile networks: network management architectures and planning; signalling, routing, and handoff management; resource allocation; mobile tracking and location - Integration of wired and wireless networks: internetworking and interoperability issues; service integration - Protocols to cope with mobility, limited bandwidth, or intermittent connectivity. - Wireless networking standards - Future trends in mobile and wireless networks, economic and business impact - Multimedia and wireless: support for multimedia applications over wireless; multimedia services and mobility; design of multimedia wireless terminals - ATM and wireless: Wireless ATM LANs; integrated services and wireless ATM. - Security and reliability issues for mobile/wireless systems HOW TO SUBMIT Paper submission will be handled electronically. Authors should Email a PostScript version of their full paper to: editors@bcn.bu.edu Detailed submission instructions can be found on the MC2R web page: http://bcn.bu.edu/MC2R SUBMISSION DUE : May 15, 1997 NOTIFICATION OF ACCEPTANCE: July 15, 1997 FOR MORE INFORMATION Please contact Irene Katzela at irene@comm.utoronto.ca, or the editors of MC2R at editors@bcn.bu.edu GUEST EDITOR EDITOR-IN-CHIEF Irene Katzela Victor Bahl University of Toronto, ECE Digital Equipment Corporation 10 King's College Road 110 Spitbrook Road, ZK1-1/E37 GB204, Toronto, Ontario Corporate Research M5S 3G4, Canada Nashua, NH 03062-2698, USA Tel: 416 946 312 Tel: (603) 881-2321 Fax: 416 971 3020 Fax: (603) 881-0585 e-mail: irene@comm.utoronto.edu email: bahl@samson.enet.dec.com ASSOCIATE EDITOR ASSOCIATE EDITOR Charles Perkins (IBM) Jason Redi (BCN) ****************************************************************************   Received: from cnri by ietf.org id aa01555; 7 May 97 11:34 EDT Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa12950; 7 May 97 11:34 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA05723 for ; Wed, 7 May 1997 11:30:21 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 May 1997 11:22:54 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA04966 for ipp-outgoing; Wed, 7 May 1997 11:16:41 -0400 (EDT) Message-Id: <01BC5AD8.4059E440@PZEHLER.ocp.mc.xerox.com> From: Peter Zehler To: 'IPP Redirector' Subject: RE: IPP> Re: MOD - RE: Base printer implementation requirements Date: Wed, 7 May 1997 08:15:42 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org All, From Jay's and Scott's conversation. ____________ JKM> As far as deriving base constraints goes, to me the real question = is: JKM> JKM> Must an "IPP Printer" must be able spool print jobs? JKM> I would like to see an answer of "Yes", but clearly this is where = desktop JKM> printers (and many, if not most, network printers) fail to perform. = And I JKM> believe this is usually the reasons behind most case of "we can't = do that JKM> due to printer limitations." SAI>I fail to see why a "yes" answer matters? If someone decides to = implement SAI>IPP in a printer that can not spool, what changes? If it is too = busy SAI>processing one job and another comes in from another client, it = returns a SAI>"busy" or a "out of spool space" just as in the case where a server SAI>implementation supports 2000 spooled jobs and the 2001st job comes = in. =20 SAI>Will anybody implement IPP in a printer like this? Probably not. = Does the SAI>model preclude them from doing so? No. Will this type of printer = ever be SAI>used as as a shared network printer? Probaly not, but if it is, and = it does SAI>not embed IPP then it can be front ended by a "server" that does. __________ PJZ: I have been listening. I am prototyping IPP on a printer that can only = accept and process a job at a time. I chose this printer specifically = to check the lower bounds of an IPP implementation. I have to agree = with Scott. Spooling is not the printer feature that determines if a = printer is capable of supporting IPP. IPP will be sitting (somewhere) = on top of TCP. The flow control capabilities of this layer of the = protocol should allow me to gate the inflow of PDL data while the = printer "catches up" with the PDL stream. I also have the job-k-octets = to limit the job size for a low-end printer. =20 This class of printer will not be IPP feature rich. The printer itself = will not be feature rich. It is true some clients will be denied = service while the printer is busy. All services must handle the = "capacity + 1" problem. IPP seems to handle this problem. There is = still the issue for the application to determine when it should time = out. IPP level print job submission operations should help accomodate = application level timeout detection. We will have to see where the = print operation semantics discussion ends up. Will this type of printer be used as as a shared network printer? Yes = it can, if the workload is low enough. If IPP service is not available = often enough for the site's needs, an IPP spooler can be put between the = client and the printer. A bigger printer could also be used. The factor that will determine if a printer can be IPP compliant will be = the complexity of IPP, IPP conformance specification, and the available = printer resources that are available for IPP. _________________________________ Pete = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 = =20 =20   Received: from cnri by ietf.org id aa06338; 7 May 97 15:01 EDT Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa17701; 7 May 97 15:01 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA09244 for ; Wed, 7 May 1997 14:57:33 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 7 May 1997 14:54:33 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA08838 for ipp-outgoing; Wed, 7 May 1997 14:50:57 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 7 May 1997 14:55:45 -0400 Message-ID: <00014604.1337@digprod.com> From: Bill Wagner Subject: Re[2]: IPP> Re: MOD - RE: Base printer implementation requir To: 'IPP Redirector' Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: ipp-owner@pwg.org In theory, at least, any spooler can be sent a job larger than it can store (at least at the time). Therefore, unless the model provides for identifying the total job size before starting transmission, it would be possible that even a "spooling printer" would have to consume some portion of the job before being able to accept the entire job. Therefore, as has been suggested, a 'non-spooling' printer can be considered as one providing very limited spooling capacity. But the message exchange seems to have avoided addressing the basic statement that prompted Jay's request that only spooling printers (or servers) be considered. Harald had asked: "Does the IPP print model have to include the possibility of the first portion of the document being printed before the request is completely sent to the printer?" Tom's response (in part) was: "We want to allow IPP to be implemented in a printer that doesn't have to spool the data before starting to print. In other words, we want to allow IPP to be used by simple desktop printers. Unfortunately, this does require that resources be declared up front, not at the end." Although I happen to agree with Tom, and understood this to be an IPP objective, perhaps it is not the proper answer to Harald's question. Perhaps, the 'loaded' terms in the answer (desktop, sooler) distracted us from the question. I therefore would like to resubmit the question to see if there is consensus to to whether: "the IPP print model [must] include the possibility of the first portion of the document being printed before the request is completely sent to the printer?". Bill Wagner, Osicom/DPI   Received: from cnri by ietf.org id aa11746; 9 May 97 15:09 EDT Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa19050; 9 May 97 15:09 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id PAA03502 for ; Fri, 9 May 1997 15:05:19 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Fri, 9 May 1997 15:01:15 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA02983 for ipp-outgoing; Fri, 9 May 1997 14:57:39 -0400 (EDT) Message-Id: <01BC5C83.1C5A91A0@PZEHLER.ocp.mc.xerox.com> From: Peter Zehler To: 'IPP Redirector' Cc: 'Carl-Uno Manros' Subject: IPP> TES> Prototype Status Date: Fri, 9 May 1997 11:11:19 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: ipp-owner@pwg.org All, I've noticed that I have a time slot to report on the state of the = prototype group at the San Diego meeting. I've made a few phone calls = to try and get some idea of what should be reported. Everyone I talk to = seems to agree. The status is: "what do you mean?" The prototype and testing group has nothing to test or prototype until = there is a concrete proposal for the object model and protocol. = Everyone I have talked to still intends to build a prototype. Time = estimates would just be a shot in the dark at this time. The range I = got was from 1 to 3 months. I was curious about the various companies capacity to contribute to any = proof of concept or architectural verification work that might be needed = by the IPP group. The lukewarm answers was that we might be able to = take on something. The specific response was a request for = clarification of the proof of concept work. As of yet the TES group has not been asked to do anything specific. If = I have missed something I would like to know about it. =20 I have asked some basic questions about the capacity of the TES group to = respond to any requests from the other IPP subgroups.=20 1) What resources are available to work on proof of concept work? The = answer to this question really depends on the task at hand and the = expertise of the people available. This will have to be answered as = issues are passed onto the TES group. 2) What is your capacity to produce a prototype? I was curious here = about how long after the specification of IPP will we be ready to show = something. The answer here depends on where IPP ends up. The common = answer was from 1 to 3 months. The prototypes range from embedding IPP = in a low-end network printer to a gateway to a full blown DPA like print = system. My questions to the group and its chairs: Is there anything specific = you need to know? Are there any general areas that you need explored? By the way...the TES group has no open issues at this time. Then again = it has no closed issues either. Pete   Received: from cnri by ietf.org id aa01548; 12 May 97 7:35 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa07296; 12 May 97 7:35 EDT Received: from ietf.org by ietf.org id aa01541; 12 May 97 7:35 EDT Received: from aun.uninett.no by ietf.org id aa01537; 12 May 97 7:35 EDT Received: from dale.uninett.no (actually jenc8-103.publab.ed.ac.uk) by aun.uninett.no with SMTP (PP); Mon, 12 May 1997 13:30:50 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id MAA20578; Mon, 12 May 1997 12:04:12 +0200 Sender:iesg-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Subject: Transaction protocol WG charter MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <20573.863431441.0@dale.uninett.no> Date: Mon, 12 May 1997 12:04:11 +0200 Message-ID: <20576.863431451@dale.uninett.no> X-Orig-Sender: hta@dale.uninett.no ------- =_aaaaaaaaaa0 Content-type: text/plain; charset="us-ascii" Content-ID: <20573.863431441.1@dale.uninett.no> This is a political issue; Oracle seems to attack this because it's got Microsoft pushing it. The veichle for attack is the OMG. OMG's suggestion is to make use of OMG CORBA instead, once that is proposed to the IETF for publishing as IETF standard. I'd like to have comments on this suggested charter. Steve: This is NOT placing it on the IESG agenda for approval. Harald A ------- =_aaaaaaaaaa0 Content-type: text/plain; charset="us-ascii" Content-ID: <20573.863431441.2@dale.uninett.no> Transaction Internet Protocol (TIP) Charter =========================================== Chair(s) -------- Keith Evans Jim Lyon Applications Area Director(s) ----------------------------- Keith Moore Harald Alvestrand Area Advisor ------------ Harald Alvestrand Mailing List Information ------------------------ General Discussion: To Subscribe: in message body: "subscribe tip" Description of Working Group ---------------------------- The task of the TIP working group is to develop an Internet standard two-phase commit protocol specification, to enable heterogeneous Transaction Managers to agree on the outcome of a distributed transaction. In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed (committed or aborted), even in the face of failures. This behaviour is achieved via the use of distributed transactions, employing a two-phase commit protocol (2-pc). The use of distributed transactions greatly simplifies distributed applications programming, since the number of possible outcomes is reduced from many to two, and failure recovery is performed automatically by the transaction service (Transaction Manager). Key requirements to be met are, 1) the 2-pc protocol be independent of the application-to-application communications protocol, such that it may be used with any application protocol (especially HTTP), and 2) the 2-pc protocol be simple to implement and have a small working footprint (to encourage ubiquitous implementation and offer wide applicability). The Internet-Draft document is to be used as the input base document for the development of this 2-pc protocol specification. [Note that since references a modified version of the Session Control Protocol (SCP), the TIP WG will also be responsible for progression of SCP to Proposed Internet Standard.] Goals and Milestones -------------------- Dec 1996 First version of TIP submitted as an Internet-Draft. Feb 7 1997 Second version of TIP submitted as an Internet-Draft. April 9 1997 First TIP BOF meeting held at Memphis IETF. May 1 1997 Submit new version of Session Control Protocol (SCP) as an Internet-Draft. Call for participants in TIP WG (this and subsequent dates slip correspondingly if the IETF does not announce the TIP WG by May 1 1997). Solicit comments re Feb 7 TIP I-D and May 1 SCP I-D (via TIP e-mail list). June 1 1997 Cut-off for comments re Feb 7 TIP I-D and May 1 SCP I-D. July 1 1997 All comments re Feb 7 TIP I-D and May 1 SCP I-D resolved, changes agreed (via TIP e-mail list). Submit new TIP I-D and SCP I-D. July 21 1997 Cut-off for comments re July 1 TIP I-D and SCP I-D. Aug 1 1997 All comments re July 1 TIP I-D and SCP I-D resolved, changes agreed (via TIP e-mail list). Submit new TIP I-D and SCP I-D. Aug 12 1997 Hold TIP WG meeting at Munich IETF: review Aug 1 TIP I-D and SCP I-D; close on any further changes; submit final version of TIP and SCP to the IESG for consideration as Proposed Internet Standards. Current Internet-Drafts ----------------------- Transaction Internet Protocol (ftp://ds.internic.net/internet-drafts/draft-lyon-itp-nodes-01.txt) Session Control Protocol (ftp://ds.internic.net/internet-drafts/draft-evans-v2-scp-00.txt) ------- =_aaaaaaaaaa0--   Received: from cnri by ietf.org id aa02444; 12 May 97 8:42 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa08262; 12 May 97 8:42 EDT Received: from ietf.org by ietf.org id aa02437; 12 May 97 8:42 EDT Received: from ns.jck.com by ietf.org id aa02431; 12 May 97 8:42 EDT Received: from tp7.Jck.com ("port 4445"@tp7.jck.com) by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EA2J515D00KQF@a4.jck.com> for iesg@ietf.org; Mon, 12 May 1997 08:39:02 -0400 (EDT) Date: Mon, 12 May 1997 08:38:55 -0400 (EDT) Sender:iesg-request@ietf.org From: John C Klensin Subject: Re: Transaction protocol WG charter In-reply-to: <20576.863431451@dale.uninett.no> To: Harald.T.Alvestrand@uninett.no Cc: directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.1 Build (14) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Priority: NORMAL X-Authentication: none On Mon, 12 May 1997 12:04:11 +0200 Harald.T.Alvestrand@uninett.no wrote: > This is a political issue; Oracle seems to attack this because > it's got Microsoft pushing it. > The veichle for attack is the OMG. > OMG's suggestion is to make use of OMG CORBA instead, once > that is proposed to the IETF for publishing as IETF standard. Sure. The day after OMG releases change control and gives permission for zero-royalty publishing, each of which they have, twice already, refused to consider. They are happy to have us "endorse", as they have gotten others to do. Wrt the charter: this stuff is complex, and it is not clear that IETF has adequate competence. Especially given that fact, the schedule is not consistent with serious review and input (although it may be consistent with railroading something through). john   Received: from cnri by ietf.org id aa06341; 12 May 97 11:10 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa10907; 12 May 97 11:10 EDT Received: from ietf.org by ietf.org id aa06332; 12 May 97 11:10 EDT Received: from ng.netgate.net by ietf.org id aa06328; 12 May 97 11:10 EDT Received: from [205.214.160.40] (d3.netgate.net [205.214.160.35]) by ng.netgate.net (8.8.5/8.8.5) with ESMTP id IAA26315; Mon, 12 May 1997 08:17:24 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <20576.863431451@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 May 1997 08:06:27 -0700 To: Harald.T.Alvestrand@uninett.no Sender:iesg-request@ietf.org From: Dave Crocker Subject: Re: Transaction protocol WG charter Cc: directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu At 3:04 AM -0700 5/12/97, Harald.T.Alvestrand@uninett.no wrote: >This is a political issue; Oracle seems to attack this because >it's got Microsoft pushing it. Then remove Microsoft from a chair position. Nothing personal (not at all), but when a potential chair engenders significant political concern, the history has been to find a different chair. It keeps things squeakier clean. Besides being political, this is a difficult topic. It needs a reasonably neutral, highly competent content expert and an IETF process person (previously chaired a working group of some complexity) for co-chairs. >The veichle for attack is the OMG. As John K. notes, OMG has chosen to be a non-starter. >The Internet-Draft document is to be used >as the input base document for the development of this 2-pc protocol >specification. [Note that since references >a modified version of the Session Control Protocol (SCP), the TIP WG >will also be responsible for progression of SCP to Proposed Internet >Standard.] I don't recall SCP being worked on in the IETF, yet it's being mentioned here almost as a throw-away. Is it not, also, a significant piece of work? >Goals and Milestones John was too polite about the dates. They are simply unrealistic. We sometimes charter working groups that are specifically intended to take a single, existing spec to standardization. We charter other working groups to look at a topic and develop a specification. If this is the former, it should say so in the working group name and in the first paragraph of the summary statement. If it is the latter, it should have some text about considering a range of design trade-offs (blah blah blah) and it should have a MUCH longer schedule. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from cnri by ietf.org id aa07840; 12 May 97 12:07 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa12000; 12 May 97 12:08 EDT Received: from ietf.org by ietf.org id aa07833; 12 May 97 12:07 EDT Received: from mail2.digital.com by ietf.org id aa07829; 12 May 97 12:07 EDT Received: from pachyderm.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA26818; Mon, 12 May 1997 08:52:09 -0700 Received: by pachyderm.pa.dec.com; id AA02101; Mon, 12 May 1997 08:52:49 -0700 Date: Mon, 12 May 1997 08:52:49 -0700 Sender:iesg-request@ietf.org From: Jim Gettys Message-Id: <9705121552.AA02101@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client tunsrv2-tunnel.imc.das.dec.com) To: Dave Crocker Cc: Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu In-Reply-To: Subject: Re: Transaction protocol WG charter I think we are being biased if a Microsoft person can NEVER be a chair. There are several Microsoft people I would trust as WG chairs. I think it should depend on the particular person involved, and their (known) integrity. A good co-chair, to handle any conflict of interest cases, should be appointed in such situations. I have no knowledge of the specific Microsoft person being proposed, and therefore have no opinion in this specific case. SCP is (an evolution of) Simon Spero's SCP (session control protocol) for his HTTP-NG design. Its intent is to allow multiplexing multiple connections over a single TCP connection. I looked at it a while back and had some problems with it and designed a derivative what I call SMUX (simple multiplexing protocol), which has been implemented several times (in ILU and in Jigsaw (and which I owe another revision of the specification; I've had bronchitis since IETF). There are still some outstanding issues for either SCP or SMUX around flow control that I consider unresolved. It would be nice to end up with one application multiplexing protocol, rather than two here. I hope to get back to SMUX in the next month or two, if I can get caught up on my work and meet my HTTP/1.1 commitments. I've been reluctant to push SMUX on people until I believe fully in its design in working code and with performance data. (I believe in numbers, as some of you may be aware.) I haven't looked at this updated SCP specification, so don't know anything about it. See: http://www.w3.org/pub/WWW/Protocols/MUX/WD-mux-961023.html for my latest MUX draft. - Jim Gettys   Received: from cnri by ietf.org id aa15239; 12 May 97 15:35 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa16751; 12 May 97 15:35 EDT Received: from ietf.org by ietf.org id aa15213; 12 May 97 15:35 EDT Received: from ng.netgate.net by ietf.org id aa15207; 12 May 97 15:35 EDT Received: from [205.214.160.77] (d43.netgate.net [205.214.160.77]) by ng.netgate.net (8.8.5/8.8.5) with ESMTP id MAA18754; Mon, 12 May 1997 12:41:38 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <9705121552.AA02101@pachyderm.pa.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 May 1997 11:56:58 -0700 To: Jim Gettys Sender:iesg-request@ietf.org From: Dave Crocker Subject: Re: Transaction protocol WG charter Cc: Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu At 8:52 AM -0700 5/12/97, Jim Gettys wrote: >I think we are being biased if a Microsoft person can NEVER be a chair. Whoa! *I* certainly never said such a thing. I was reacting to the assessment that this is perceived as something Microsoft is pushing. Now, one might argue that Microsoft is likely to always have such assertions being made and, ergo, your conclusion comes into effect, but these should be evaluated case-wise (which is, I think, what you are saying too.) >SCP is (an evolution of) Simon Spero's SCP (session control protocol) for h= is >HTTP-NG design. Its intent is to allow multiplexing multiple connections >over a single TCP connection. How does it compare, in terms of complexity and overhead, with TMUX, which multiplexes multiple TCP connections over one IP datagram? The point behind such a question is that TCP creates connections. If we lay on top of that something which also creates connections, the question becomes "why"? It tends to lead to redundant mechanism and we all know how awful such an eventuality is. (Truth in labeling: I created TMUX so I'm fully biased, but I don't think that renders my question inappropriate.) >revision of the specification; I've had bronchitis since IETF). There are >still some outstanding issues for either SCP or SMUX around flow control Flow control was one of the big wins for TMUX. No problem at all. >(I believe in numbers, as some of you may be aware.) I haven't looked at >this updated SCP specification, so don't know anything about it. Sounds like SCP is not a slam dunk and it sounds like it needs separate and narrow attention. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from cnri by ietf.org id aa15825; 12 May 97 15:53 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa17073; 12 May 97 15:53 EDT Received: from ietf.org by ietf.org id aa15816; 12 May 97 15:53 EDT Received: from mailhost.ipsilon.com by ietf.org id aa15812; 12 May 97 15:53 EDT Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id MAA07891; Mon, 12 May 1997 12:49:43 -0700 Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id MAA00619; Mon, 12 May 1997 12:50:28 -0700 Message-Id: <199705121950.MAA00619@red.ipsilon.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Dave Crocker cc: Jim Gettys , Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Subject: Re: Transaction protocol WG charter In-reply-to: Your message of "Mon, 12 May 1997 11:56:58 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 May 1997 12:50:28 -0700 Sender:iesg-request@ietf.org From: Greg Minshall Such a distinguished audience! Dcrocker said: > Sounds like SCP is not a slam dunk and it sounds like it needs > separate and narrow attention. I agree with this. I looked at SCP a while back, and the flow control issues (in particular) worry me a lot. Greg   Received: from cnri by ietf.org id aa16032; 12 May 97 16:00 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa17188; 12 May 97 16:00 EDT Received: from ietf.org by ietf.org id aa16025; 12 May 97 16:00 EDT Received: from mailhost.ipsilon.com by ietf.org id aa16021; 12 May 97 16:00 EDT Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id MAA08188; Mon, 12 May 1997 12:56:42 -0700 Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id MAA00641; Mon, 12 May 1997 12:57:02 -0700 Message-Id: <199705121957.MAA00641@red.ipsilon.com> X-Mailer: exmh version 1.6.9 8/22/96 To: John C Klensin cc: Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Subject: Re: Transaction protocol WG charter In-reply-to: Your message of "Mon, 12 May 1997 08:38:55 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 May 1997 12:57:02 -0700 Sender:iesg-request@ietf.org From: Greg Minshall Ahh, one other comment. John K said: > Wrt the charter: this stuff is complex, and it is not clear that > IETF has adequate competence. Again, i agree, though i don't really know what to do about that fact. We (the IETF) are being pushed in lots of areas. We can either be "pure-ist" (my tendency, surely) by saying "whoa there, nelly, slow down -- we need to work on things that are in our core competence, and do a thorough job on each", or we can "go with the flow". The real danger of the former approach is that we run the risk of being marginalized. I.e., if we say "no" to lots of things, people will quit asking us, and then we won't even get the *chance* to say "no". (One solution might be to punt TIP to the IRTF? Here, the "research" portion is the *IETF* researching "what do you mean by 2pc, etc.?", i.e., developing sufficient expertise, both "in the ranks" as well as in the leadership [IESG, etc.], in order to do "justice" to such an effort.) The danger of the "go with the flow" approach is losing any semblance of quality in our "product line". Sigh. Greg   Received: from cnri by ietf.org id aa16114; 12 May 97 16:02 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa17255; 12 May 97 16:02 EDT Received: from ietf.org by ietf.org id aa16105; 12 May 97 16:02 EDT Received: from mail1.digital.com by ietf.org id aa16100; 12 May 97 16:02 EDT Received: from pachyderm.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA06584; Mon, 12 May 1997 12:52:14 -0700 Received: by pachyderm.pa.dec.com; id AA18156; Mon, 12 May 1997 12:52:54 -0700 Date: Mon, 12 May 1997 12:52:54 -0700 Sender:iesg-request@ietf.org From: Jim Gettys Message-Id: <9705121952.AA18156@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client tunsrv2-tunnel.imc.das.dec.com) To: Dave Crocker Cc: Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu In-Reply-To: Subject: Re: Transaction protocol WG charter The logical conclusion of the current Microsoft almost monopoly is that they are always concerned with almost anything anyone does.... I think the real issue should be the particular person involved from Microsoft, and who a co-chair is. The other major issue is whether the really good transactions people will be participating; I gather from conversations in Digital that the Microsoft person proposed to chair has very good TP credentials. As far as TMUX, it has been approaching 18 months since I looked at it (if it is what I remember looking at). If you send me a copy, I'll try to refresh my memory. You can also look at SCP or SMUX to get an idea of what they are intended for. My memory (if TMUX is what I remember) that there were very good reasons it wouldn't be useful for the intended purposes. Among other things, the requirement is to run over existing TCP stacks, and NOT to generate independent segments on the wire when switching from one multiplexed stream to another. - Jim   Received: from cnri by ietf.org id aa16836; 12 May 97 16:25 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa17631; 12 May 97 16:25 EDT Received: from ietf.org by ietf.org id aa16828; 12 May 97 16:25 EDT Received: from zippy.psc.edu by ietf.org id aa16824; 12 May 97 16:25 EDT Received: (from mathis@localhost) by zippy.psc.edu (8.8.5/8.8.2) id QAA06206; Mon, 12 May 1997 16:21:13 -0400 (EDT) Date: Mon, 12 May 1997 16:21:13 -0400 (EDT) Message-Id: <199705122021.QAA06206@zippy.psc.edu> Sender:iesg-request@ietf.org From: Matt Mathis To: Dave Crocker Cc: directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu In-reply-to: Dave Crocker's message of Mon, 12 May 1997 11:56:58 -0700 Subject: Re: Transaction protocol WG charter Reply-to: mathis@psc.edu References: > Flow control was one of the big wins for TMUX. No problem at all. True, but TMUX implementations can trash congestion control in the same manner as http 1.0 implementations. This may be a critical point - If you multiplex below transport (e.g. multiple instantiations of transport state), then flow control is "easy" and congestion control is "hard". Witness http 1.0 and TMUX. If you multiplex above transport (e.g. one instantiation of transport state), then congestion control is "easy" and flow control is "hard". Witness SMUX and SCP. Both models have their place. Both models have problems. --MM--   Received: from cnri by ietf.org id aa16949; 12 May 97 16:29 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa17716; 12 May 97 16:29 EDT Received: from ietf.org by ietf.org id aa16942; 12 May 97 16:29 EDT Received: from mail3.microsoft.com by ietf.org id aa16938; 12 May 97 16:29 EDT Received: by INET-03-IMC with Internet Mail Service (5.0.1458.30) id ; Mon, 12 May 1997 13:27:14 -0700 Message-ID: Sender:iesg-request@ietf.org From: Chris Weider To: "'jg@pa.dec.com'" , Dave Crocker Cc: Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Subject: RE: Transaction protocol WG charter Date: Mon, 12 May 1997 13:25:53 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) I agree with this; it should be done on a case-by-case basis. I mean, I'd like to be able to chair working groups too :^). I don't know the transactions people personally so I can't comment on their expertise. I do think that the timeline is way too aggressive. Chris > -----Original Message----- > From: jg@pa.dec.com [SMTP:jg@pa.dec.com] > Sent: Monday, May 12, 1997 12:53 PM > To: Dave Crocker > Cc: Harald.T.Alvestrand@uninett.no; directorate@apps.ietf.org; > iesg@ietf.org; trans-area@isi.edu > Subject: Re: Transaction protocol WG charter > > The logical conclusion of the current Microsoft almost monopoly is > that > they are always concerned with almost anything anyone does.... I > think > the real issue should be the particular person involved from > Microsoft, > and who a co-chair is. > > The other major issue is whether the really good transactions people > will be participating; I gather from conversations in Digital that the > Microsoft person proposed to chair has very good TP credentials. > > As far as TMUX, it has been approaching 18 months since I looked at it > (if it is what I remember looking at). If you send me a copy, I'll > try > to refresh my memory. You can also look at SCP or SMUX to get an idea > of what they are intended for. My memory (if TMUX is what I remember) > that > there were very good reasons it wouldn't be useful for the intended > purposes. > > Among other things, the requirement is to run over existing TCP > stacks, > and NOT to generate independent segments on the wire when switching > from > one multiplexed stream to another. > - Jim   Received: from cnri by ietf.org id aa11474; 13 May 97 4:10 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa04553; 13 May 97 4:10 EDT Received: from ietf.org by ietf.org id aa11465; 13 May 97 4:10 EDT Received: from aun.uninett.no by ietf.org id aa11461; 13 May 97 4:10 EDT Received: from dale.uninett.no (actually jenc8-t100.publab.ed.ac.uk) by aun.uninett.no with SMTP (PP); Tue, 13 May 1997 10:06:50 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id TAA02395; Mon, 12 May 1997 19:22:42 +0200 Sender:iesg-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: John C Klensin cc: directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Subject: Re: Transaction protocol WG charter In-reply-to: Your message of "Mon, 12 May 1997 08:38:55 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2391.863457762.1@dale.uninett.no> Date: Mon, 12 May 1997 18:22:42 +0100 Message-ID: <2393.863457762@dale.uninett.no> X-Orig-Sender: hta@dale.uninett.no I'm not sure the complexity is real here. Two-phase commit is basically a simple idea; the problems come when you have to implement this thing in such a way that the ASID properties are guaranteed throughout all the layers of the systems; this proposal addresses only a single layers, which is fairly well documented in the literature. So I'm not sure it's so unrealistic as it seems. But I haven't inspected the schedule that closely.... Harald A   Received: from cnri by ietf.org id aa28226; 14 May 97 11:31 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa10814; 14 May 97 11:31 EDT Received: from ietf.org by ietf.org id aa28216; 14 May 97 11:31 EDT Received: from mercury.Sun.COM by ietf.org id aa28212; 14 May 97 11:31 EDT Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA26393; Wed, 14 May 1997 08:41:10 -0700 Received: from jurassic.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18987; Wed, 14 May 1997 08:27:22 -0700 Received: from offshore.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14632; Wed, 14 May 1997 08:27:32 -0700 Received: by offshore.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA05682; Wed, 14 May 1997 08:20:40 -0700 Date: Wed, 14 May 1997 08:20:40 -0700 Sender:iesg-request@ietf.org From: Allyn Romanow Message-Id: <199705141520.IAA05682@offshore.eng.sun.com> To: Harald.T.Alvestrand@uninett.no Subject: Re: Transaction protocol WG charter Cc: directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu, allyn@pacific-86.eng.sun.com X-Sun-Charset: US-ASCII I have a couple of questions about the proposed TIP WG. I hope this note might serve to uncover some of the issues involved in the proposed WG. (In other words, it's not a position, but a probe) As I understand it, in the state of the art TP, the transaction propagation function is bound up in the communication protocol for performance reasons. This is how Microsoft's DTC works and also OMG's IIOP. TIP is a protocol to do the propagation function only, as separate from a communication protocol (one which is over TCP and application specific). In this architecture any such higher layer communication protocol can be used, but the performance won't be as good as combining communication and transaction function. What I wonder is - what is the compelling need for TIP? What problem does TIP solve that isn't currently being solved? What are some scenarios that the TIP approach would work better for than the currently existing TP solutions? The compelling need for doing TIP isn't clear to me, what constituency wants to use it? Who would prefer to use this approach to the problem rather than the two existing TP solutions, and why? (Just being an open standard in and of itself isn't sufficient, there has to be someone who plans to use the open standard rather than the existing ones). If these questions can be answered I would think it a fine idea and that the people doing the work are most qualified to carry it through. The downside of developing TIP if it doesn't offer any real advantages is that if it becomes an IETF standard it's possible that vendors would need to implement it along with DTC and OMG's TP. This kind of transaction processing is quite complex and will require significant effort to implement, especially along with the other 2 TP protocols which already need to be provided. It just seems that we need to be sure of compelling demand in order to proliferate alternative solutions.   Received: from cnri by ietf.org id aa29650; 14 May 97 12:24 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa11891; 14 May 97 12:24 EDT Received: from ietf.org by ietf.org id aa29641; 14 May 97 12:24 EDT Received: from mail2.digital.com by ietf.org id aa29633; 14 May 97 12:24 EDT Received: from pachyderm.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA20714; Wed, 14 May 1997 09:12:08 -0700 Received: by pachyderm.pa.dec.com; id AA21176; Wed, 14 May 1997 09:12:35 -0700 Date: Wed, 14 May 1997 09:12:35 -0700 Sender:iesg-request@ietf.org From: Jim Gettys Message-Id: <9705141612.AA21176@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client tunsrv2-tunnel.imc.das.dec.com) To: Allyn Romanow Cc: Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu In-Reply-To: <199705141520.IAA05682@offshore.eng.sun.com> Subject: Re: Transaction protocol WG charter We certainly discussed much of your concerns in Digital. The following is my insight on it, having been dragged to a Digital meeting on the merits/demerits of the TIP proposal vs. competing technologies (I don't pretend to be a TP weenie). The classic example where something is needed is the Web, and is the example given in some of the TIP folks presentations. Imagine a travel agent, on a web site. You want to make a reservation, for plane, hotel, and automobile. The plane reservation will be made via the airline's web site, the hotel via the hotel's web site, and the auto via the rental agency. You'd like to do a transaction across all of the web sites (travel agency, airline, hotel, and auto, not to mention the credit card or debit card part of the transaction); you interact with a bunch of web sites as part of a single transaction. Today, the only way to engineer such a system is via back end protocols between cooperating Web sites; this means that building a meta-service among non-cooperating sites isn't possible without compromizing transaction semantics. I (and others at the meeting) concluded that the web could use such a facility, when I thought about it. And since DTC or CORBA both lack firewall boundary crossing, HTTP is about the only protocol to build from. Now, I think one could ask the question of whether the charter should make this explicit and clear or not. I also point out that we'd like someday to do something other than HTTP for the web, so defining a TP protocol strictly as messages independent of the transport is probably a good idea, so that the Web can continue to evolve (i.e. the same TP protocol be used over various transports). Existing protocols all depend on the details of the transport used, from what I understand. A working group to rubber stamp either DTC or CORBA's transaction protocols didn't seem to be useful to us, but a TP protocol independent of transport protocol for the Web and potentially other uses did seem like a reasonable thing (whether IETF is the right venue is another interesting question). - Jim Gettys   Received: from cnri by ietf.org id aa00848; 14 May 97 13:03 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa12571; 14 May 97 13:03 EDT Received: from ietf.org by ietf.org id aa00841; 14 May 97 13:03 EDT Received: from alpha.Xerox.COM by ietf.org id aa00836; 14 May 97 13:03 EDT Received: from bronze-208.parc.xerox.com ([13.0.209.122]) by alpha.xerox.com with SMTP id <17821(5)>; Wed, 14 May 1997 09:59:29 PDT Message-ID: <3379EF68.605F@parc.xerox.com> Date: Wed, 14 May 1997 09:59:20 PDT Sender:iesg-request@ietf.org From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Jim Gettys CC: Allyn Romanow , Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu Subject: Re: Transaction protocol WG charter References: <9705141612.AA21176@pachyderm.pa.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Now, I think one could ask the question of whether the charter should make > this explicit and clear or not. I think that your message or the presentation it was based on should be quickly recast into a "requirements" document for TP, and proposed as the starting point for the TP working group. The charter could explicitly mention the initial draft requirements as the basis for the work. It would be unwieldy to put the whole thing into the charter itself, but since there is such a clear statement of intent and scope, it might help reduce the fracus to have it written first, before the charter is approved. Here's my edit of your message, you could submit it as "draft-gettys-tp-req-00.txt". :) Larry ----- - Motivation - Imagine a travel agent, on a web site. You want to make a reservation for plane, hotel, and automobile. The plane reservation will be made via the airline's web site, the hotel via the hotel's web site, and the auto via the rental agency. You'd like to do a transaction across all of the web sites (travel agency, airline, hotel, and auto, not to mention the credit card or debit card part of the transaction); you interact with a bunch of web sites as part of a single transaction. Today, the only way to engineer such a system is via back end protocols between cooperating Web sites; this means that building a meta-service among non-cooperating sites isn't possible without compromizing transaction semantics. Currently these applications are built with HTTP, but other protocols might be used as well; thus, defining a TP protocol strictly as messages independent of the transport seems the best way to create something that will survive as the web continues to evolve, since the same TP protocol can be used over various transports.   Received: from cnri by ietf.org id aa15169; 16 May 97 12:56 EDT Received: from ietf.org by CNRI.Reston.VA.US id aa12070; 16 May 97 12:56 EDT Received: from ietf.org by ietf.org id aa15159; 16 May 97 12:56 EDT Received: from mersey.hursley.ibm.com by ietf.org id aa15153; 16 May 97 12:56 EDT Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13057; Fri, 16 May 1997 17:52:51 +0100 Date: Fri, 16 May 1997 17:52:51 +0100 Message-Id: <9705161652.AA13057@hursley.ibm.com> Sender:iesg-request@ietf.org From: "(Brian E Carpenter)" Subject: Re: Transaction protocol WG charter To: Greg Minshall Cc: klensin@mci.net, Harald.T.Alvestrand@uninett.no, directorate@apps.ietf.org, iesg@ietf.org, trans-area@isi.edu In-Reply-To: <199705121957.MAA00641@red.ipsilon.com> from "Greg Minshall" at May 12, 97 12:57:02 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2204 Firstly a slight declaration of interest: my new office is in the same building as the folks who do strategy and development for transaction systems in IBM, so I may be slightly infected here... >- Greg Minshall said: > > Ahh, one other comment. > > John K said: > > > Wrt the charter: this stuff is complex, and it is not clear that > > IETF has adequate competence. > > Again, i agree, though i don't really know what to do about that fact. One option is to opt out and simply not do it. .... > The real danger of the former approach is that we run the risk of being > marginalized. I.e., if we say "no" to lots of things, people will quit asking > us, and then we won't even get the *chance* to say "no". IMHO that is a lesser danger than the one we face, of over-stretching the IETF. > (One solution might be to punt TIP to the IRTF? Here, the "research" portion > is the *IETF* researching "what do you mean by 2pc, etc.?", i.e., developing > sufficient expertise, both "in the ranks" as well as in the leadership [IESG, > etc.], in order to do "justice" to such an effort.) I really think that is no solution - 2pc is hardly a new concept. IIOP and CORBA are not only the reserved hunting ground of the OMG, which is why they are exceedingly unlikely to give up change control, but also they are defined in a way which is totally different from how we do things in the IETF. I just can't see any reason to invest effort in migrating them to IETF-speak, even if the OMG and the IETF agreed politically. The CORBA specs are about 500 pages long. It just makes no sense. (To be clear, I'm vigorously wearing an IAB hat when I say this.) Whether we develop TIP in the IETF should be decided on its own merits: given that a large chunk of the industry is going for CORBA/IIOP as a multivendor solution, does the industry *need* TIP? What is the extra requirement that TIP satisfies? (Not transactions over http - that's such a misuse that it doesn't get past the start line afaic.) Somebody asserted that IIOP won't traverse firewalls. Surely that is not a real constraint - i.e. firewalls will be modernised appropriately if the market calls for IIOP traversal. Brian Carpenter   Received: from ietf.org by ietf.org id aa17502; 28 May 97 12:20 EDT Received: from [200.246.167.105] by ietf.org id aa17421; 28 May 97 12:19 EDT Received: from tucows.alphanet.com.br (andre@tucows.alphanet.com.br [200.246.167.105]) by tucows.alphanet.com.br (8.7.5/8.7.3) with SMTP id NAA21581; Wed, 28 May 1997 13:18:09 -0300 Date: Wed, 28 May 1997 13:18:08 -0300 (EST) Sender:ietf-request@ietf.org From: Andre Correa To: "D. JEULAND" cc: ietf@ietf.org Subject: Re: (no subject) In-Reply-To: <338C2B19.8C4@ireste.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Please read the mailling list FAQ before trying to subscribe to a list. It is the wrong address. NetQuet. ********************************************** E-Mail: andre.correa@pobox.com Finger: andre.correa@pobox.com IRC: meandyou > @#sampa igc.dal.net IRC: meandyou > IRCop irc.alphanet.com.br Home Page: http://www.pobox.com/~andre.correa/ ********************************************** -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzOCPRcAAAEEAMREqeDuB3F8RiygJQpOAlYrjNg00I9HTmrubN+S/b92cgFk wnntIdODsrVzkH+AFp+DtfAFMIxUkpyPoKgbZZsGBl/jIbZQKJt9DLqr+KhUCNZF uH3rb+eCCl4O20WD0xc/vRQyWuKOe7Aov2cIrr+5gyttUvzKXbtXCwEYW0lNAAUR tCVBbmRyZSBDb3JyZWEgPGFuZHJlLmNvcnJlYUBwb2JveC5jb20+iQCVAwUQM4I9 F7tXCwEYW0lNAQHpiQP/WOiTmRGACc0qQlB56LtPlyzldaCQBev15RQqzaadYZ7z Eh6CzCg79tczDe3NOzqY3vh8vPWciwKpg377GipJMIaHQL1EqU+WgqKEUXr5MM4d qg9t++8WHc5lfq8PhOhwJE+IUZmbzXt0Tc+E7nuDkbl2yngeL2bkhNMlEUZEgrU= =OmNV -----END PGP PUBLIC KEY BLOCK----- On Wed, 28 May 1997, D. JEULAND wrote: > SUBSCRIBE djeuland@ireste.fr >