From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 2 16:27:55 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22885 for ; Tue, 2 Jan 2001 16:27:55 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA24123; Tue, 2 Jan 2001 13:26:11 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.prod.itd.earthlink.net [207.217.120.120]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA24108 for ; Tue, 2 Jan 2001 13:26:11 -0800 (PST) Received: from w2kbwyman (sdn-ar-007casfrMP010.dialsprint.net [158.252.214.12]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA28578 for ; Tue, 2 Jan 2001 13:25:56 -0800 (PST) Message-ID: <004701c07502$96866b70$b1d9fc9e@accrue.com> Reply-To: "Bob Wyman" From: "Bob Wyman" To: Date: Tue, 2 Jan 2001 13:25:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] User Specific profile advertisement? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit I would like to be able to advertise different lists of available profiles based on the identity of the users who connect to my server. How do I do this? In BXXP, the greeting element allows each peer to advertise the profiles it supports by sending a greeting message. Thus, a peer can advertise supported profiles either on initial connection or when the greeting is sent after transport security is negotiated. This means that one set of profiles might be advertised to peers that connect with no transport security while a second, identical or different, set of profiles can be advertised once transport security has been negotiated. This is goodness. For some obscure reason, I may only want to send my profile advertisements over secure lines or only to those who have established their ability to use some particular kind of transport security. It would also be desirable to allow the advertising of profiles to be dependent on authentication. However, the User Authentication negotiation, unlike that for Transport Security, does not appear to provide for a new greeting message once complete. This is unfortunate since there are a number of situations in which I would only want profiles to be advertised to specific individuals or members of groups. Am I misreading the spec (I'm new to BXXP.)? Or, is there a mechanism available to allow user specific profile advertisement? If not, should one be added? (i.e. perhaps require or permit a new greeting message after User Authentication?) bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 2 16:57:27 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23133 for ; Tue, 2 Jan 2001 16:57:27 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA24387; Tue, 2 Jan 2001 13:56:27 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA24372 for ; Tue, 2 Jan 2001 13:56:26 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f02Ljf018160; Tue, 2 Jan 2001 13:45:41 -0800 (PST) Message-ID: <023c01c07506$d1e3ba70$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: <004701c07502$96866b70$b1d9fc9e@accrue.com> Subject: Re: [BXXPwg] User Specific profile advertisement? Date: Tue, 2 Jan 2001 13:56:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit > I would like to be able to advertise different lists of available profiles > based on the identity of the users who connect to my server. How do I do > this? hi. the short answer is that you can do this, but it isn't easy. you already stated the sub-optimal solution: if you use a transport security profile to authenticate then when the underlying transport security negotiation completes, all cached information is discarded and a new greeting is generated. you could make this greeting authenticator-specific if you wanted. an alternative approach is to offer BEEP on multiple TCP ports, and have different profiles available on each port. you could then use the DNS to do the selection for you. for example, i don't think that it's unreasonable to think that 6 months from now, a given server might be offering APEX edge service on one port, the APEX relay service on another, the syslog service on a third, etc. in each case, the initiating peer uses SRV records to figure out the port to connect to. from a philosophical perspective, services decide which users get to do what; it's easy to see a useful system based on "i want to do this specific class of transactions, and i authenticate as mrose"; it's a lort hard to imagine a useful system based on "i authenticate as mrose, so what classes of transactions am i allowed"? /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 2 18:06:37 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23867 for ; Tue, 2 Jan 2001 18:06:36 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA25109; Tue, 2 Jan 2001 15:05:35 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.prod.itd.earthlink.net [207.217.120.120]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA25086 for ; Tue, 2 Jan 2001 15:05:34 -0800 (PST) Received: from w2kbwyman (sdn-ar-007casfrMP010.dialsprint.net [158.252.214.12]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id PAA13843; Tue, 2 Jan 2001 15:04:44 -0800 (PST) Message-ID: <008401c07510$657a8a30$b1d9fc9e@accrue.com> Reply-To: "Bob Wyman" From: "Bob Wyman" To: "Marshall T. Rose" , References: <004701c07502$96866b70$b1d9fc9e@accrue.com> <023c01c07506$d1e3ba70$8753cf3f@FATORA> Subject: Re: [BXXPwg] User Specific profile advertisement? Date: Tue, 2 Jan 2001 15:03:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Marshall T. Rose wrote: > hard to imagine a useful system based on > "i authenticate as mrose, so what classes > of transactions am i allowed"? Imagine: A site uses a single BEEP port to offer a variety of services to a variety of customers who are provided with varying degrees of service. Of the 10 services available, "basic" customers are allowed to use services 1-5 while "premium" customers are allowed to use services 1-10. All 10 services are known to a client applications that enables or disables various user interface elements based on which profiles are available on the currently active connection. A stock market site might, for instance, allow Edgar searching for free, yet require a valid UserID in order to access "portfolio management." The client application might be something like Groove, thus providing a basic framework within which many "tools" can be run. The result is that there might be dozens or even hundreds of profiles that could be supported by any particular client configuration. Thus, it would be ugly to have to query for each possible profile every time the client connects to a server. In a slightly different scenario, there might be "stealth" services available (such as use of proto-type systems or proprietary applications), access to which would be reserved to specific users and whose availability the site did not want to publish. (Note: In some contexts, simply publishing the name of a service can give away critical information. Even publishing a service with an obscure name might cause people to seek additional information - via probes or off-line means. Thus, some profiles should not be advertised either by greeting messages or DNS entries.) Admittedly, one can say that the stealth service, even if not advertised in the greeting message, could still be requested by the client, however, given a sufficiently paranoid site, folk may wish to ensure that clients for "stealth" services never risk asking for the service from a server that does not provide it. Rejected profile requests might be logged and thus be open to inspection. (i.e. Hacker says: "The log says that someone from 'Bank of FooBar' asked for access to the 'BigBucks' service. Let's see if we can find it on one of their servers...) > you already stated the sub-optimal solution: Let me clarify: You appear to be suggesting that I can do Authentication specific greeting messages by doing Authentication first and then doing Transport Security negotiation second. The greeting message emitted after the Transport Security negotiation could then be dependent on the earlier authentication? I had been assuming that Authentication had to happen after Transport Security negotiation since such negotiation causes all cached information to be discarded. Is Authentication information NOT discarded as a result of Transport Security negotiation? If this "pattern" works, then should one suggest that as a "best practice" peers should always do Authentication first and transport security second in order to enable Authentication specific greetings messages? Even if this works, there is still the problem of how to do this Transport Security negotiation is not necessary. I suppose one could define a way to negotiate for "no-transport security" in order to trigger the greeting message, however, that strikes me as very ugly. It would seem to be easier to simply allow a greeting message to appear after Authentication. > an alternative approach is to offer BEEP on multiple TCP ports, and have > different profiles available on each port. you could then use the DNS to do > the selection for you. for example, i don't think that it's unreasonable to If DNS satisfied all profile advertisement requirements then it wouldn't be sensible to do profile advertisement in BEEP... In some cases, as described above, one does not want to publish the availability of services except to a very strictly controlled community. In other cases, for instance my personal machine connecting through an ISP who does not let me diddle with DNS settings, I may not be able to make appropriate modifications to the DNS entries. Even in a corporate environment, it can sometimes be hard to get the local MIS folk to make DNS changes when desired. I really like that BEEP can provide a single access port that I can use to advertise and support a wide range of services much in the same way I can use a single web server to provide access to a variety of services. I do, of course, see the value of being able to use a mechanism to direct or redirect users to different ports based on the service they require. That, however, should be the subject of a later discussion... bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 2 18:24:11 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23994 for ; Tue, 2 Jan 2001 18:24:11 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA25247; Tue, 2 Jan 2001 15:23:11 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA25230 for ; Tue, 2 Jan 2001 15:23:10 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f02NCS018437; Tue, 2 Jan 2001 15:12:28 -0800 (PST) Message-ID: <033401c07512$f184fea0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: <004701c07502$96866b70$b1d9fc9e@accrue.com> <023c01c07506$d1e3ba70$8753cf3f@FATORA> <008401c07510$657a8a30$b1d9fc9e@accrue.com> Subject: Re: [BXXPwg] User Specific profile advertisement? Date: Tue, 2 Jan 2001 15:22:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit well, there's nothing that stops you from making problems as hard (or easy) as you want. but this all sounds like the hard way: the wrong thing is being optimized for. you can certainly have a server advertise lots of profiles in a greeting, and then, after authentication, decide whether it will allow a given profile to be started or not. or maybe you can start it, but the authorization policy allows only a subset of the operations, etc., etc. /mtr ----- Original Message ----- From: "Bob Wyman" To: "Marshall T. Rose" ; Sent: Tuesday, January 02, 2001 15:03 Subject: Re: [BXXPwg] User Specific profile advertisement? > Marshall T. Rose wrote: > > hard to imagine a useful system based on > > "i authenticate as mrose, so what classes > > of transactions am i allowed"? > Imagine: A site uses a single BEEP port to offer a variety of services to a > variety of customers who are provided with varying degrees of service. Of > the 10 services available, "basic" customers are allowed to use services 1-5 > while "premium" customers are allowed to use services 1-10. All 10 services > are known to a client applications that enables or disables various user > interface elements based on which profiles are available on the currently > active connection. A stock market site might, for instance, allow Edgar > searching for free, yet require a valid UserID in order to access "portfolio > management." The client application might be something like Groove, thus > providing a basic framework within which many "tools" can be run. The result > is that there might be dozens or even hundreds of profiles that could be > supported by any particular client configuration. Thus, it would be ugly to > have to query for each possible profile every time the client connects to a > server. > > In a slightly different scenario, there might be "stealth" services > available (such as use of proto-type systems or proprietary applications), > access to which would be reserved to specific users and whose availability > the site did not want to publish. (Note: In some contexts, simply publishing > the name of a service can give away critical information. Even publishing a > service with an obscure name might cause people to seek additional > information - via probes or off-line means. Thus, some profiles should not > be advertised either by greeting messages or DNS entries.) Admittedly, one > can say that the stealth service, even if not advertised in the greeting > message, could still be requested by the client, however, given a > sufficiently paranoid site, folk may wish to ensure that clients for > "stealth" services never risk asking for the service from a server that does > not provide it. Rejected profile requests might be logged and thus be open > to inspection. (i.e. Hacker says: "The log says that someone from 'Bank of > FooBar' asked for access to the 'BigBucks' service. Let's see if we can find > it on one of their servers...) > > > you already stated the sub-optimal solution: > Let me clarify: You appear to be suggesting that I can do Authentication > specific greeting messages by doing Authentication first and then doing > Transport Security negotiation second. The greeting message emitted after > the Transport Security negotiation could then be dependent on the earlier > authentication? I had been assuming that Authentication had to happen after > Transport Security negotiation since such negotiation causes all cached > information to be discarded. Is Authentication information NOT discarded as > a result of Transport Security negotiation? If this "pattern" works, then > should one suggest that as a "best practice" peers should always do > Authentication first and transport security second in order to enable > Authentication specific greetings messages? > Even if this works, there is still the problem of how to do this Transport > Security negotiation is not necessary. I suppose one could define a way to > negotiate for "no-transport security" in order to trigger the greeting > message, however, that strikes me as very ugly. It would seem to be easier > to simply allow a greeting message to appear after Authentication. > > > an alternative approach is to offer BEEP on multiple TCP ports, and have > > different profiles available on each port. you could then use the DNS to > do > > the selection for you. for example, i don't think that it's unreasonable > to > > If DNS satisfied all profile advertisement requirements then it wouldn't be > sensible to do profile advertisement in BEEP... In some cases, as described > above, one does not want to publish the availability of services except to a > very strictly controlled community. In other cases, for instance my personal > machine connecting through an ISP who does not let me diddle with DNS > settings, I may not be able to make appropriate modifications to the DNS > entries. Even in a corporate environment, it can sometimes be hard to get > the local MIS folk to make DNS changes when desired. > > I really like that BEEP can provide a single access port that I can use to > advertise and support a wide range of services much in the same way I can > use a single web server to provide access to a variety of services. I do, of > course, see the value of being able to use a mechanism to direct or redirect > users to different ports based on the service they require. That, however, > should be the subject of a later discussion... > > bob wyman > > > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jan 3 07:19:31 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18586 for ; Wed, 3 Jan 2001 07:19:31 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id EAA28811; Wed, 3 Jan 2001 04:18:27 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id EAA28792 for ; Wed, 3 Jan 2001 04:18:26 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18352; Wed, 3 Jan 2001 07:18:24 -0500 (EST) Message-Id: <200101031218.HAA18352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: bxxpwg@invisible.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Jan 2001 07:18:24 -0500 Subject: [BXXPwg] I-D ACTION:draft-ietf-beep-framework-10.txt Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Blocks Extensible Exchange Protocol Working Group of the IETF. Title : The Blocks Extensible Exchange Protocol Framework Author(s) : M. Rose Filename : draft-ietf-beep-framework-10.txt Pages : 57 Date : 02-Jan-01 This memo describes a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-beep-framework-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-beep-framework-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-beep-framework-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010102133721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-beep-framework-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-beep-framework-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010102133721.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jan 3 10:21:04 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25155 for ; Wed, 3 Jan 2001 10:21:03 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id HAA29767; Wed, 3 Jan 2001 07:20:02 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id HAA29750 for ; Wed, 3 Jan 2001 07:20:02 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f03F9N020782; Wed, 3 Jan 2001 07:09:23 -0800 (PST) Message-ID: <001301c07598$a1c45010$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Wed, 3 Jan 2001 07:19:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] draft-ietf-beep-framework-10.txt Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit hi. the previous message about a new BEEP framework I-D contains some, but not all, of the changes made during the IESG review. there's one other set of changes i'm still waiting on. here's the summary between -09 and -10: s/parallelism/asynchrony = pipelining + parallelism/ you can pretty much see it all by reading page 27. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jan 3 14:21:44 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02537 for ; Wed, 3 Jan 2001 14:21:43 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA01749; Wed, 3 Jan 2001 11:20:33 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA01734 for ; Wed, 3 Jan 2001 11:20:32 -0800 (PST) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA13112; Wed, 3 Jan 2001 11:20:28 -0800 (PST) Message-ID: <3A537B58.8ECCCFE@isi.edu> Date: Wed, 03 Jan 2001 11:19:52 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith McCloghrie CC: bxxpwg@invisible.net Subject: Re: [BXXPwg] Draft minutes of meeting in San Diego References: <200012282311.PAA02259@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Keith McCloghrie wrote: > > Joe, > > Thanks for your technical comments. However, I was really looking > for agreement on recording what happened at the meeting. If you > believe that my draft minutes do not reflect what happened, could > you suggest alternative wording. Here: > > > 1. The notion of mapping a BEEP session onto multiple TCP connections > > > is still under consideration by Joe Touch, even though no I-D has > > > been generated as yet. The notion of mapping a BEEP session onto multiple TCP connections is still under consideration by Joe Touch. Joe confirmed that this work is still pending further progress of the base protocol. > > > Discussion then returned to the issue of whether the "ERR" message > > > should be allowed (as an alternative to a "NUL" message) in one-to-many > > > exchanges. The chair observed that this was not a new issue; the > > > Working Group had discussed it at least once before on the mailing > > > list and decided in favour of the approach in the current documents. It was unclear at the meeting if there was agreement on what the current documents indicated. At least one group argued that "ERR" messages convey BEEP-layer errors only, and that application-specific errors are conveyed by "RSP" or "ANS" messages. Joe Touch believed the current documents indicated otherwise; that the ERR messages include application errors. (as chair, I would expect that the draft might include a clarification by you on this, as an aside. I did review the documents later, and found them consistent with application-level errors, and in fact that they were not consistent with BEEP-level errors at all.) Joe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jan 5 00:09:00 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23340 for ; Fri, 5 Jan 2001 00:08:59 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA13105; Thu, 4 Jan 2001 21:07:35 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA13089 for ; Thu, 4 Jan 2001 21:07:35 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f054uj025948; Thu, 4 Jan 2001 20:56:46 -0800 (PST) Message-ID: <00ba01c076d5$672abe60$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Thu, 4 Jan 2001 21:07:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] updated I-Ds Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit another set of comments from the IESG came in, and new I-Ds have been sent to the repository. the next two messages contain the .html versions for people who want to see them now. here are the macro diffs: framework document: 1. is now called the "core" document, because "framework" means "informational taxonomy document" to the iesg. (throughout) 2. the serial nature of tuning channels was clarified. (page 5) 3. a possible race condition when closing a channel was removed by specifying more detail for the steps taken by each peer. (last three paragraphs of page 20, and page 21) tcpmapping document: 1. title change ("... the beep core ...") 2. more explicit references to abstract TCP calls (e.g., "OPEN call" becomes "TCP OPEN call" throughout) 3. explicit detail for when the TCP CLOSE is issued when releasing a session (page 4) 4. reference made to RFC 1982 on serial number arithmetic (page 6) 5. segmentation hint changed to 2/3rds of TCP's negotiated maximum segment size (page 9) 6. consolidating SEQ frames is no longer parenthetical (page 9) 7. value-add of congestion information APIs is spelled-out (page 9). 8. security considerations section added pointing to core document. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jan 5 00:09:20 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23350 for ; Fri, 5 Jan 2001 00:09:18 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA13206; Thu, 4 Jan 2001 21:08:16 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA13137 for ; Thu, 4 Jan 2001 21:08:13 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f054vN025953; Thu, 4 Jan 2001 20:57:24 -0800 (PST) Message-ID: <00c501c076d5$7dd05210$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Thu, 4 Jan 2001 21:08:07 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C2_01C07692.6F8D06F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] new BEEP core draft (in HTML) Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C07692.6F8D06F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_00C2_01C07692.6F8D06F0 Content-Type: text/html; name="draft-ietf-beep-core.html" Content-Disposition: attachment; filename="draft-ietf-beep-core.html" Content-Transfer-Encoding: quoted-printable The Blocks Extensible Exchange Protocol Core
 TOC 
Network Working GroupM.T. Rose
Internet-DraftInvisible Worlds, Inc.
Expires: July 5, 2001January 4, 2001

The Blocks = Extensible Exchange Protocol Core
draft-ietf-beep-framework-10

Status of this Memo

This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet-Drafts as reference material or to = cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/i= etf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html<= /a>.

This Internet-Draft will expire on July 5, 2001.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.


 TOC 

Table of Contents

    1.  Introduction
     2.  The BEEP Core
     2.1  Roles
     2.1.1  Exchange Styles
     2.2  Messages and Frames
     2.2.1  Frame Syntax
     2.2.1.1  Frame Header
     2.2.1.2  Frame Payload
     2.2.1.3  Frame Trailer
     2.2.2  Frame Semantics
     2.2.2.1  Poorly-formed Messages
     2.3  Channel Management
     2.3.1  Message Semantics
     2.3.1.1  The Greeting Message
     2.3.1.2  The Start Message
     2.3.1.3  The Close Message
     2.3.1.4  The OK Message
     2.3.1.5  The Error Message
     2.4  Session Establishment and Release
     2.5  Transport Mappings
     2.5.1  Session Management
     2.5.2  Message Exchange
     2.6  Asynchrony
     2.6.1  Within a Single Channel
     2.6.2  Between Different Channels
     2.6.3  Pre-emptive Replies
     2.6.4  Interference
     2.7  Peer-to-Peer Behavior
     3.  Transport Security
     3.1  The TLS Transport Security Profile
     3.1.1  Profile Identification and Initialization
     3.1.2  Message Syntax
     3.1.3  Message Semantics
     3.1.3.1  The Ready Message
     3.1.3.2  The Proceed Message
     4.  User Authentication
     4.1  The SASL Family of Profiles
     4.1.1  Profile Identification and Initialization
     4.1.2  Message Syntax
     4.1.3  Message Semantics
     5.  Registration Templates
     5.1  Profile Registration Template
     5.2  Feature Registration Template
     6.  Initial Registrations
     6.1  Registration: BEEP Channel Management
     6.2  Registration: TLS Transport Security Profile
     6.3  Registration: SASL Family of Profiles
     6.4  Registration: application/beep+xml
     7.  DTDs
     7.1  BEEP Channel Management DTD
     7.2  TLS Transport Security Profile DTD
     7.3  SASL Family of Profiles DTD
     8.  Reply Codes
     9.  Security Considerations
     §  References
     §  Author's Address
     A.  Acknowledgements
     B.  IANA Considerations
     §  Full Copyright Statement


 TOC 

1. Introduction

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP.

At BEEP's core is a framing mechanism that permits simultaneous and independent exchanges of messages between = peers. Messages are arbitrary MIME[1] content, but are usually textual (structured using XML[2]).

All exchanges occur in the context of a channel — a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange.

Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BEEP is the notion of channel management. In addition to defining BEEP's channel management profile, this document defines:

  • the TLS[3] transport security profile; and,
  • the SASL[4] family of profiles.
Other profiles, such as those used for data exchange, are defined by an application protocol designer.


 TOC 

2. The BEEP Core

A BEEP session is mapped onto an underlying transport service. A separate series of documents describe how a particular transport service realizes a BEEP session. For example, [5] describes how a BEEP session is mapped onto a single TCP[6] connection.

When a session is established, each BEEP peer advertises the profile it supports. Later on, during the creation of a channel, the client supplies one or more proposed profiles for that channel. If the server creates the channel, it selects one of the profiles and sends it in a reply; otherwise, it may indicate that none of the profiles are acceptable, and decline creation of the channel.

Channel usage falls into one of two categories:

initial tuning:
these are used by profiles that perform initialization once the BEEP session is established (e.g., negotiating the use of transport security); although several exchanges may be required to perform the = initialization, these channels become inactive early in the BEEP session and remain so for the duration.
continuous:
these are used by profiles that support data exchange; typically, these channels are created after the initial tuning channels have gone quiet.
Note that because of their special nature, only one tuning channel may be established at any given time; in contrast, BEEP allows multiple data exchange channels to be simultaneously in use.

2.1 Roles

Although BEEP is peer-to-peer, it is convenient to label each peer in the context of the role it is performing at a given time:

  • When a BEEP session is established, the peer that awaits new connections is acting in the listening role, and the other peer, which establishes a connection to the listener, is acting in the initiating role. In the examples which follow, these are referred to as "L:" and "I:", respectively.
  • A BEEP peer starting an exchange is termed the client; similarly, the other BEEP peer is termed the server. In the examples which follow, these are referred to as "C:" and "S:", respectively.
Typically, a BEEP peer acting in the server role is also acting in a listening = role. However, because BEEP is peer-to-peer in nature, no such requirement exists.

2.1.1 Exchange Styles

BEEP allows three styles of exchange:

MSG/RPY:
the client sends a "MSG" message asking the server to perform some task, the server performs the task and replies with a "RPY" message (termed a positive reply).
MSG/ERR:
the client sends a "MSG" message, the server does not perform any task and replies with an "ERR" message (termed a negative reply).
MSG/ANS:
the client sends a "MSG" message, the server, during the course of performing some task, replies with zero or more "ANS" messages, and, upon completion of the task, sends a "NUL" message, which signifies the end of the reply.
The first two styles are termed one-to-one exchanges, whilst the third style is termed a one-to-many exchange.

2.2 Messages and Frames

A message is structured according to the rules of MIME. Accordingly, each message may begin with "entity-headers" (c.f., MIME[1]'s Section 3). If none, or only some, of the "entity-headers" are present:

  • the default "Content-Type" is "application/octet-stream"; and,
  • the default "Content-Transfer-Encoding" is "binary".

Normally, a message is sent in a single frame. However, it may be convenient or necesary to segment a message into multiple = frames (e.g., if only part of a message is ready to be sent).

Each frame consists of a header, the payload, and a trailer. The header and trailer are each represented using printable ASCII characters and are terminated with a CRLF pair. Between the header and the trailer is the payload, consisting of zero or more octets.

For example, here is a message contained in a single frame that contains a payload of 132 octets spread over 5 lines (each line is terminated with a CRLF pair): 

    C: MSG 0 1 . 52 132
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    C: </start>
    C: END

In this example, note that the entire message is represented in a single frame.

2.2.1 Frame Syntax

The ABNF[7] for a frame is: 

frame      =3D data / mapping

data       =3D header payload trailer

header     =3D msg / rpy / err / ans / nul

msg        =3D "MSG" SP common          CR LF
rpy        =3D "RPY" SP common          CR LF
ans        =3D "ANS" SP common SP ansno CR LF
err        =3D "ERR" SP common          CR LF
nul        =3D "NUL" SP common          CR LF

common     =3D channel SP msgno SP more SP seqno SP size
channel    =3D 0..2147483647
msgno      =3D 0..2147483647
more       =3D "." / "*"
seqno      =3D 0..4294967295
size       =3D 0..2147483647
ansno      =3D 0..2147483647

payload    =3D *OCTET

trailer    =3D "END" CR LF

mapping    =3D ;; each transport mapping may define additional frames

2.2.1.1 Frame Header

The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each = component. The header is terminated with a CRLF pair.

The channel number ("channel") must be a non-negative integer (in the range 0..2147483647).

The message number ("msgno") must be a non-negative integer (in the range 0..2147483647) and have a different value than all other "MSG" messages on the same channel for which a reply has not been completely received.

The continuation indicator ("more", one of: decimal code 42, "*", or decimal code 46, ".") specifies whether this is the final frame of the message:

intermediate ("*"):
at least one other frame follows for the message; or,
complete ("."):
this frame completes the message.

The sequence number ("seqno") must be a non-negative integer (in the range 0..4294967295) and specifies the sequence number of the first octet in the payload, for the associated channel (c.f., Frame Payload).

The payload size ("size") must be a non-negative integer (in the range 0..2147483647) and specifies the exact number of octets in the payload. (This does not include either the header or trailer.)

Note that a frame may have an empty payload, e.g., 

    S: RPY 0 1 * 287 20
    S:     ...
    S:     ...
    S: END
    S: RPY 0 1 . 307 0
    S: END

The answer number ("ansno") must be a non-negative integer (in the range 0..4294967295) and must have a different value than all other answers in progress for the message being replied to.

There are two kinds of frames: data and mapping. each transport mapping (c.f., Transport = Mappings) may define its own frames. For example, [5] defines the SEQ frame. The remainder of this section discusses data frames.

When a message is segmented and sent as several frames, those frames must be sent sequentally, without any intervening frames from other messages on the same channel. However, there are two exceptions: first, no restriction is made with respect to the interleaving of frames for other channels; and, second, in a one-to-many exchange, multiple answers may be simultaneously in progress. Accordingly, frames for "ANS" messages may be interleaved on the same channel — the answer number is used for collation, e.g., 

    S: ANS 1 0 * 0 20 0
    S:     ...
    S:     ...
    S: END
    S: ANS 1 0 * 20 20 1
    S:     ...
    S:     ...
    S: END
    S: ANS 1 0 . 40 10 0
    S:     ...
    S: END

which shows two "ANS" messages interleaved on channel 1 as part of a reply to message number 0. Note that the sequence number is advanced for each frame sent on the channel, and is independent of the messages sent in those frames.

There are several rules for identifying poorly-formed frames:

  • if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or "NUL";=20
  • if any of the parameters in the header cannot be determined or are invalid (i.e., syntactically incorrect);
  • if the value of the channel number doesn't refer to an existing channel;
  • if the header starts with "MSG", and the message number refers to a "MSG" message that has been = completely received but for which a reply has not been completely sent;
  • if the header doesn't start with "MSG", and refers to a message number for which a reply has already been completely received;
  • if the header doesn't start with "MSG", and refers to a message number that has never been sent (except during session establishment, c.f., The Greeting Message);
  • if the header starts with "MSG", "RPY", "ERR", or "ANS", and refers to a message number for which at least one other frame has been received, and the three-character keyword starting this frame and the immediately-previous received frame for this message number are not identical;
  • if the header starts with "NUL", and refers to a message number for which at least one other frame has been received, and the keyword of of the immediately-previous received frame for this reply isn't "ANS";
  • if the continuation indicator of the previous frame received on the same channel was intermediate ("*"), and its message number isn't identical to this frame's message number;
  • if the value of the sequence number doesn't correspond to the expected value for the associated channel (c.f., Frame Payload); or,
  • if the header starts with "NUL", and the continuation indicator is intermediate ("*") or the payload size is non-zero.
If a frame is poorly-formed, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

2.2.1.2 Frame Payload

The frame payload consists of zero or more octets.

Every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a frame is such that the first = payload octet is the lowest numbered, and the following payload octets are numbered consecutively. (When a channel is created, the sequence number associated with the first payload octet of the first frame is 0.)

The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of [8] for a discussion of the arithmetic properties of sequence numbers.

When receiving a frame, the sum of its sequence number and payload size, modulo 4294967296 (2**32), gives the expected sequence number associated with the first payload = octet of the next frame received. Accordingly, when receiving a frame if the sequence number isn't the expected value for this channel, then the BEEP peers have lost synchronization, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

2.2.1.3 Frame Trailer

The frame trailer consists of "END" followed by a CRLF pair.

When receiving a frame, if the characters immediately following the payload don't correspond to a trailer, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

2.2.2 Frame Semantics

The semantics of each message is channel-specific. Accordingly, the profile associated with a channel must define:

  • the initialization messages, if any, exchanged during channel creation;
  • the messages that may be exchanged in the payload of the channel; and,
  • the semantics of these messages.
A profile registration template organizes this information.

2.2.2.1 Poorly-formed Messages

When defining the behavior of the profile, the template must specify how poorly-formed "MSG" messages are replied to. For example, the channel management profile sends a negative reply containing an error message (c.f., The Error Message).

If a poorly-formed reply is received on channel zero, the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

If a poorly-formed reply is received on another channel, then the channel must be closed using the procedure in The Close Message.

2.3 Channel Management

When a BEEP session starts, only channel number zero is defined, which is used for channel management. Registration: BEEP Channel = Management contains the profile registration for BEEP channel management.

Channel management allows each BEEP peer to advertise the profiles that it supports (c.f., The Greeting Message), bind an instance of one of those profiles to a channel (c.f., The Start Message), and then later close any channels or release the BEEP session (c.f., The Close Message).

A BEEP peer should support at least 257 concurrent channels.

2.3.1 Message Semantics

2.3.1.1 The Greeting = Message

When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero that contains a "greeting" element, e.g., 

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 122
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END

Note that this example implies that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends = its greeting — this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.

The "greeting" element has two optional attributes ("features" and "localize") and zero or more "profile" elements, one for each profile supported by the BEEP peer acting in a server role:

  • the "features" attribute, if present, contains one or more feature tokens, each indicating an optional feature of the channel management profile supported by the BEEP peer;
  • the "localize" attribute, if present, contains one or more language tokens (defined in [9]), each identifying a desirable language tag to be used by the remote BEEP peer when generating textual diagnostics for the "close" and "error" elements (the tokens are ordered from most to least desirable); and,
  • each "profile" element contained within the "greeting" element = identifies a profile, and unlike the "profile" elements that occur within the "start" element, the content of each "profile" element may not contain an optional initialization message.

Feature Registration Template = defines a registration template for optional features.

2.3.1.2 The Start Message

When a BEEP peer wants to create a channel, it sends a "start" element on channel zero, e.g., 

    C: MSG 0 1 . 52 132
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    C: </start>
    C: END

The "start" element has a "number" attribute, an optional "serverName" attribute, and one or more "profile" elements:

  • the "number" attribute indicates the channel number=20 (in the range 1..2147483647) used to identify the channel in future messages;
  • the "serverName" attribute, an arbitrary string, indicates the desired server name for this BEEP session; and,
  • each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content:
    • the "uri" attribute authoritatively identifies the profile;
    • the "encoding" attribute, if present, specifies whether the content of the "profile" element is represented as a base64-encoded string; and,
    • the content of the "profile" element, if present, must be no longer than 4K octets in length and specifies an initialization message given to the channel as soon as it is created.

To avoid conflict in assigning channel numbers when requesting the creation of a channel, BEEP peers acting in the initiating role use only positive integers that = are odd-numbered; similarly, BEEP peers acting in the listening role use only positive integers that = are even-numbered.

The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in a negative reply.

When a BEEP peer receives a "start" element on channel zero, it examines each of the proposed profiles, and decides whether to use one of them to create the channel. If so, the appropriate "profile" element is sent in a positive reply; otherwise, an "error" element is sent in a negative reply.

When creating the channel, the value of the "serverName" attribute from the first successful "start" element is consulted to provide configuration information, e.g., the desired server-side certificate when starting the TLS transport security profile.

For example, a successful channel creation might look like this: 

    C: MSG 0 1 . 52 209
    C: Content-Type: application/beep+xml
    C:=20
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    C:    <profile
    C:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    C: </start>
    C: END
    S: RPY 0 1 . 264 99
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' />
    S: END

Similarly, an unsuccessful channel creation might look like this: 

    C: MSG 0 1 . 52 132
    C: Content-Type: application/beep+xml
    C:=20
    C: <start number=3D'2'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>=20
    C: </start>
    C: END
    S: ERR 0 1 . 264 127
    S: Content-Type: application/beep+xml
    S:
    S: <error code=3D'501'>number attribute
    S: in &lt;start&gt; element must be odd-valued</error>
    S: END

Finally, here's an example in which an initialization element is exchanged during channel creation: 

    C: MSG 0 1 . 52 170
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    C:        <![CDATA[<ready />]]>
    C:    </profile>
    C: </start>
    C: END
    S: RPY 0 1 . 122 133
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    S:     <![CDATA[<proceed />]]>
    S: </profile>
    S: END

2.3.1.3 The Close Message

When a BEEP peer wants to close a channel, it sends a "close" element on channel zero, e.g., 

    C: MSG 0 2 . 247 71
    C: Content-Type: application/beep+xml
    C:
    C: <close number=3D'1' code=3D'200' />
    C: END

The "close" element has a "number" attribute, a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content:

  • the "number" attribute indicates the channel number;
  • the "code" attribute is a three-digit reply code meaningful to programs (c.f., Reply Codes);
  • the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and,
  • the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs.
Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used.

If the value of the "number" attribute is zero, then the BEEP peer wants to release the BEEP session (c.f., Session Establishment and Release) = — otherwise the value of the "number" attribute refers to an existing channel, and the remainder of this section applies.

A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".)

After sending the "close" message, that BEEP peer must not send any more "MSG" messages on that channel being closed until the reply to the "close" message has been received (either by an "error" message rejecting the request to close the = channel, or by an "ok" message subsequently followed by the channel being successfully started).

NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel.

When a BEEP peer receives a "close" message for a channel, it may, at any time, reject the request to close the channel by sending an "error" message in = a negative reply.

Otherwise, before accepting the request to close the channel, and sending an "ok" message in a positive reply, it must:

  • finish sending any queued "MSG" messages on that channel of its own;
  • await complete replies to any outstanding "MSG" messages it has sent on that channel; and,
  • finish sending complete replies to any outstanding "MSG" messages it has received on that channel, and ensure that the final frames of those replies have been successfully delivered, i.e.,
    • for transport mappings that guarantee inter-channel ordering of messages, the replies must be sent prior to sending the "ok" message in a positive reply; otherwise,
    • the replies must be sent and subsequently acknowledged by the underlying transport service prior to sending the "ok" message in a positive reply.

Briefly, a successful channel close might look like this: 

    C: MSG 0 2 . 247 71
    C: Content-Type: application/beep+xml
    C:
    C: <close number=3D'1' code=3D'200' />
    C: END
    S: RPY 0 2 . 447 46
    S: Content-Type: application/beep+xml
    S:
    S: <ok />
    S: END

Similarly, an unsuccessful channel close might look like this: 

    C: MSG 0 2 . 247 71
    C: Content-Type: application/beep+xml
    C:
    C: <close number=3D'1' code=3D'200' />
    C: END
    S: ERR 0 2 . 447 79
    S: Content-Type: application/beep+xml
    S:
    S: <error code=3D'550'>still working</error>
    S: END

2.3.1.4 The OK Message

When a BEEP peer agrees to close a channel (or release the BEEP session), it sends an "ok" element in a positive reply.

The "ok" element has no attributes and no content.

2.3.1.5 The Error Message

When a BEEP peer declines the creation of a channel, it sends an "error" element in a negative reply, e.g., 

    I: MSG 0 1 . 52 127
    I: Content-Type: application/beep+xml
    I:=20
    I: <start number=3D'2'>
    I:    <profile uri=3D'http://xml.resource.org/profiles/FOO' />
    I: </start>
    I: END
    L: ERR 0 1 . 264 105
    L: Content-Type: application/beep+xml
    L:
    L: <error code=3D'550'>all requested profiles are
    L: unsupported</error>
    L: END

The "error" element has a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content:

  • the "code" attribute is a three-digit reply code meaningful to programs (c.f., Reply Codes);
  • the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and,
  • the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs.
Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used.

In addition, a BEEP peer sends an "error" element whenever:

  • it receives a "MSG" message containing a poorly-formed or unexpected element;
  • it receives a "MSG" message asking to close a channel=20 (or release the BEEP session) and it declines to do so; or
  • a BEEP session is established, the BEEP peer is acting in the listening role, and that BEEP peer is unavailable (in this case, the BEEP acting in the listening role does not send a "greeting" = element).
In the final case, both BEEP peers terminate the session, and it is recommended that a diagnostic entry be logged by both BEEP peers.

2.4 Session Establishment and = Release

When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero on channel zero that = contains a "greeting" element, e.g., 

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 122
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END

Alternatively, if the BEEP peer acting in the listening role is unavailable, it sends a negative reply, e.g., 

    L: <wait for incoming connection>
    I: <open connection>
    L: ERR 0 0 . 0 60
    L: Content-Type: application/beep+xml
    L:
    L: <error code=3D'421' />
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END
    I: <close connection>
    L: <close connection>
    L: <wait for next connection>

and the "greeting" element sent by the BEEP peer acting in the initiating role is ignored. It is recommended that a diagnostic entry be logged by both BEEP peers.

Note that both of these examples imply that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends = its greeting — this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.

When a BEEP peer wants to release the BEEP session, it sends a "close" element with a zero-valued "number" attribute on channel zero. The other BEEP peer indicates its willingness by sending an "ok" element in a positive reply, e.g., 

    C: MSG 0 1 . 52 60
    C: Content-Type: application/beep+xml
    C:
    C: <close code=3D'200' />
    C: END
    S: RPY 0 1 . 264 46
    S: Content-Type: application/beep+xml
    S:
    S: <ok />
    S: END
    I: <close connection>
    L: <close connection>
    L: <wait for next connection>

Alternatively, if the other BEEP doesn't want to release the BEEP session, the exchange might look like this: 

    C: MSG 0 1 . 52 60
    C: Content-Type: application/beep+xml
    C:
    C: <close code=3D'200' />
    C: END
    S: ERR 0 1 . 264 79
    S: Content-Type: application/beep+xml
    S:
    S: <error code=3D'550'>still working</error>
    S: END

If session release is declined, the BEEP session should not be terminated, if possible.

2.5 Transport Mappings

All transport interactions occur in the context of a session — a mapping onto a particular transport service. Accordingly, this memo defines the requirements that must be satisified by any document describing how a particular transport service realizes a BEEP session.

2.5.1 Session Management

A BEEP session is connection-oriented. A mapping document must define:

  • how a BEEP session is established;
  • how a BEEP peer is identified as acting in the listening role;
  • how a BEEP peer is identified as acting in the initiating role;
  • how a BEEP session is released; and,
  • how a BEEP session is terminated.

2.5.2 Message Exchange

A BEEP session is message-oriented. A mapping document must define:

  • how messages are reliably sent and received;
  • how messages on the same channel are received in the same order as they were sent; and,
  • how messages on different channels are sent without ordering constraint.

2.6 Asynchrony

BEEP accomodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel).

2.6.1 Within a Single Channel

A BEEP peer acting in the client role may send multiple "MSG" messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel.

A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel.

Note that in one-to-many exchanges (c.f., Exchange Styles), the reply to the "MSG" message consists of zero or more "ANS" messages followed by a "NUL" message. In this style of exchange, the "ANS" messages comprising the reply may be interleaved. When the BEEP peer acting in the server role signifies the end of the reply by generating the "NUL" message, it may then process the next "MSG" message received for that channel.

2.6.2 Between Different Channels

A BEEP peer acting in the client role may send multiple "MSG" messages on different channels without waiting to receive the corresponding replies. The channels operate independently, in parallel.

A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels.

2.6.3 Pre-emptive Replies

A BEEP peer acting in the server role may send a negative reply before it receives the final "MSG" frame of a message. If it does so, that BEEP peer is obliged to ignore any subsequent "MSG" frames for that message, up to and including the final "MSG" frame.

If a BEEP peer acting in the client role receives a negative reply before it sends the final "MSG" frame for a message, then it is required to send a "MSG" frame with a continuation status of complete (".") and having a zero-length payload.

2.6.4 Interference

If the processing of a particular message has sequencing impacts on other messages (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport mapping.

2.7 Peer-to-Peer Behavior

BEEP is peer-to-peer — as such both peers must be prepared to receive all messages defined in this memo. Accordingly, an initiating BEEP peer capable of acting only in the client role must behave gracefully if it receives a "MSG" message. Accordingly, all profiles must provide an appropriate error message for replying to unexpected "MSG" messages.

As a consequence of the peer-to-peer nature of BEEP, message numbers are unidirectionally-significant. That is, the message numbers in "MSG" messages sent by a BEEP peer acting in the initiating role are unrelated to the message numbers in "MSG" messages sent by a BEEP peer acting in the listening role.

For example, these two messages 

    I: MSG 0 1 . 52 132
    I: Content-Type: application/beep+xml
    I:=20
    I: <start number=3D'1'>
    I:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>=20
    I: </start>
    I: END
    L: MSG 0 1 . 264 128
    L: Content-Type: application/beep+xml
    L:=20
    L: <start number=3D'2'>
    L:    <profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L: </start>
    L: END

refer to different messages sent on channel zero.


 TOC 

3. Transport Security

When a BEEP session is established, plaintext transfer, without privacy, is provided. Accordingly, transport security in BEEP is achieved using an initial tuning profile.

This document defines one profile:

Other profiles may be defined and deployed on a bilateral basis. Note that because of their intimate relationship with the transport = service, a given transport security profile tends to be relevant to a single transport mapping (c.f., Transport = Mappings).

When a channel associated with transport security begins the underlying negotiation process, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers. (If the negotiation process fails, then either BEEP peer may instead terminate the session, and it is recommended that a diagnostic entry be logged.)

A BEEP peer may choose to issue different greetings based on whether privacy is in use, e.g., 

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 122
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END
    I: MSG 0 1 . 52 170
    I: Content-Type: application/beep+xml
    I:=20
    I: <start number=3D'1'>
    I:    <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    I:        <![CDATA[<ready />]]>
    I:    </profile>
    I: </start>
    I: END
    L: RPY 0 1 . 122 133
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    L:     <![CDATA[<proceed />]]>
    L: </profile>
    L: END

        ... successful transport security negotiation ...

    L: RPY 0 0 . 0 264
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile
    L:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    L:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    L:    <profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END

Of course, not all BEEP peers need be as single-minded: 

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 323
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile
    L:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    L:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    L:    <profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END
    I: MSG 0 1 . 52 170
    I: Content-Type: application/beep+xml
    I:=20
    I: <start number=3D'1'>
    I:    <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    I:        <![CDATA[<ready />]]>
    I:    </profile>
    I: </start>
    I: END
    L: RPY 0 1 . 323 133
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    L:     <![CDATA[<proceed />]]>
    L: </profile>
    L: END

        ... failed transport security negotiation ...

    L: RPY 0 0 . 0 323
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile
    L:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    L:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    L:    <profile uri=3D'http://xml.resource.org/profiles/IMXP' />
    L:    <profile uri=3D'http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END

3.1 The TLS Transport Security = Profile

Registration: TLS Transport Security = Profile contains the registration for this profile.

3.1.1 Profile Identification and = Initialization

The TLS transport security profile is identified as: 

    http://xml.resource.org/profiles/TLS

in the BEEP "profile" element during channel creation.

During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "ready" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "ready" element and includes the resulting response in the reply, e.g., 

    C: MSG 0 1 . 52 170
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    C:        <![CDATA[<ready />]]>
    C:    </profile>
    C: </start>
    C: END
    S: RPY 0 1 . 122 133
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    S:     <![CDATA[<proceed />]]>
    S: </profile>
    S: END

Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g., 

    C: MSG 0 1 . 52 185
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    C:        <![CDATA[<ready version=3D"oops" />]]>
    C:    </profile>
    C: </start>
    C: END
    S: RPY 0 1 . 122 205
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/TLS'>
    S:     <![CDATA[<error code=3D'501'>version attribute
    S: poorly formed in &lt;ready&gt; element</error>]]>
    S: </profile>
    S: END

In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.

3.1.2 Message Syntax

TLS Transport Security Profile DTD defines the = messages that are used in the TLS transport security profile.

3.1.3 Message Semantics

3.1.3.1 The Ready Message

The "ready" element has an optional "version" attribute and no content:

  • the "version" element defines the earliest version of TLS acceptable for use.

When a BEEP peer sends the "ready" element, it must not send any further traffic on the underlying transport service until a corresponding reply ("proceed" or "error") is received; similarly, the receiving BEEP peer must wait until any pending replies have been generated and sent before it processes a "ready" element.

3.1.3.2 The Proceed Message

The "proceed" element has no attributes and no content. It is sent as a reply to the "ready" element.

When a BEEP peer receives the "ready" element, it must not send any further traffic on the underlying transport service until it generates a corresponding reply. If the BEEP peer decides to allow transport security negotation, it implicitly closes all channels (including channel zero), and sends the "proceed" element, and awaits the underlying negotiation process for transport security.

When a BEEP peer receives a "proceed" element in reply to its "ready" message, it implicitly closes all channels (including channel zero), and immediately begins the underlying negotiation process for transport security.


 TOC 

4. User Authentication

When a BEEP session is established, anonymous access, without trace information, is provided. Accordingly, user authentication in BEEP is achieved using an initial tuning profile.

This document defines a family of profiles based on SASL mechanisms:

Other profiles may be defined and deployed on a bilateral basis.

Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further, no additional attempts at authentication are allowed.

Note that regardless of transport security and user authentication, authorization is an internal matter for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided (i.e., unauthorized operations might be rejected with error code 530).

4.1 The SASL Family of = Profiles

Registration: SASL Family of Profiles = contains the registration for this profile.

Note that SASL may provide both user authentication and transport = security. Once transport security is successfully negotiated for a BEEP session, then a SASL security layer must not be negotiated; similarly, once any SASL negotiation is successful, a transport security profile must not begin its underlying negotiation process.

Section 4 of the SASL specification[4] requires the following information be supplied by a protocol definition:

service name:
"beep"
initiation sequence:
Creating a channel using a BEEP profile corresponding to a SASL mechanism starts the exchange. An optional parameter corresponding to the "initial response" sent by the client is carried within a "blob" element during channel creation.
exchange sequence:
"Challenges" and "responses" are carried in exchanges of the "blob" element. The "status" attribute of the "blob" element is used both by a server indicating a successful completion of the exchange,=20 and a client aborting the exchange, The server indicates failure of the exchange by sending an "error" = element.
security layer negotiation:
When a security layer starts negotiation, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers.
If a security layer is successfully negotiated, it takes effect immediately following the message that concludes the server's successful completion reply.
use of the authorization identity:
This is made available to all channels for the duration of the BEEP session.

4.1.1 Profile Identification and = Initialization

Each SASL mechanism registered with the IANA is identified as: 

    http://xml.resource.org/profiles/sasl/MECHANISM

where "MECHANISM" is the token assigned to that mechanism by the IANA.

Note that during channel creation, a BEEP peer may provide multiple profiles to the remote peer, e.g., 

    C: MSG 0 1 . 52 209
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile
    C:       uri=3D'http://xml.resource.org/profiles/sasl/ANONYMOUS' />
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' =
/>
    C: </start>
    C: END
    S: RPY 0 1 . 264 99
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP' />
    S: END

During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "blob" element. Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g., 

    C: MSG 0 1 . 52 195
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    C:        <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
    C:    </profile>
    C: </start>
    C: END
    S: RPY 0 1 . 264 190
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    S:     <![CDATA[<error code=3D'534'>authentication mechanism =
is
    S: too weak</error>]]>
    S: </profile>
    S: END

In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.

Otherwise, the server sends a challenge (or signifies success), e.g., 

    C: MSG 0 1 . 52 195
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    C:        <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
    C:    </profile>
    C: </start>
    C: END
    S: RPY 0 1 . 264 183
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri=3D'http://xml.resource.org/profiles/sasl/OTP'>
    S:    =
<![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=3D
                                                           =
</blob>]]>
    S: </profile>
    S: END

Note that this example implies that the "blob" element in the server's reply appears on two lines — this is an artifact of the presentation; in fact, only one line is used.

If a challenge is received, then the client responds and awaits another reply, e.g., 

    C: MSG 1 0 . 0 97
    C: Content-Type: application/beep+xml
    C:
    C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
    C: END
    S: RPY 1 0 . 0 66
    S: Content-Type: application/beep+xml
    S:
    S: <blob status=3D'complete' />
    S: END

Of course, the client could abort the authentication process by sending "<blob status=3D'abort' />" instead.

Alternatively, the server might reject the response with an error: e.g., 

    C: MSG 1 0 . 0 97
    C: Content-Type: application/beep+xml
    C:
    C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
    C: END
    S: ERR 1 1 . 0 60
    S: Content-Type: application/beep+xml
    S:
    S: <error code=3D'535' />
    S: END

Finally, depending on the SASL mechanism, an initialization element may be exchanged unidirectionally during channel creation, e.g., 

    C: MSG 0 1 . 52 145
    C: Content-Type: application/beep+xml
    C:
    C: <start number=3D'1'>
    C:    <profile
    C:        uri=3D'http://xml.resource.org/profiles/sasl/CRAM-MD5' />
    C: </start>
    C: END
    S: RPY 0 1 . 264 197
    S: Content-Type: application/beep+xml
    S:
    S: <profile =
uri=3D'http://xml.resource.org/profiles/sasl/CRAM-MD5'>
    S: =
<![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
                                                  =
jaS5uZXQ+</blob>]]>
    S: </profile>
    S: END

Note that this example implies that the "blob" element in the server's reply appears on two lines — this is an artifact of the presentation; in fact, only one line is used.

4.1.2 Message Syntax

SASL Family of Profiles DTD defines the = messages that are used for each profile in the SASL family.

Note that because many SASL mechanisms exchange binary data, the content of the "blob" element is always a base64-encoded string.

4.1.3 Message Semantics

The "blob" element has an optional "status" attribute, and arbitrary octets as its content:

  • the "status" attribute, if present, takes one of three values:
    abort:
    used by a client to indicate that it is aborting the authentication process;
    complete:
    used by a server to indicate that the exchange is complete and successful; or,
    continue:
    used by either a client or server, otherwise.

Finally, note that SASL's EXTERNAL mechanism works with an "external authentication" service, which is provided by one of:

  • a transport security profile, capable of providing authentication information (e.g., The TLS Transport Security Profile), being active on the connection;
  • a network service, capable of providing strong authentication (e.g., IPSec[12]), underlying the connection; or,
  • a locally-defined security service.
For authentication to succeed, two conditions must hold:
  • an external authentication service must be active; and,
  • if present, the authentication identity must be consistent with the credentials provided by the external authentication service (if the authentication identity is empty, then an authorization identity is automatically derived from the credentials provided by the external authentication service).


 TOC 

5. Registration Templates

5.1 Profile Registration = Template

When a profile is registered, the following information is supplied:

Profile Identification:
specify a URI[10] that authoritatively identifies this profile.
Message Exchanged during Channel Creation:
specify the datatypes that may be exchanged during channel creation.
Messages starting one-to-one exchanges:
specify the datatypes that may be present when an exchange starts.
Messages in positive replies:
specify the datatypes that may be present in a positive reply.
Messages in negative replies:
specify the datatypes that may be present in a negative reply.
Messages in one-to-many exchanges:
specify the datatypes that may be present in a one-to-many exchange.
Message Syntax:
specify the syntax of the datatypes exchanged by the profile.
Message Semantics:
specify the semantics of the datatypes exchanged by the profile.
Contact Information:
specify the postal and electronic contact information for the author of the profile.

5.2 Feature Registration = Template

When a feature for the channel management profile is registered, the following information is supplied:

Feature Identification:
specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-".
Feature Semantics:
specify the semantics of the feature.
Contact Information:
specify the postal and electronic contact information for the author of the feature.


 TOC 

6. Initial Registrations

6.1 Registration: BEEP = Channel Management

Profile Identification:
not applicable
Messages exchanged during Channel Creation:
not applicable
Messages starting one-to-one exchanges:
"start" or "close"
Messages in positive replies:
"greeting", "profile", or "ok"
Messages in negative replies:
"error"
Messages in one-to-many exchanges:
none
Message Syntax:
c.f., BEEP Channel Management DTD
Message Semantics:
c.f., Message Semantics
Contact Information:
c.f., the "Author's Address" section of this memo

6.2 Registration: TLS Transport = Security Profile

Profile Identification:
http://xml.resource.org/pro= files/TLS
Messages exchanged during Channel Creation:
"ready"
Messages starting one-to-one exchanges:
"ready"
Messages in positive replies:
"proceed"
Messages in negative replies:
"error"
Messages in one-to-many exchanges:
none
Message Syntax:
c.f., TLS Transport Security Profile DTD
Message Semantics:
c.f., Message Semantics
Contact Information:
c.f., the "Author's Address" section of this memo

6.3 Registration: SASL Family = of Profiles

Profile Identification:
http://xml.resou= rce.org/profiles/sasl/MECHANISM, where "MECHANISM" is a token registered with the IANA
Messages exchanged during Channel Creation:
"blob"
Messages starting one-to-one exchanges:
"blob"
Messages in positive replies:
"blob"
Messages in negative replies:
"error"
Messages in one-to-many exchanges:
none
Message Syntax:
c.f., SASL Family of Profiles DTD
Message Semantics:
c.f., Message Semantics
Contact Information:
c.f., the "Author's Address" section of this memo

6.4 Registration: = application/beep+xml

MIME media type name:
application
MIME subtype name:
beep+xml
Required parameters:
none
Optional parameters:
charset (defaults to "UTF-8"[13])
Encoding considerations:
This media type may contain binary content; accordingly, when used over a transport that does not permit binary transfer, an appropriate encoding must be applied
Security considerations:
none, per se; however, any BEEP profile which uses this media type must describe its relevant security considerations
Interoperability considerations:
n/a
Published specification:
This media type is a proper subset of the the XML 1.0 specification[2]. Two restrictions are made.
First, no entity references other than the five predefined general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and "&quot;") and numeric entity references may be present.

Second, neither the "XML" declaration (e.g., <?xml version=3D"1.0" ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be present. (Accordingly, if another character set other than UTF-8 is desired, then the "charset" parameter must be present.)

All other XML 1.0 instructions (e.g., CDATA blocks, processing instructions, and so on) are allowed.
Applications which use this media type:
any BEEP profile wishing to make use of this XML 1.0 subset
Additional Information:
none
Contact for further information:
c.f., the "Author's Address" section of this memo
Intended usage:
limited use
Author/Change controller:
the IESG


 TOC 

7. DTDs

7.1 BEEP Channel Management DTD

<!--
  DTD for BEEP Channel Management, as of 2000-10-29


  Refer to this DTD as:

    <!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
               "http://xml.resource.org/profiles/BEEP/beep.dtd">
    %BEEP;
  -->


<!--
  DTD data types:

        entity        syntax/reference     example
        =3D=3D=3D=3D=3D=3D        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
=3D=3D=3D=3D=3D=3D=3D
    a channel number
        CHAN          1..2147483647        1

    authoritative profile identification
        URI          c.f., [RFC-2396]      http://invisible.net/

    one or more feature tokens, seperated by space
        FTRS         NMTOKENS              "magic"

    a language tag
        LANG         c.f., [RFC-1766]      "en", "en-US", etc.

    zero or more language tags
        LOCS         NMTOKENS              "en-US"

    a 3-digit reply code
        XYZ           [1-5][0-9][0-9]      500
-->


<!ENTITY % CHAN       "CDATA">
<!ENTITY % URI        "CDATA">
<!ENTITY % FTRS       "NMTOKENS">
<!ENTITY % LANG       "NMTOKEN">
<!ENTITY % LOCS       "NMTOKEN">
<!ENTITY % XYZ        "CDATA">




<!--
  BEEP messages, exchanged as application/beep+xml

     role       MSG         RSP         ERR
    =3D=3D=3D=3D=3D=3D=3D     =3D=3D=3D         =3D=3D=3D         =
=3D=3D=3D
    I and L                 greeting    error

    I or L      start       profile     error=20

    I or L      close       ok          error
  -->


<!ELEMENT greeting    (profile)*>
<!ATTLIST greeting
          features    %FTRS;            #IMPLIED
          localize    %LOCS;            "i-default">

<!ELEMENT start       (profile)+>
<!ATTLIST start
          number      %CHAN;             #REQUIRED
          serverName  CDATA              #IMPLIED>

<!-- profile element is empty if contained in a greeting -->
<!ELEMENT profile     (#PCDATA)>
<!ATTLIST profile
          uri         %URI;              #REQUIRED
          encoding    (none|base64)      "none">

<!ELEMENT close       (#PCDATA)>
<!ATTLIST close
          number      %CHAN;             "0"
          code        %XYZ;              #REQUIRED
          xml:lang    %LANG;             #IMPLIED>

<!ELEMENT ok          EMPTY>

<!ELEMENT error       (#PCDATA)>
<!ATTLIST error
          code        %XYZ;              #REQUIRED
          xml:lang    %LANG;             #IMPLIED>

7.2 TLS Transport Security Profile = DTD

<!--
  DTD for the TLS Transport Security Profile, as of 2000-09-04


  Refer to this DTD as:

    <!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN"
               "http://xml.resource.org/profiles/TLS/tls.dtd">
    %TLS;
  -->


<!--
  TLS messages, exchanged as application/beep+xml

     role       MSG         RSP         ERR
    =3D=3D=3D=3D=3D=3D      =3D=3D=3D         =3D=3D=3D         =
=3D=3D=3D
    I or L      ready       proceed     error        =20
  -->


<!ELEMENT ready       EMPTY>
<!ATTLIST ready
          version     CDATA              "1">

<!ELEMENT proceed     EMPTY>

7.3 SASL Family of Profiles DTD

<!--
  DTD for the SASL Family of Profiles, as of 2000-09-04


  Refer to this DTD as:

    <!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN"=20
               "http://xml.resource.org/profiles/sasl/sasl.dtd">
    %SASL;
  -->


<!--
  SASL messages, exchanged as application/beep+xml

     role       MSG         RSP         ERR
    =3D=3D=3D=3D=3D=3D      =3D=3D=3D         =3D=3D=3D         =
=3D=3D=3D
    I or L      blob        blob        error
  -->


<!ELEMENT blob        (#PCDATA)>
<!ATTLIST blob
          xml:space   (default|preserve)
                                        "preserve"
          status      (abort|complete|continue)
                                         "continue">

 TOC 

8. Reply Codes

code    meaning
=3D=3D=3D=3D    =3D=3D=3D=3D=3D=3D=3D
200     success

421     service not available

450     requested action not taken
        (e.g., lock already in use)

451     requested action aborted
        (e.g., local error in processing)

454     temporary authentication failure

500     general syntax error
        (e.g., poorly-formed XML)

501     syntax error in parameters
        (e.g., non-valid XML)=20

504     parameter not implemented

530     authentication required

534     authentication mechanism insufficient
        (e.g., too weak, sequence exhausted, etc.)

535     authentication failure

537     action not authorized for user

538     authentication mechanism requires encryption

550     requested action not taken
        (e.g., no requested profiles are acceptable)

553     parameter invalid

554     transaction failed
        (e.g., policy violation)

 TOC 

9. Security Considerations

The BEEP framing mechanism, per se, provides no protection against attack; however, judicious use of initial tuning profiles provides varying degrees of assurance:

  1. If one of the profiles from the SASL family is used, refer to [4]'s Section 9 for a discussion of security considerations.
  2. If the TLS transport security profile is used (or if a SASL security layer is negotiated), then:
    1. A man-in-the-middle may remove the security-related profiles from the BEEP greeting or generate a negative reply to the "ready" element of the TLS transport security profile. A BEEP peer may be configurable to refuse to proceed without an acceptable level of privacy.
    2. A man-in-the-middle may cause a down-negotiation to the weakest cipher suite available. A BEEP peer should be configurable to refuse weak cipher suites.
    3. A man-in-the-middle may modify any protocol exchanges prior to a successful negotiation. Upon completing the negotiation, a BEEP peer must discard previously cached information about the BEEP session.
    As different TLS ciphersuites provide varying levels of security, administrators should carefully choose which ciphersuites are = provisioned.

As BEEP is peer-to-peer in nature, before performing any task associated with a message, each channel should apply the appropriate access control based on the authenticated identity and privacy level associated with the BEEP = session.


 TOC 

References

[1] Freed, = N. and N. Borenstein, "Multipurpose Internet = Mail Extensions (MIME) Part One: Format of Internet Message Bodies", = RFC 2045, November 1996.
[2] World Wide Web = Consortium, "Extensible Markup = Language (XML) 1.0", W3C XML, February 1998.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. O. and P. C. Kocher, "The TLS Protocol Version = 1.0", RFC 2246, January 1999.
[4] Myers, = J.G., "Simple = Authentication and Security Layer (SASL)", RFC 2222, October = 1997.
[5] Rose, = M.T., "Mapping the BEEP Core onto TCP", draft-ietf-beep-tcpmapping-06 = (work in progress), January 2001.
[6] Postel, J., "Transmission Control = Protocol", RFC 793, STD 7, Sep 1981.
[7] Crocker, = D. H. and P. Overell, "Augmented BNF for Syntax = Specifications: ABNF", RFC 2234, November 1997.
[8] Elz, = R. and R. Bush, "Serial Number = Arithmetic", RFC 1982, August 1996.
[9] Alvestrand, H., "Tags for the = Identification of Languages", RFC 1766, March 1995.
[10] Berners-Lee, = T., Fielding, R.T. and = L. Masinter, "Uniform Resource = Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[11] Newman, C., "The One-Time-Password = SASL Mechanism", RFC 2444, October 1998.
[12] Kent, S. = and R. Atkinson, "Security Architecture = for the Internet Protocol", RFC 2401, November 1998.
[13] Yergeau, = F., "UTF-8, a = transformation format of ISO 10646", RFC 2279, January = 1998.
[14] Linn, = J., "Generic = Security Service Application Program Interface, Version 2", RFC = 2078, January 1997.
 TOC 

Author's Address

  Marshall T. Rose
  Invisible Worlds, Inc.
  1179 North McDowell Boulevard
  Petaluma, CA 94954-6559
  US
Phone:  +1 707 789 3700
EMail:  mrose@invisible.net
URI:  http://invisible.net/
 TOC 

Appendix A. Acknowledgements

The author gratefully acknowledges the contributions of: David Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave Crocker provided helpful suggestions on the nature of=20 segmentation in the framing mechanism.


 TOC 

Appendix B. IANA Considerations

The IANA registers "beep" as a GSSAPI[14] service name, as specified in The SASL Family of = Profiles.

The IANA maintains a list of:

For each list, the IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. As a courtesy to developers of non-standards track BEEP profiles and channel management features, the mailing list bxxpwg@invisible.net may be used to solicit commentary.

The IANA makes the registrations specified in Registration: TLS Transport Security = Profile and Registration: SASL Family = of Profiles. It is recommended that the IANA register these profiles using the IANA as a URI-prefix, and populate those URIs with the respective profile registrations.


 TOC 

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC editor function is currently provided by the Internet Society.

 ------=_NextPart_000_00C2_01C07692.6F8D06F0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jan 5 00:09:58 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23366 for ; Fri, 5 Jan 2001 00:09:57 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA13257; Thu, 4 Jan 2001 21:08:46 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA13240 for ; Thu, 4 Jan 2001 21:08:45 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f054vu025958; Thu, 4 Jan 2001 20:57:56 -0800 (PST) Message-ID: <00d001c076d5$90df7890$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Thu, 4 Jan 2001 21:08:39 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CD_01C07692.82714CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] new BEEP tcpmapping draft (in HTML) Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C07692.82714CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_00CD_01C07692.82714CE0 Content-Type: text/html; name="draft-ietf-beep-tcpmapping.html" Content-Disposition: attachment; filename="draft-ietf-beep-tcpmapping.html" Content-Transfer-Encoding: quoted-printable Mapping the BEEP Core onto TCP
 TOC 
Network Working GroupM.T. Rose
Internet-DraftInvisible Worlds, Inc.
Expires: July 5, 2001January 4, 2001

Mapping the = BEEP Core onto TCP
draft-ietf-beep-tcpmapping-06

Status of this Memo

This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet-Drafts as reference material or to = cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/i= etf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html<= /a>.

This Internet-Draft will expire on July 5, 2001.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This memo describes how a BEEP session is mapped onto a single TCP connection.


 TOC 

Table of Contents

    1.  Introduction
     2.  Session Management
     3.  Message Exchange
     3.1  Flow Control
     3.1.1  Channel Creation
     3.1.2  Sending Messages
     3.1.3  Processing SEQ Frames
     3.1.4  Use of Flow Control
     4.  Security Considerations
     §  References
     §  Author's Address
     A.  Acknowledgements
     §  Full Copyright Statement


 TOC 

1. Introduction

This memo describes how a BEEP[1] session is mapped onto a single TCP[2] connection. Refer to Section 2.5 of [1] for an = explanation of the mapping requirements.


 TOC 

2. Session Management

The mapping of BEEP session management onto the TCP service is straight-forward.

A BEEP session is established when a TCP connection is established between two BEEP peers:

  • the BEEP peer that issues a passive TCP OPEN call is termed the listener; and,
  • the BEEP peer that issues an active TCP OPEN call is termed the initiator.

If both peers agree to release a BEEP session (c.f., [1]'s Section 2.4), the peer sending the "ok" reply, immediately issues the TCP CLOSE call. Upon receiving the reply, the other peer immediately issues the TCP CLOSE call.

A BEEP session is terminated when either peer issues the TCP ABORT call, and the TCP connection is subsequently aborted.


 TOC 

3. Message Exchange

The mapping of BEEP exchanges onto the TCP service is less straight-forward.

Messages are reliably sent and received using TCP's SEND and RECEIVE calls. (This also provides ordered delivery of messages on the same channel.)

Although TCP imposes flow control on a per-connection basis, if multiple channels are simultaneously in use on a BEEP session, BEEP must provide a mechanism to avoid starvation and deadlock. To achieve this, BEEP re-introduces a mechanism used by the TCP: window-based flow control — each channel has a sliding window that indicates the number of payload octets that a peer may transmit before receiving further permission.

3.1 Flow Control

Recall from Section 2.2.1.2 of [1] that every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a data frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively.

The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of [3] for a discussion of the arithmetic properties of sequence numbers.

3.1.1 Channel Creation

When a channel is created, the sequence number associated with the first payload octet of the first data frame is 0, and the initial window size for that channel is 4096 octets. After channel creation, a BEEP peer may update the window size by sending a SEQ frame.

If a BEEP peer is asked to create a channel and it is unable to allocate at least 4096 octets for that channel, it must decline creation of the channel, as specified in Section 2.3.1.2 of [1]. Similarly, during establishment of the BEEP session, if the BEEP peer acting in the listening role is unable to allocate at least 4096 octets for channel 0, then it must return a negative reply, as specified in Section 2.4 of [1], instead of a greeting.

3.1.2 Sending Messages

Before a message is sent, the sending BEEP peer must ensure that the size of the payload is within the window advertised by the receiving BEEP peer. If not, it has three choices:

  • if the window would allow for at least one payload octet to be sent, the BEEP peer may segment the message and start by sending a smaller data frame (up to the size of the remaining window);
  • the BEEP peer may delay sending the message until the window becomes larger; or,
  • the BEEP peer may signal to its application that it is unable to send the message, allowing the application to try again at a later time (or perhaps signaling its application when a larger window is = available).
The choice is implementation-dependent, although it is recommended that the application using BEEP be given a mechanism for influencing the decision.

3.1.3 Processing SEQ Frames

As an application accepts responsibility for incoming data frames, its BEEP peer should send SEQ frames to advertise a new window.

The ABNF[4] for a SEQ frame is: 

    seq        =3D "SEQ" SP channel SP ackno SP window CR LF

    ackno      =3D seqno

    window     =3D size

    ; channel, seqno, and size are defined in Section 2.2.1 of [1].

The SEQ frame has three parameters:

  • a channel number;
  • an acknowledgement number, that indicates the value of the next sequence number that the sender is expecting to receive on this channel; and,
  • a window size, that indicates the number of payload octets beginning with the one indicated by the acknowledgement number that the sender is expecting to receive on this channel.
A single space character (decimal code 32, " ") separates each component. The SEQ frame is terminated with a CRLF pair.

When a SEQ frame is received, if any of the channel number, acknowledgement number, or window size cannot be determined or is invalid, then the BEEP session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.

3.1.4 Use of Flow Control

The key to successful use of flow control within BEEP is to balance performance and fairness:

  • large messages should be segmented into frames no larger than two-thirds of TCP's negotiated maximum segment size;
  • frames for different channels with traffic ready to send should be sent in a round-robin fashion;
  • each time a frame is received, a SEQ frame should be sent whenever the window size that will be sent is at least one half of the buffer space available to this channel; and,
  • if the transport service presents multiple frames to a BEEP peer simultaneously, then a single consolidating SEQ frame may be sent.
In order to avoid pathological interactions with the transport service, it is important that a BEEP peer advertise windows based on available buffer space, to allow data to be read from the transport service as soon as available. Further, SEQ frames for a channel must have higher priority than messages for that channel.

Implementations may wish to provide queue management facilities to the application using BEEP, e.g., channel priorities, (relative) buffer allocations, and so on. In particular, implementations should not allow a given channel to monopolize the underlying transport window (e.g., slow readers should get small windows).

In addition, where possible, implementations should support transport layer APIs that convey congestion information. These APIs allow an implementation to determine its share of the available bandwidth, and also be notified of changes in the estimated path bandwidth. Note that when a BEEP session has multiple channels that are simultaneously exchanging large messages, implementations without access to this information may have uncertain fairness and progress properties during times of network congestion.

Finally, implementors should follow the guidelines given in the relevant portions of RFC1122[5] that deal with flow control=20 (and bear in mind that issues such as retransmission, while they interact with flow control in TCP, are not applicable to this memo). For example, Section 4.2.2.16 of RFC1122[5] indicates that a "receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left" and then discusses the impact of this rule on unacknowledged data. In the context of mapping BEEP onto a single TCP connection, only the portions concerning flow control should be implemented.


 TOC 

4. Security Considerations

Consult Section [1]'s Section 9 for a discussion of security issues.


 TOC 

References

[1] Rose, = M.T., "The Blocks Extensible Exchange Protocol Core", = draft-ietf-beep-framework-10 (work in progress), January 2001.
[2] Postel, J., "Transmission Control = Protocol", RFC 793, STD 7, Sep 1981.
[3] Elz, = R. and R. Bush, "Serial Number = Arithmetic", RFC 1982, August 1996.
[4] Crocker, = D. H. and P. Overell, "Augmented BNF for Syntax = Specifications: ABNF", RFC 2234, November 1997.
[5] Braden, = R., "Requirements = for Internet Hosts -- Communication Layers", RFC 1122, October = 1989.
 TOC 

Author's Address

  Marshall T. Rose
  Invisible Worlds, Inc.
  1179 North McDowell Boulevard
  Petaluma, CA 94954-6559
  US
Phone:  +1 707 789 3700
EMail:  mrose@invisible.net
URI:  http://invisible.net/
 TOC 

Appendix A. Acknowledgements

The author gratefully acknowledges the contributions of: Dave Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge, Vernon Schryver, and, Joe Touch. In particular, Dave Crocker provided helpful suggestions on the nature of=20 flow control in the mapping.


 TOC 

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC editor function is currently provided by the Internet Society.

 ------=_NextPart_000_00CD_01C07692.82714CE0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jan 5 13:08:38 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18441 for ; Fri, 5 Jan 2001 13:08:37 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA17003; Fri, 5 Jan 2001 10:06:08 -0800 (PST) Received: from ns1.tenzing.com (ns1.tenzing.com [63.115.0.10]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA16260 for ; Fri, 5 Jan 2001 08:41:23 -0800 (PST) Received: from ts-exch01.tenzing.com (ts-exch01.tenzing.com [63.115.0.25]) by ns1.tenzing.com (8.9.3/8.9.3) with ESMTP id IAA08930 for ; Fri, 5 Jan 2001 08:41:04 -0800 Received: from torus (63.115.3.217 [63.115.3.217]) by ts-exch01.tenzing.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZDY36F49; Fri, 5 Jan 2001 08:41:05 -0800 Received: from seh by torus with local (Exim 3.12 #1 (Debian)) id 14EZsR-0002b0-00 for ; Fri, 05 Jan 2001 08:38:03 -0800 To: bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] updated I-Ds References: <00ba01c076d5$672abe60$8753cf3f@FATORA> Organization: Tenzing Communications Inc. From: "Steven E. Harris" Date: 05 Jan 2001 08:38:03 -0800 In-Reply-To: "Marshall T. Rose"'s message of "Thu, 4 Jan 2001 21:07:29 -0800" Message-ID: <87bstmvtsk.fsf@torus.tenzing.com> Lines: 9 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net BEEP is looking better and better. I've been away from it for a while (missed most of the "ANS" one-to-many stuff), but the latest drafts brought me up to date. Does anyone have any tales to share BEEP being used in an application? -- Steven E. Harris :: steven.harris@tenzing.com Tenzing :: http://www.tenzing.com _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 8 07:28:53 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00697 for ; Mon, 8 Jan 2001 07:28:52 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id EAA03151; Mon, 8 Jan 2001 04:27:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id EAA03128 for ; Mon, 8 Jan 2001 04:27:27 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00289; Mon, 8 Jan 2001 07:27:25 -0500 (EST) Message-Id: <200101081227.HAA00289@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: bxxpwg@invisible.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 08 Jan 2001 07:27:25 -0500 Subject: [BXXPwg] I-D ACTION:draft-ietf-beep-framework-11.txt Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Blocks Extensible Exchange Protocol Working Group of the IETF. Title : The Blocks Extensible Exchange Protocol Core Author(s) : M. Rose Filename : draft-ietf-beep-framework-11.txt Pages : 58 Date : 05-Jan-01 This memo describes a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-beep-framework-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-beep-framework-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-beep-framework-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010105145614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-beep-framework-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-beep-framework-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010105145614.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 8 07:39:04 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00698 for ; Mon, 8 Jan 2001 07:28:52 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id EAA03107; Mon, 8 Jan 2001 04:27:22 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id EAA03092 for ; Mon, 8 Jan 2001 04:27:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00270; Mon, 8 Jan 2001 07:27:18 -0500 (EST) Message-Id: <200101081227.HAA00270@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: bxxpwg@invisible.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 08 Jan 2001 07:27:18 -0500 Subject: [BXXPwg] I-D ACTION:draft-ietf-beep-tcpmapping-06.txt Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Blocks Extensible Exchange Protocol Working Group of the IETF. Title : Mapping the BEEP Core onto TCP Author(s) : M. Rose Filename : draft-ietf-beep-tcpmapping-06.txt Pages : 13 Date : 05-Jan-01 This memo describes how a BXXP session is mapped onto a single TCP connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-beep-tcpmapping-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-beep-tcpmapping-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-beep-tcpmapping-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010105145602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-beep-tcpmapping-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-beep-tcpmapping-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010105145602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 12:28:21 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11320 for ; Mon, 15 Jan 2001 12:28:20 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA26541; Mon, 15 Jan 2001 09:26:43 -0800 (PST) Received: from devmail.dev.tivoli.com (devmail.dev.tivoli.com [208.230.244.136]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA26457 for ; Mon, 15 Jan 2001 09:19:06 -0800 (PST) Received: from tivoli.com (wharold.dev.tivoli.com [146.84.43.109]) by devmail.dev.tivoli.com (8.9.1/8.9.1) with ESMTP id LAA05501 for ; Mon, 15 Jan 2001 11:19:00 -0600 (CST) Message-ID: <3A633100.CE5B9229@tivoli.com> Date: Mon, 15 Jan 2001 11:18:56 -0600 From: Ward Harold Organization: Tivoli Systems X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: bxxpwg@lists.invisibleworlds.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [BXXPwg] Multichannel Protocol Design Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit If I'm designing a protocol with command and data channels, e.g., commands flow from the initiating peer to the listener and data flows back from the listener over one or more data channels, I assume the obvious approach would be to create command and data profiles for the respective channels. Having done that what is the obvious approach to coordinating channel creation and interaction, i.e., making sure that data channels get created as necessary, that the data requested gets delivered, etc.? Is it correct to say that beyond the channel management mechanism BEEP doesn't provide any explicit support for this aspect of protocol design? ... WkH _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 17:41:43 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17024 for ; Mon, 15 Jan 2001 17:41:42 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28731; Mon, 15 Jan 2001 14:40:40 -0800 (PST) Received: from ns1.tenzing.com (ns1.tenzing.com [63.115.0.10]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28718 for ; Mon, 15 Jan 2001 14:40:39 -0800 (PST) Received: from ts-exch01.tenzing.com (ts-exch01.tenzing.com [63.115.0.25]) by ns1.tenzing.com (8.9.3/8.9.3) with ESMTP id SAA03079 for ; Mon, 15 Jan 2001 18:40:28 -0800 Received: from torus (63.115.3.217 [63.115.3.217]) by ts-exch01.tenzing.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CS1BYSXG; Mon, 15 Jan 2001 14:40:24 -0800 Received: from seh by torus with local (Exim 3.12 #1 (Debian)) id 14IIF3-0004Qa-00 for ; Mon, 15 Jan 2001 14:36:45 -0800 To: bxxpwg@lists.invisibleworlds.com Organization: Tenzing Communications Inc. From: "Steven E. Harris" Date: 15 Jan 2001 14:36:45 -0800 Message-ID: <87vgrgl9xe.fsf@torus.tenzing.com> Lines: 63 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BXXPwg] Definition of SEQ fields in TCP mapping document Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Section 3.1.3 of draft-ietf-beep-tcpmapping-06 defines the "ackno" field of a SEQ message as: ,---- | an acknowledgement number, that indicates the value of the next | sequence number that the sender is expecting to receive on this | channel `---- While at one point I found that easy to understand, my reaction to it now is, "Huh?" I've been envisioning a scheme in which SEQ frames could be sent at times somewhat independent of when an incoming frame arrives. It seems to me that the the window management messages must be consistent only among themselves, not with respect to the "current" byte count on the channel as suggested above. If I approve 4096 bytes on a given channel, starting a byte 0, then, after having received 3000 bytes decide to approve another 2048 bytes (since my application is consuming its buffer quickly), then the second SEQ message should be able to specify 3000 as its ackno, with the window equal to (4096 - 3000) + 2048 = 3144. That is, assuming we'd bother with the first SEQ (it's actually implicit in channel creation, I think), we'd send SEQ 1 0 4096 ... later ... SEQ 1 3000 3144 It shouldn't matter that in between the time I've decided to compose and send this second SEQ message that more bytes may have arrived. (Maybe by the time the SEQ goes out I've received 3177 bytes.) What should matter is that the sending side could still do the proper math to know when to hold back its frames. To continue the above example, the sender might say, "I've sent 3300 bytes. With this latest SEQ message in mind, I can send another 3144 - (3300 - 3000) = 2844 bytes before requiring further approval." Is this correct? If so, we should massage the "ackno" definition quoted above, as it sounds too stringent. Also, why can't a SEQ message be "predictive," with the "ackno" higher than what's actually been received? The math still works out the same. Consider: SEQ 1 0 4096 ... later ... SEQ 1 4096 2048 Again, when the sender gets this SEQ, it could say, "I've sent 3300 bytes. With this latest SEQ, I can send another 2048 - (3300 - 4096) = 2048 + 796 = 2844 bytes before requiring further approval." Tada! Permitting such a "forward-looking" SEQ simplifies some of the bookkeeping required to compose SEQ messages by decoupling the ackno from the _actual_ received byte count. Is this heresy? -- Steven E. Harris :: steven.harris@tenzing.com Tenzing :: http://www.tenzing.com _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 18:00:04 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17255 for ; Mon, 15 Jan 2001 18:00:03 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28906; Mon, 15 Jan 2001 14:59:03 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28893 for ; Mon, 15 Jan 2001 14:59:03 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0FMl0323197; Mon, 15 Jan 2001 14:47:00 -0800 (PST) Message-ID: <034901c07f46$b9049f20$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Ward Harold" , Cc: "Marshall Rose" References: <3A633100.CE5B9229@tivoli.com> Subject: Re: [BXXPwg] Multichannel Protocol Design Date: Mon, 15 Jan 2001 14:58:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit > If I'm designing a protocol with command and data channels, e.g., > commands flow from the initiating peer to the listener and data flows > back from the listener over one or more data channels, I assume the > obvious approach would be to create command and data profiles for the > respective channels. Having done that what is the obvious approach to > coordinating channel creation and interaction, i.e., making sure that > data channels get created as necessary, that the data requested gets > delivered, etc.? Is it correct to say that beyond the channel management > mechanism BEEP doesn't provide any explicit support for this aspect of > protocol design? hi. from your description, it sounds like you're organizing your application around 1+N channels, where the first channel is orchestrating the behavior of the other N channels. if this is not the case, ignore the rest of the message and explain what you're trying to do. if this is the case, then you're right: the channel management mechanism doesn't provide any way for you to coordinate the behavior of the channels you create. you can define your own profile to do what you want. for example, i know of a family of profiles that do queries against a datastore and return document names. each profile has its own custom query language. there is another profile that does only logical operations on result sets, each "term" in it's query language consists of an arbitrary string and a channel number. the semantics are pretty simple: give that existing channel this string, take the results as the thing to work on next. this is one of many possible ways of structuring an application. your job is to decide what makes the most sense for your application. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 18:28:34 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17515 for ; Mon, 15 Jan 2001 18:28:33 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA29136; Mon, 15 Jan 2001 15:27:33 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA29122 for ; Mon, 15 Jan 2001 15:27:32 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0FNFZ323275; Mon, 15 Jan 2001 15:15:35 -0800 (PST) Message-ID: <039e01c07f4a$b72e82c0$8753cf3f@FATORA> From: "Marshall T. Rose" To: , "Steven E. Harris" Cc: "Marshall Rose" References: <87vgrgl9xe.fsf@torus.tenzing.com> Subject: Re: [BXXPwg] Definition of SEQ fields in TCP mapping document Date: Mon, 15 Jan 2001 15:27:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit > Is this heresy? yes. it's called "ackno" because it's acknowledging something that's received. an implementation is free to implement whatever algorithms it finds useful providing that its external behavior matches the specification. what this means is that you're free to send SEQs asynchronously, but when you send them, ackno must accurately reflect what you've received. you can just as easily get the effect you seek by playing with the size (parameter 3) instead of the ackno (parameter 2). /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 18:49:23 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17754 for ; Mon, 15 Jan 2001 18:49:22 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA29406; Mon, 15 Jan 2001 15:48:13 -0800 (PST) Received: from devmail.dev.tivoli.com (devmail.dev.tivoli.com [208.230.244.136]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA29241 for ; Mon, 15 Jan 2001 15:39:30 -0800 (PST) Received: from tivoli.com (wharold.dev.tivoli.com [146.84.43.109]) by devmail.dev.tivoli.com (8.9.1/8.9.1) with ESMTP id RAA08777; Mon, 15 Jan 2001 17:39:27 -0600 (CST) Message-ID: <3A638A2B.E6E5A072@tivoli.com> Date: Mon, 15 Jan 2001 17:39:23 -0600 From: Ward Harold Organization: Tivoli Systems X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Marshall T. Rose" CC: bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] Multichannel Protocol Design References: <3A633100.CE5B9229@tivoli.com> <034901c07f46$b9049f20$8753cf3f@FATORA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit "Marshall T. Rose" wrote: > hi. from your description, it sounds like you're organizing your application > around 1+N channels, where the first channel is orchestrating the behavior > of the other N channels. if this is not the case, ignore the rest of the > message and explain what you're trying to do. A 1+N organization is exactly what I'm thinking about. I am envisioning the peer in the Initiator role creating the "command" channel and the Listening peer creating n, where n <= N, "data" channels depending on the command issued, the object(s) requested, etc. I hadn't thought of using a profile to coordinate the behavior of the channels. ... WkH _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 19:24:09 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18027 for ; Mon, 15 Jan 2001 19:24:09 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA29663; Mon, 15 Jan 2001 16:23:08 -0800 (PST) Received: from ns1.tenzing.com (ns1.tenzing.com [63.115.0.10]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA29647 for ; Mon, 15 Jan 2001 16:23:07 -0800 (PST) Received: from ts-exch01.tenzing.com (ts-exch01.tenzing.com [63.115.0.25]) by ns1.tenzing.com (8.9.3/8.9.3) with ESMTP id UAA03798 for ; Mon, 15 Jan 2001 20:23:11 -0800 Received: from torus (63.115.3.217 [63.115.3.217]) by ts-exch01.tenzing.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CS1BYT1H; Mon, 15 Jan 2001 16:23:07 -0800 Received: from seh by torus with local (Exim 3.12 #1 (Debian)) id 14IJqS-0004uj-00 for ; Mon, 15 Jan 2001 16:19:28 -0800 To: bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] Definition of SEQ fields in TCP mapping document References: <87vgrgl9xe.fsf@torus.tenzing.com> <039e01c07f4a$b72e82c0$8753cf3f@FATORA> Organization: Tenzing Communications Inc. From: "Steven E. Harris" Date: 15 Jan 2001 16:19:28 -0800 In-Reply-To: "Marshall T. Rose"'s message of "Mon, 15 Jan 2001 15:27:02 -0800" Message-ID: <87puhol567.fsf@torus.tenzing.com> Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net "Marshall T. Rose" writes: > yes. it's called "ackno" because it's acknowledging something that's > received. [...] > what this means is that you're free to send SEQs asynchronously, but > when you send them, ackno must accurately reflect what you've > received. Okay. But it seems impossible for an outgoing SEQ's ackno to correspond to *exactly* the number of bytes that have been received, as the incoming and outgoing activity can be happening concurrently. Is it sufficient to say that the ackno must be *less than or equal* to the number of bytes received when the SEQ message is composed? > you can just as easily get the effect you seek by playing with the > size (parameter 3) instead of the ackno (parameter 2). Okay, I see your point there. -- Steven E. Harris :: steven.harris@tenzing.com Tenzing :: http://www.tenzing.com _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 15 22:05:34 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20323 for ; Mon, 15 Jan 2001 22:05:34 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id TAA00390; Mon, 15 Jan 2001 19:04:17 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id TAA00376 for ; Mon, 15 Jan 2001 19:04:16 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0G2qE323813; Mon, 15 Jan 2001 18:52:14 -0800 (PST) Message-ID: <004801c07f68$fdec9300$8753cf3f@FATORA> From: "Marshall T. Rose" To: , "Steven E. Harris" Cc: "Marshall Rose" References: <87vgrgl9xe.fsf@torus.tenzing.com><039e01c07f4a$b72e82c0$8753cf3f@FATORA> <87puhol567.fsf@torus.tenzing.com> Subject: Re: [BXXPwg] Definition of SEQ fields in TCP mapping document Date: Mon, 15 Jan 2001 19:04:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit > Okay. But it seems impossible for an outgoing SEQ's ackno to > correspond to *exactly* the number of bytes that have been received, > as the incoming and outgoing activity can be happening > concurrently. Is it sufficient to say that the ackno must be *less > than or equal* to the number of bytes received when the SEQ message is > composed? i'll quote my previous message: > an implementation is free to implement whatever algorithms it finds useful > providing that its external behavior matches the specification. what this means is that if you've structured your implementation so that you don't know the exact number when you generate a SEQ, then the external behavior of your implementation should not indicate this. so, using a policy like "less than or equal" is likely to keep up appearances. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 16 16:58:58 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22329 for ; Tue, 16 Jan 2001 16:58:57 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA06924; Tue, 16 Jan 2001 13:56:22 -0800 (PST) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA06905 for ; Tue, 16 Jan 2001 13:56:21 -0800 (PST) Received: from norman.cp10.es.xerox.com (norman.cp10.es.xerox.com [13.240.124.12]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id QAA29282 for ; Tue, 16 Jan 2001 16:56:20 -0500 (EST) Received: from x-crt-es-ms1.es.cp10.es.xerox.com (x-crt-es-ms1.cp10.es.xerox.com [13.240.124.41]) by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id NAA01654 for ; Tue, 16 Jan 2001 13:58:32 -0800 (PST) Received: by x-crt-es-ms1.cp10.es.xerox.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 13:56:16 -0800 Message-ID: <918C79AB552BD211A2BD00805F15CE85045E0FB2@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: bxxpwg@lists.invisibleworlds.com Date: Tue, 16 Jan 2001 13:56:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [BXXPwg] A couple of questions Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Hi, I followed some the initial work on BEEP, but later got busy with too many other things. I am now trying to catch up and have just eyed through the latest drafts dated January 4 and as result I have a few comments and questions: 1) The documents start looking pretty good and I assume that you are soon getting ready to submit them to the IESG. Is this a correct understanding of where you are? 2) In was told earlier on that actual code was being written in parallel to the specs. Is any of that code available as open source or are there any plans to make that happen? 3) I can't find anything mentioned about a default port or URL scheme to go with BEEP. Is that by design and would port numbers and URL schemes be defined by the applications that sit on top of BEEP? Thankful for any clarifications on these questions, Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 16 17:14:55 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22565 for ; Tue, 16 Jan 2001 17:14:55 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA07114; Tue, 16 Jan 2001 14:13:08 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id OAA07096 for ; Tue, 16 Jan 2001 14:13:04 -0800 (PST) Received: (qmail 29199 invoked by uid 3039); 16 Jan 2001 22:12:55 -0000 Message-ID: <20010116171255.A25486@wachob.com> Date: Tue, 16 Jan 2001 17:12:55 -0500 From: Gabe Wachob To: "Manros, Carl-Uno B" , bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] A couple of questions References: <918C79AB552BD211A2BD00805F15CE85045E0FB2@x-crt-es-ms1.cp10.es.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <918C79AB552BD211A2BD00805F15CE85045E0FB2@x-crt-es-ms1.cp10.es.xerox.com>; from Manros, Carl-Uno B on Tue, Jan 16, 2001 at 01:56:13PM -0800 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net On Tue, Jan 16, 2001 at 01:56:13PM -0800, Manros, Carl-Uno B wrote: > Hi, > > I followed some the initial work on BEEP, but later got busy with too many > other things. > > I am now trying to catch up and have just eyed through the latest drafts > dated January 4 and as result I have a few comments and questions: > > 1) The documents start looking pretty good and I assume that you are soon > getting ready to submit them to the IESG. Is this a correct understanding of > where you are? > > 2) In was told earlier on that actual code was being written in parallel to > the specs. Is any of that code available as open source or are there any > plans to make that happen? The PyBXXP (Python implementation) is open source and is available at bxxp.org. If you are a python person, I would appreciate any help you can give. > 3) I can't find anything mentioned about a default port or URL scheme to go > with BEEP. Is that by design and would port numbers and URL schemes be > defined by the applications that sit on top of BEEP? It would seem to me that a bxxp well-known port number should be defined, unless there is a requirement be passed "up" to all applications on top of beep that a port must be part of the URL for the bxxp peer. I don't think requiring a port number is a good thing. Since (as I understand it), specific channel numbers are *not* assigned to specific applications (unlike port numbers), that the only thing an application would need to specify is an endpoint for a bxxp peer (endpoint being ip address and port). But this is part of the TCP Mapping, I'm guessing, which I haven't looked at in detail very recently. To restate: In the modal case, an app that works on top of BXXP only requires a IP address (in the TCP Mapping) to specify a peer. Authentication and TLS may have further naming requirements for specifying the peer endpoint. Is this right? -Gabe > > Thankful for any clarifications on these questions, > > Carl-Uno > > Carl-Uno Manros > Manager, Print Services > Xerox Architecture Center - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 16 17:37:48 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22805 for ; Tue, 16 Jan 2001 17:37:47 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA07345; Tue, 16 Jan 2001 14:36:47 -0800 (PST) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.249.11]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA07233; Tue, 16 Jan 2001 14:28:20 -0800 (PST) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 14:33:08 -0800 Message-ID: From: Kris Magnusson To: "'Gabe Wachob'" , "Manros, Carl-Uno B" , bxxpwg@lists.invisibleworlds.com Cc: Jay Kint Subject: RE: [BXXPwg] A couple of questions Date: Tue, 16 Jan 2001 14:33:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net You might also check with Jay Kint (jkint@invisible.net) about the Python work he has been doing. It might make sense for you guys to put your heads together. ........... kris -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Tuesday, January 16, 2001 2:13 PM To: Manros, Carl-Uno B; bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] A couple of questions On Tue, Jan 16, 2001 at 01:56:13PM -0800, Manros, Carl-Uno B wrote: > Hi, > > I followed some the initial work on BEEP, but later got busy with too many > other things. > > I am now trying to catch up and have just eyed through the latest drafts > dated January 4 and as result I have a few comments and questions: > > 1) The documents start looking pretty good and I assume that you are soon > getting ready to submit them to the IESG. Is this a correct understanding of > where you are? > > 2) In was told earlier on that actual code was being written in parallel to > the specs. Is any of that code available as open source or are there any > plans to make that happen? The PyBXXP (Python implementation) is open source and is available at bxxp.org. If you are a python person, I would appreciate any help you can give. > 3) I can't find anything mentioned about a default port or URL scheme to go > with BEEP. Is that by design and would port numbers and URL schemes be > defined by the applications that sit on top of BEEP? It would seem to me that a bxxp well-known port number should be defined, unless there is a requirement be passed "up" to all applications on top of beep that a port must be part of the URL for the bxxp peer. I don't think requiring a port number is a good thing. Since (as I understand it), specific channel numbers are *not* assigned to specific applications (unlike port numbers), that the only thing an application would need to specify is an endpoint for a bxxp peer (endpoint being ip address and port). But this is part of the TCP Mapping, I'm guessing, which I haven't looked at in detail very recently. To restate: In the modal case, an app that works on top of BXXP only requires a IP address (in the TCP Mapping) to specify a peer. Authentication and TLS may have further naming requirements for specifying the peer endpoint. Is this right? -Gabe > > Thankful for any clarifications on these questions, > > Carl-Uno > > Carl-Uno Manros > Manager, Print Services > Xerox Architecture Center - Xerox Corporation > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 > Phone +1-310-333 8273, Fax +1-310-333 5514 > Email: manros@cp10.es.xerox.com > > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 16 18:11:08 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23155 for ; Tue, 16 Jan 2001 18:11:07 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA07727; Tue, 16 Jan 2001 15:10:05 -0800 (PST) Received: from netforensics.com ([208.37.243.70]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA07708 for ; Tue, 16 Jan 2001 15:10:04 -0800 (PST) Received: from netforensics.com (azim@piranha.netforensics.com [146.127.98.75]) by netforensics.com (8.8.7/8.8.7) with ESMTP id OAA17343 for ; Tue, 16 Jan 2001 14:22:47 -0500 Message-ID: <3A64D4DF.AEC0D460@netforensics.com> Date: Tue, 16 Jan 2001 18:10:23 -0500 From: "Azim, Ozakil" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: bxxpwg@lists.invisibleworlds.com References: Content-Type: multipart/alternative; boundary="------------74A9442136CD7316BB5AC3FA" Subject: [BXXPwg] BXXP C Implementation Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net --------------74A9442136CD7316BB5AC3FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Just wanted to check if anyone is working on a C based implementation for BXXP. I didn't find any reference to that on bxxp.org site. Thanks, Azim -- Azim, Ozakil - azim@netforensics.com Product Engineering http://www.netforensics.com --------------74A9442136CD7316BB5AC3FA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hi,
Just wanted to check if anyone is working on a C based implementation for BXXP.
I didn't find any reference to that on bxxp.org site.
Thanks,
Azim
-- 
Azim, Ozakil - azim@netforensics.com
Product Engineering
http://www.netforensics.com
  --------------74A9442136CD7316BB5AC3FA-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 16 18:41:19 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23395 for ; Tue, 16 Jan 2001 18:41:19 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA08036; Tue, 16 Jan 2001 15:40:19 -0800 (PST) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.249.11]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA07780; Tue, 16 Jan 2001 15:13:11 -0800 (PST) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 15:17:59 -0800 Message-ID: From: Kris Magnusson To: "'Azim, Ozakil'" , bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] BXXP C Implementation Date: Tue, 16 Jan 2001 15:17:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08012.907FD5FC" Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08012.907FD5FC Content-Type: text/plain; charset="iso-8859-1" We are in fact working on the design for a C-based BEEP library. But don't let that stop anyone from pitching in . . . =) .......... kris -----Original Message----- From: Azim, Ozakil [mailto:azim@netforensics.com] Sent: Tuesday, January 16, 2001 3:10 PM To: bxxpwg@lists.invisibleworlds.com Subject: [BXXPwg] BXXP C Implementation Hi, Just wanted to check if anyone is working on a C based implementation for BXXP. I didn't find any reference to that on bxxp.org site. Thanks, Azim -- Azim, Ozakil - azim@netforensics.com Product Engineering http://www.netforensics.com ------_=_NextPart_001_01C08012.907FD5FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We are=20 in fact working on the design for a C-based BEEP = library. = But don't let=20 that stop anyone from pitching in . . . =3D)
 
.......... kris
-----Original Message-----
From: Azim, Ozakil=20 [mailto:azim@netforensics.com]
Sent: Tuesday, January 16, = 2001 3:10=20 PM
To: bxxpwg@lists.invisibleworlds.com
Subject: = [BXXPwg]=20 BXXP C Implementation

Hi,
Just =
wanted to check if anyone is working on a C based implementation for =
BXXP.
I didn't find any reference to that on bxxp.org =
site.
Thanks,
Azim
-- 
Azim, Ozakil - azim@netforensics.com
Product Engineering
http://www.netforensics.com =20
------_=_NextPart_001_01C08012.907FD5FC-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jan 16 18:46:39 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23441 for ; Tue, 16 Jan 2001 18:46:39 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA08150; Tue, 16 Jan 2001 15:45:37 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA08131 for ; Tue, 16 Jan 2001 15:45:37 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0GNWD326821; Tue, 16 Jan 2001 15:32:13 -0800 (PST) Message-ID: <004801c08016$382e7b20$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Manros, Carl-Uno B" , Cc: "Marshall Rose" References: <918C79AB552BD211A2BD00805F15CE85045E0FB2@x-crt-es-ms1.cp10.es.xerox.com> Subject: Re: [BXXPwg] A couple of questions Date: Tue, 16 Jan 2001 15:44:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit > 1) The documents start looking pretty good and I assume that you are soon > getting ready to submit them to the IESG. Is this a correct understanding of > where you are? the IESG is completing their review at present. > 3) I can't find anything mentioned about a default port or URL scheme to go > with BEEP. Is that by design and would port numbers and URL schemes be > defined by the applications that sit on top of BEEP? when you define an application protocol using BEEP, you define how to determine the port number. take a look at the last paragraph in Section 2 of http://search.ietf.org/internet-drafts/draft-ietf-syslog-reliable-02.txt for an example. /mtr ps: that might be "-03" by the time you read this message. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jan 17 16:56:58 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26683 for ; Wed, 17 Jan 2001 16:56:57 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA16577; Wed, 17 Jan 2001 13:55:36 -0800 (PST) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA16563 for ; Wed, 17 Jan 2001 13:55:36 -0800 (PST) Received: from w2kbwyman (sdn-ar-003casfrMP064.dialsprint.net [158.252.210.66]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA24244 for ; Wed, 17 Jan 2001 13:55:30 -0800 (PST) Message-ID: <02cd01c080d0$390efb90$a8d1fc9e@accrue.com> Reply-To: "Bob Wyman" From: "Bob Wyman" To: Date: Wed, 17 Jan 2001 13:55:35 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CA_01C0808D.2A345270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_02CA_01C0808D.2A345270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the things I find very frustrating with a number of network = protocols is that when you get the "service not available" message, you = don't get answers to the questions: "Why not?" and "When will it be = back?." Few protocols allow you to do much more than simply poll the = darned server from time to time in the hope that the thing will return = to life. In many cases, that polling can simply make matters worse, = since the unavailability of the service may be because too many people = are trying to access it... It would be very useful, I think, if BXXP could expand it's = "unavailable" error messages to include: 1) Service permanently unavailable (i.e. Don't ever try again!) 2) Service temporarily unavailable (i.e. We'll be back) This would allow clients to do more rational things in response to being = rejected. Cases of temporary unavailability include things like startup, = shutdown, server is overloaded and can't take more connects, databases = are being reorganized, backups are being performed, etc. These are all = cases where it would be good to refuse new connections without = discouraging people from coming back later. Ideally, the protocol would = support returning an estimated time to availability in the case of a = temporary shut-out. It would also, I think, be very useful to provide for a redirection = response, very much like that which we find in HTTP. I realize that one = can buy all sorts of fancy gear to do load balancing for you, and I = realize that once you've got a connection to a BXXP server and start = talking a profile, that profile could implement redirection, however, it = is still likely that in many cases, scalability of the solution is going = to be enhanced by allowing the BXXP servers themselves to communicate = the need to redirect. Of course, just as with "unavailable" messages, = redirection should be either permanent or temporary. bob wyman ------=_NextPart_000_02CA_01C0808D.2A345270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One of the things I find very = frustrating with a=20 number of network protocols is that when you get the "service not = available"=20 message, you don't get answers to the questions: "Why not?" and "When = will it be=20 back?." Few protocols allow you to do much more than simply poll the = darned=20 server from time to time in the hope that the thing will return to life. = In many=20 cases, that polling can simply make matters worse, since the = unavailability of=20 the service may be because too many people are trying to access=20 it...
 
It would be very useful, I think, if = BXXP could=20 expand it's "unavailable" error messages to include:
    1) Service = permanently=20 unavailable (i.e. Don't ever try again!)
    2) Service = temporarily=20 unavailable (i.e. We'll be back)
 
This would allow clients to do more = rational things=20 in response to being rejected. Cases of temporary unavailability = include=20 things like startup, shutdown, server is overloaded and = can't=20 take more connects, databases are being reorganized, backups are being=20 performed, etc. These are all cases where it would be good to refuse new = connections without discouraging people from coming back later. Ideally, = the=20 protocol would support returning an estimated time to availability in = the case=20 of a temporary shut-out.
 
It would also, I think, be very useful = to provide=20 for a redirection response, very much like that which we find in HTTP. I = realize=20 that one can buy all sorts of fancy gear to do load balancing for you, = and I=20 realize that once you've got a connection to a BXXP server and = start=20 talking a profile, that profile could implement redirection, however, it = is=20 still likely that in many cases, scalability of the solution is going to = be=20 enhanced by allowing the BXXP servers themselves to communicate the need = to=20 redirect. Of course, just as with "unavailable" messages, redirection = should be=20 either permanent or temporary.
 
        bob=20 wyman
 
------=_NextPart_000_02CA_01C0808D.2A345270-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jan 17 23:30:24 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05022 for ; Wed, 17 Jan 2001 23:30:24 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id UAA21281; Wed, 17 Jan 2001 20:29:16 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id UAA21262 for ; Wed, 17 Jan 2001 20:29:15 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0I4Gs300808; Wed, 17 Jan 2001 20:16:54 -0800 (PST) Message-ID: <004401c08107$2c43d110$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: <02cd01c080d0$390efb90$a8d1fc9e@accrue.com> Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... Date: Wed, 17 Jan 2001 20:28:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C080C4.1D864CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C080C4.1D864CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi. in terms of unavailable messages: 421 is a transient problem 521 is a permanent problem in terms of redirects: i can see arguments for returning a redirect instead of a greeting. i can also see arguments for returning a redirect in response to a start. i'm more inclined to favor the latter since a peer might offer several services, but need to do redirects on only a subset of them. supporting either of these approaches requires a change to the protocol. that's not fatal, since there's a field in the greeting element that we can use to signal extensibility. however, until the beep specs get published, it doesn't make much sense to talk about more enhancements... /mtr ----- Original Message ----- From: Bob Wyman To: bxxpwg@lists.invisibleworlds.com Sent: Wednesday, January 17, 2001 13:55 Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... One of the things I find very frustrating with a number of network protocols is that when you get the "service not available" message, you don't get answers to the questions: "Why not?" and "When will it be back?." Few protocols allow you to do much more than simply poll the darned server from time to time in the hope that the thing will return to life. In many cases, that polling can simply make matters worse, since the unavailability of the service may be because too many people are trying to access it... It would be very useful, I think, if BXXP could expand it's "unavailable" error messages to include: 1) Service permanently unavailable (i.e. Don't ever try again!) 2) Service temporarily unavailable (i.e. We'll be back) This would allow clients to do more rational things in response to being rejected. Cases of temporary unavailability include things like startup, shutdown, server is overloaded and can't take more connects, databases are being reorganized, backups are being performed, etc. These are all cases where it would be good to refuse new connections without discouraging people from coming back later. Ideally, the protocol would support returning an estimated time to availability in the case of a temporary shut-out. It would also, I think, be very useful to provide for a redirection response, very much like that which we find in HTTP. I realize that one can buy all sorts of fancy gear to do load balancing for you, and I realize that once you've got a connection to a BXXP server and start talking a profile, that profile could implement redirection, however, it is still likely that in many cases, scalability of the solution is going to be enhanced by allowing the BXXP servers themselves to communicate the need to redirect. Of course, just as with "unavailable" messages, redirection should be either permanent or temporary. bob wyman ------=_NextPart_000_0040_01C080C4.1D864CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi. in terms of unavailable messages:
 
421 is a transient problem
521 is a permanent problem
 
in terms of redirects:
 
i can see arguments for returning a redirect instead = of a=20 greeting. i can also see arguments for returning a redirect in response = to a=20 start. i'm more inclined to favor the latter since a peer might offer = several=20 services, but need to do redirects on only a subset of them. supporting = either=20 of these approaches requires a change to the protocol. that's not fatal, = since=20 there's a field in the greeting element that we can use to signal = extensibility.=20 however, until the beep specs get published, it doesn't make much sense = to talk=20 about more enhancements...
 
/mtr
----- Original Message -----
From:=20 Bob=20 Wyman
To: bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Wednesday, January 17, = 2001=20 13:55
Subject: [BXXPwg] Why won't you = talk to=20 me? (i.e. 421 - service not available), and redirection...

One of the things I find very = frustrating with a=20 number of network protocols is that when you get the "service not = available"=20 message, you don't get answers to the questions: "Why not?" and "When = will it=20 be back?." Few protocols allow you to do much more than simply poll = the darned=20 server from time to time in the hope that the thing will return to = life. In=20 many cases, that polling can simply make matters worse, since the=20 unavailability of the service may be because too many people are = trying to=20 access it...
 
It would be very useful, I think, if = BXXP could=20 expand it's "unavailable" error messages to include:
    1) Service = permanently=20 unavailable (i.e. Don't ever try again!)
    2) Service = temporarily=20 unavailable (i.e. We'll be back)
 
This would allow clients to do more = rational=20 things in response to being rejected. Cases of temporary = unavailability=20 include things like startup, shutdown, server is = overloaded and=20 can't take more connects, databases are being reorganized, backups are = being=20 performed, etc. These are all cases where it would be good to refuse = new=20 connections without discouraging people from coming back later. = Ideally, the=20 protocol would support returning an estimated time to availability in = the case=20 of a temporary shut-out.
 
It would also, I think, be very = useful to provide=20 for a redirection response, very much like that which we find in HTTP. = I=20 realize that one can buy all sorts of fancy gear to do load balancing = for you,=20 and I realize that once you've got a connection to a BXXP server = and=20 start talking a profile, that profile could implement redirection, = however, it=20 is still likely that in many cases, scalability of the solution is = going to be=20 enhanced by allowing the BXXP servers themselves to communicate the = need to=20 redirect. Of course, just as with "unavailable" messages, redirection = should=20 be either permanent or temporary.
 
        bob=20 wyman
 
------=_NextPart_000_0040_01C080C4.1D864CE0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jan 18 00:36:32 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06460 for ; Thu, 18 Jan 2001 00:36:32 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA21677; Wed, 17 Jan 2001 21:35:28 -0800 (PST) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA21615 for ; Wed, 17 Jan 2001 21:35:27 -0800 (PST) Received: from w2kbwyman (sdn-ar-001casfrMP092.dialsprint.net [158.252.208.94]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id VAA16609; Wed, 17 Jan 2001 21:34:45 -0800 (PST) Message-ID: <041101c08110$692a65e0$a8d1fc9e@accrue.com> Reply-To: "Bob Wyman" From: "Bob Wyman" To: "Marshall T. Rose" , Cc: "Marshall Rose" References: <02cd01c080d0$390efb90$a8d1fc9e@accrue.com> <004401c08107$2c43d110$8753cf3f@FATORA> Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... Date: Wed, 17 Jan 2001 21:34:47 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040C_01C080CD.50B516B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_040C_01C080CD.50B516B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marshal Rose wrote: > 421 is a transient problem > 521 is a permanent problem I was guessing that 521 would be the permanent code, however, the = core drafts all have the error codes explicitly listed rather than = providing any explanation for the meaning of the digits. (521 isn't in = any of the drafts that I've seen) The error code philosophy is discussed = in the "design" document, however, that isn't the document that might = become an RFC is it? Would it make sense to include a discussion of = error code assignment practices in the core document to provide guidance = for codes that may be defined in the future? re: redirect on greeting, or start, or both. There are arguments for one or the other or both. But, if it has to = be in just one place, I think it would be best provided on the start = message. Is this the sort of thing that could be added in the meantime as a = "feature?" If so, I'd really appreciate a sketch of how that would be = done. The current documentation discusses features but doesn't provide = an example. Would something like the following be what is intended: 1) Extend the Greeting message to warn that redirects may occur. Thus, = the following might be sent: L: RPY 0 0 . 0 122 L: Content-Type: application/beep+xml L: L: L: L: L: END =20 2) Define two error codes (one for permanent, the other for transient = redirection) and craft responses to start messages that look like: S: ERR 0 1 . 264 127 S: Content-Type: application/beep+xml S: S: redirection required S: S: END Is this how it works? When I declare a feature to be supported, is there = anyway that I can point to a profile that defines it? If I've added = error codes, do I register them somewhere? (The feature definition = template doesn't explicitly provide for error code declaration.) bob wyman ----- Original Message -----=20 From: Marshall T. Rose=20 To: Bob Wyman ; bxxpwg@lists.invisibleworlds.com=20 Cc: Marshall Rose=20 Sent: Wednesday, January 17, 2001 8:28 PM Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service = not available), and redirection... hi. in terms of unavailable messages: 421 is a transient problem 521 is a permanent problem in terms of redirects: i can see arguments for returning a redirect instead of a greeting. i = can also see arguments for returning a redirect in response to a start. = i'm more inclined to favor the latter since a peer might offer several = services, but need to do redirects on only a subset of them. supporting = either of these approaches requires a change to the protocol. that's not = fatal, since there's a field in the greeting element that we can use to = signal extensibility. however, until the beep specs get published, it = doesn't make much sense to talk about more enhancements... /mtr ----- Original Message -----=20 From: Bob Wyman=20 To: bxxpwg@lists.invisibleworlds.com=20 Sent: Wednesday, January 17, 2001 13:55 Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not = available), and redirection... One of the things I find very frustrating with a number of network = protocols is that when you get the "service not available" message, you = don't get answers to the questions: "Why not?" and "When will it be = back?." Few protocols allow you to do much more than simply poll the = darned server from time to time in the hope that the thing will return = to life. In many cases, that polling can simply make matters worse, = since the unavailability of the service may be because too many people = are trying to access it... It would be very useful, I think, if BXXP could expand it's = "unavailable" error messages to include: 1) Service permanently unavailable (i.e. Don't ever try again!) 2) Service temporarily unavailable (i.e. We'll be back) This would allow clients to do more rational things in response to = being rejected. Cases of temporary unavailability include things like = startup, shutdown, server is overloaded and can't take more connects, = databases are being reorganized, backups are being performed, etc. These = are all cases where it would be good to refuse new connections without = discouraging people from coming back later. Ideally, the protocol would = support returning an estimated time to availability in the case of a = temporary shut-out. It would also, I think, be very useful to provide for a redirection = response, very much like that which we find in HTTP. I realize that one = can buy all sorts of fancy gear to do load balancing for you, and I = realize that once you've got a connection to a BXXP server and start = talking a profile, that profile could implement redirection, however, it = is still likely that in many cases, scalability of the solution is going = to be enhanced by allowing the BXXP servers themselves to communicate = the need to redirect. Of course, just as with "unavailable" messages, = redirection should be either permanent or temporary. bob wyman ------=_NextPart_000_040C_01C080CD.50B516B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Marshal Rose wrote:
> 421 is a transient problem
> 521 is a permanent = problem
    I was guessing that = 521 would be=20 the permanent code, however, the core drafts all have the error codes = explicitly=20 listed rather than providing any explanation for the meaning of the=20 digits. (521 isn't in any of the drafts that I've seen) The error = code=20 philosophy is discussed in the "design" document, however, that isn't = the=20 document that might become an RFC is it? Would it make sense to = include a=20 discussion of error code assignment practices in the core document to = provide=20 guidance for codes that may be defined in the future?
 
re: redirect on greeting, or start, or=20 both.
    There are arguments = for one or=20 the other or both. But, if it has to be in just one place, I think it = would be=20 best provided on the start message.
    Is this the sort of = thing that=20 could be added in the meantime as a "feature?" If so, I'd really = appreciate a=20 sketch of how that would be done. The current documentation discusses = features=20 but doesn't provide an example. Would something like the following be = what is=20 intended:
 
1) Extend the Greeting message = to warn that=20 redirects may occur. Thus, the following might be sent:
       L: = RPY 0 0 . 0=20 122
       L: Content-Type:=20 application/beep+xml
      =20 L:
       L: <greeting=20 features=3D'x-redirect'>
      =20 L:    <profile = uri=3D'http://xml.resource.org/profiles/TLS'=20 />
       L:=20 </greeting>
       L:=20 END
 
2) Define two error codes (one=20 for permanent, the other for transient redirection) and craft=20 responses to start messages that look like:

    S: ERR 0 1 . 264 127
    = S:=20 Content-Type: application/beep+xml
   =20 S:
    S: <error code=3D'4??'>redirection=20 required</error>
    S: <x-redirect=20 fqdn=3D'foo.bar.com' port=3D'3333' /x-redirect>
    = S:=20 END
Is this how it works? When I declare a = feature to=20 be supported, is there anyway that I can point to a profile that defines = it? If=20 I've added error codes, do I register them somewhere? (The feature = definition=20 template doesn't explicitly provide for error code = declaration.)
 
        = bob=20 wyman
 
----- Original Message -----
From:=20 Marshall T. = Rose
To: Bob Wyman ; bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Wednesday, January 17, = 2001 8:28=20 PM
Subject: Re: [BXXPwg] Why won't = you talk=20 to me? (i.e. 421 - service not available), and redirection...

hi. in terms of unavailable messages:
 
421 is a transient problem
521 is a permanent problem
 
in terms of redirects:
 
i can see arguments for returning a redirect = instead of a=20 greeting. i can also see arguments for returning a redirect in = response to a=20 start. i'm more inclined to favor the latter since a peer might offer = several=20 services, but need to do redirects on only a subset of them. = supporting either=20 of these approaches requires a change to the protocol. that's not = fatal, since=20 there's a field in the greeting element that we can use to signal=20 extensibility. however, until the beep specs get published, it doesn't = make=20 much sense to talk about more enhancements...
 
/mtr
----- Original Message -----
From:=20 Bob=20 Wyman
To: bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Wednesday, January 17, = 2001=20 13:55
Subject: [BXXPwg] Why won't = you talk to=20 me? (i.e. 421 - service not available), and redirection...

One of the things I find very = frustrating with=20 a number of network protocols is that when you get the "service not=20 available" message, you don't get answers to the questions: "Why = not?" and=20 "When will it be back?." Few protocols allow you to do much more = than simply=20 poll the darned server from time to time in the hope that the thing = will=20 return to life. In many cases, that polling can simply make matters = worse,=20 since the unavailability of the service may be because too many = people are=20 trying to access it...
 
It would be very useful, I think, = if BXXP could=20 expand it's "unavailable" error messages to include:
    1) Service = permanently=20 unavailable (i.e. Don't ever try again!)
    2) Service = temporarily=20 unavailable (i.e. We'll be back)
 
This would allow clients to do more = rational=20 things in response to being rejected. Cases of temporary = unavailability=20 include things like startup, shutdown, server is=20 overloaded and can't take more connects, databases are being=20 reorganized, backups are being performed, etc. These are all cases = where it=20 would be good to refuse new connections without discouraging people = from=20 coming back later. Ideally, the protocol would support returning an=20 estimated time to availability in the case of a temporary=20 shut-out.
 
It would also, I think, be very = useful to=20 provide for a redirection response, very much like that which we = find in=20 HTTP. I realize that one can buy all sorts of fancy gear to do load=20 balancing for you, and I realize that once you've got a connection = to a=20 BXXP server and start talking a profile, that profile could = implement=20 redirection, however, it is still likely that in many cases, = scalability of=20 the solution is going to be enhanced by allowing the BXXP servers = themselves=20 to communicate the need to redirect. Of course, just as with = "unavailable"=20 messages, redirection should be either permanent or = temporary.
 
        bob=20 wyman
 
------=_NextPart_000_040C_01C080CD.50B516B0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jan 18 12:39:23 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29257 for ; Thu, 18 Jan 2001 12:39:22 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA25385; Thu, 18 Jan 2001 09:38:14 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA25369 for ; Thu, 18 Jan 2001 09:38:13 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0IHPt302779; Thu, 18 Jan 2001 09:25:55 -0800 (PST) Message-ID: <016901c08175$6749cb20$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: <02cd01c080d0$390efb90$a8d1fc9e@accrue.com> <004401c08107$2c43d110$8753cf3f@FATORA> <041101c08110$692a65e0$a8d1fc9e@accrue.com> Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... Date: Thu, 18 Jan 2001 09:38:00 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0165_01C08132.58D89230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_0165_01C08132.58D89230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit look around for some lore called "the theory of reply codes" (e.g., in RFC 821), and you'll see what the three digits mean... i haven't sat down to design a redirection feature for beep. what you outline below is probably pretty close to the optimal. however, the problem probably isn't interesting until the beep specs get published... /mtr ----- Original Message ----- From: Bob Wyman To: Marshall T. Rose ; bxxpwg@lists.invisibleworlds.com Cc: Marshall Rose Sent: Wednesday, January 17, 2001 21:34 Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... Marshal Rose wrote: > 421 is a transient problem > 521 is a permanent problem I was guessing that 521 would be the permanent code, however, the core drafts all have the error codes explicitly listed rather than providing any explanation for the meaning of the digits. (521 isn't in any of the drafts that I've seen) The error code philosophy is discussed in the "design" document, however, that isn't the document that might become an RFC is it? Would it make sense to include a discussion of error code assignment practices in the core document to provide guidance for codes that may be defined in the future? re: redirect on greeting, or start, or both. There are arguments for one or the other or both. But, if it has to be in just one place, I think it would be best provided on the start message. Is this the sort of thing that could be added in the meantime as a "feature?" If so, I'd really appreciate a sketch of how that would be done. The current documentation discusses features but doesn't provide an example. Would something like the following be what is intended: 1) Extend the Greeting message to warn that redirects may occur. Thus, the following might be sent: L: RPY 0 0 . 0 122 L: Content-Type: application/beep+xml L: L: L: L: L: END 2) Define two error codes (one for permanent, the other for transient redirection) and craft responses to start messages that look like: S: ERR 0 1 . 264 127 S: Content-Type: application/beep+xml S: S: redirection required S: S: END Is this how it works? When I declare a feature to be supported, is there anyway that I can point to a profile that defines it? If I've added error codes, do I register them somewhere? (The feature definition template doesn't explicitly provide for error code declaration.) bob wyman ----- Original Message ----- From: Marshall T. Rose To: Bob Wyman ; bxxpwg@lists.invisibleworlds.com Cc: Marshall Rose Sent: Wednesday, January 17, 2001 8:28 PM Subject: Re: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... hi. in terms of unavailable messages: 421 is a transient problem 521 is a permanent problem in terms of redirects: i can see arguments for returning a redirect instead of a greeting. i can also see arguments for returning a redirect in response to a start. i'm more inclined to favor the latter since a peer might offer several services, but need to do redirects on only a subset of them. supporting either of these approaches requires a change to the protocol. that's not fatal, since there's a field in the greeting element that we can use to signal extensibility. however, until the beep specs get published, it doesn't make much sense to talk about more enhancements... /mtr ----- Original Message ----- From: Bob Wyman To: bxxpwg@lists.invisibleworlds.com Sent: Wednesday, January 17, 2001 13:55 Subject: [BXXPwg] Why won't you talk to me? (i.e. 421 - service not available), and redirection... One of the things I find very frustrating with a number of network protocols is that when you get the "service not available" message, you don't get answers to the questions: "Why not?" and "When will it be back?." Few protocols allow you to do much more than simply poll the darned server from time to time in the hope that the thing will return to life. In many cases, that polling can simply make matters worse, since the unavailability of the service may be because too many people are trying to access it... It would be very useful, I think, if BXXP could expand it's "unavailable" error messages to include: 1) Service permanently unavailable (i.e. Don't ever try again!) 2) Service temporarily unavailable (i.e. We'll be back) This would allow clients to do more rational things in response to being rejected. Cases of temporary unavailability include things like startup, shutdown, server is overloaded and can't take more connects, databases are being reorganized, backups are being performed, etc. These are all cases where it would be good to refuse new connections without discouraging people from coming back later. Ideally, the protocol would support returning an estimated time to availability in the case of a temporary shut-out. It would also, I think, be very useful to provide for a redirection response, very much like that which we find in HTTP. I realize that one can buy all sorts of fancy gear to do load balancing for you, and I realize that once you've got a connection to a BXXP server and start talking a profile, that profile could implement redirection, however, it is still likely that in many cases, scalability of the solution is going to be enhanced by allowing the BXXP servers themselves to communicate the need to redirect. Of course, just as with "unavailable" messages, redirection should be either permanent or temporary. bob wyman ------=_NextPart_000_0165_01C08132.58D89230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
look around for some lore called "the theory of = reply codes"=20 (e.g., in RFC 821), and you'll see what the three digits = mean...
 
i haven't sat down to design a redirection feature = for beep.=20 what you outline below is probably pretty close to the optimal. however, = the=20 problem probably isn't interesting until the beep specs get=20 published...
 
/mtr
----- Original Message -----
From:=20 Bob=20 Wyman
To: Marshall T. = Rose ; bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Wednesday, January 17, = 2001=20 21:34
Subject: Re: [BXXPwg] Why won't = you talk=20 to me? (i.e. 421 - service not available), and redirection...

Marshal Rose wrote:
> 421 is a transient problem
> 521 is a permanent = problem
    I was guessing = that 521 would=20 be the permanent code, however, the core drafts all have the error = codes=20 explicitly listed rather than providing any explanation for the = meaning of the=20 digits. (521 isn't in any of the drafts that I've seen) The error = code=20 philosophy is discussed in the "design" document, however, that isn't = the=20 document that might become an RFC is it? Would it make sense to = include a=20 discussion of error code assignment practices in the core document to = provide=20 guidance for codes that may be defined in the future?
 
re: redirect on greeting, or start, = or=20 both.
    There are = arguments for one or=20 the other or both. But, if it has to be in just one place, I think it = would be=20 best provided on the start message.
    Is this the sort = of thing that=20 could be added in the meantime as a "feature?" If so, I'd really = appreciate a=20 sketch of how that would be done. The current documentation discusses = features=20 but doesn't provide an example. Would something like the following be = what is=20 intended:
 
1) Extend the Greeting message = to warn that=20 redirects may occur. Thus, the following might be sent:
       = L: RPY 0 0 .=20 0 122
       L: Content-Type:=20 application/beep+xml
      =20 L:
       L: <greeting=20 features=3D'x-redirect'>
      =20 L:    <profile = uri=3D'http://xml.resource.org/profiles/TLS'=20 />
       L:=20 </greeting>
       L:=20 END
 
2) Define two error codes (one=20 for permanent, the other for transient redirection) and = craft=20 responses to start messages that look like:

    S: ERR 0 1 . 264 127
    = S:=20 Content-Type: application/beep+xml
   =20 S:
    S: <error code=3D'4??'>redirection=20 required</error>
    S: <x-redirect=20 fqdn=3D'foo.bar.com' port=3D'3333' = /x-redirect>
    S:=20 END
Is this how it works? When I declare = a feature to=20 be supported, is there anyway that I can point to a profile that = defines it?=20 If I've added error codes, do I register them somewhere? (The feature=20 definition template doesn't explicitly provide for error code=20 declaration.)
 
        = bob=20 wyman
 
----- Original Message -----
From:=20 Marshall T. = Rose
To: Bob Wyman ; bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Wednesday, January 17, = 2001 8:28=20 PM
Subject: Re: [BXXPwg] Why = won't you=20 talk to me? (i.e. 421 - service not available), and = redirection...

hi. in terms of unavailable = messages:
 
421 is a transient problem
521 is a permanent problem
 
in terms of redirects:
 
i can see arguments for returning a redirect = instead of a=20 greeting. i can also see arguments for returning a redirect in = response to a=20 start. i'm more inclined to favor the latter since a peer might = offer=20 several services, but need to do redirects on only a subset of them. = supporting either of these approaches requires a change to the = protocol.=20 that's not fatal, since there's a field in the greeting element that = we can=20 use to signal extensibility. however, until the beep specs get = published, it=20 doesn't make much sense to talk about more = enhancements...
 
/mtr
----- Original Message ----- =
From:=20 Bob=20 Wyman
To: bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Wednesday, January = 17, 2001=20 13:55
Subject: [BXXPwg] Why won't = you talk=20 to me? (i.e. 421 - service not available), and = redirection...

One of the things I find very = frustrating=20 with a number of network protocols is that when you get the = "service not=20 available" message, you don't get answers to the questions: "Why = not?" and=20 "When will it be back?." Few protocols allow you to do much more = than=20 simply poll the darned server from time to time in the hope that = the thing=20 will return to life. In many cases, that polling can simply make = matters=20 worse, since the unavailability of the service may be because too = many=20 people are trying to access it...
 
It would be very useful, I think, = if BXXP=20 could expand it's "unavailable" error messages to = include:
    1) Service = permanently=20 unavailable (i.e. Don't ever try again!)
    2) Service = temporarily=20 unavailable (i.e. We'll be back)
 
This would allow clients to do = more rational=20 things in response to being rejected. Cases of temporary=20 unavailability include things like startup, = shutdown, server is=20 overloaded and can't take more connects, databases are being=20 reorganized, backups are being performed, etc. These are all cases = where=20 it would be good to refuse new connections without discouraging = people=20 from coming back later. Ideally, the protocol would support = returning an=20 estimated time to availability in the case of a temporary=20 shut-out.
 
It would also, I think, be very = useful to=20 provide for a redirection response, very much like that which we = find in=20 HTTP. I realize that one can buy all sorts of fancy gear to do = load=20 balancing for you, and I realize that once you've got a connection = to a BXXP server and start talking a profile, that profile = could=20 implement redirection, however, it is still likely that in many = cases,=20 scalability of the solution is going to be enhanced by allowing = the BXXP=20 servers themselves to communicate the need to redirect. Of course, = just as=20 with "unavailable" messages, redirection should be either = permanent or=20 temporary.
 
       =20 bob wyman
 
------=_NextPart_000_0165_01C08132.58D89230-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jan 19 12:38:55 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03081 for ; Fri, 19 Jan 2001 12:38:55 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA09431; Fri, 19 Jan 2001 09:36:51 -0800 (PST) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA09413 for ; Fri, 19 Jan 2001 09:36:50 -0800 (PST) Received: from w2kbwyman (sdn-ar-011casfrMP210.dialsprint.net [158.252.242.212]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA02726 for ; Fri, 19 Jan 2001 09:36:47 -0800 (PST) Message-ID: <001d01c0823e$679539b0$d4f2fc9e@accrue.com> Reply-To: "Bob Wyman" From: "Bob Wyman" To: Date: Fri, 19 Jan 2001 09:36:48 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C081FB.586803C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] Will there be only one beep? What about Versions? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C081FB.586803C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A practice followed by many protocols, is to provide version = information as part of the initial handshake. However, there seems to be = no way to determine what version of BXXP one is talking to. Admittedly, = once finalized, the first version will be the only version, however, we = can anticipate that someday someone is going to raise enough support for = an idea that one will wish to extend the protocol through something = other than Features. I might, for instance, get lucky and convince folk = to support the redirect methods that I recently proposed.=20 Features, since they are supported in the Greetings message, may be = enough to handle extensions that only impact post-greetings protocol = elements such as Start, End, etc. as long as extensions are built in a = backwards compatible manner. However, it seems to me that Features would = NOT be a good way to handle modifications to the Greetings message = itself. Thus, it would be difficult to add support for redirect in the = Greetings message in the future without making a bit of a mess. Also, a = Feature advertised in a Greetings message can't be relied upon to = introduce protocol elements that might one day need to appear before the = Greetings message (these are admittedly unlikely to appear and can = probably be ignored as a problem.) While profiles exist for the various application level exchanges = that can flow over BXXP (I assume profiles can be versioned), the = underlying protocol has no way of advertising its own profile... Are there existing plans to handle version advertisement if a BXXP = V1.1 or V2.0 is ever defined? May I suggest that the Greetings message should have a "Version" = attribute? i.e. the following would then be a valid greeting: L: L: L: =20 Yes, I realize that a version identifier can be introduced in a = later version and that one could write a rule that says that if no = version is present then it must be V1.0. However, we recently went = through this with HTTP and it was a real pain. The problem was people = who had clients or servers that weren't anticipating versions in the = headers they were receiving. It was quickly fixed since there weren't = that many bits of code around at the time, but it would have been = avoided if people knew up front that they would have to handle versions. = In BXXP, the server sends its Greetings first. Given that there will = be many more clients than servers, what we have here is a case where a = change to a small number of servers is going to need to be handled by a = very large number of clients. It is inevitable that some idiot is going = to code at least one or more of those clients in a way that it can't = handle a version advertisement in an elegant way. Let's hope that = whatever that client is, it isn't for some popular service. Otherwise, = BXXP evolution could be blocked by the stupid implementation. This is = not goodness and it certainly wouldn't seem to address the BXXP goal of = incorporating the best practices of protocol design into a single, = reusable framework. bob wyman ------=_NextPart_000_001A_01C081FB.586803C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    A practice followed = by many=20 protocols, is to provide version information as part of the initial = handshake.=20 However, there seems to be no way to determine what version of BXXP one = is=20 talking to. Admittedly, once finalized, the first version will be the = only=20 version, however, we can anticipate that someday someone is going to = raise=20 enough support for an idea that one will wish to extend the protocol = through=20 something other than Features. I might, for instance, get lucky and = convince=20 folk to support the redirect methods that I recently proposed. =
    Features, since they = are supported in the Greetings message, may be enough to handle = extensions=20 that only impact post-greetings protocol elements such as Start, End, = etc. as=20 long as extensions are built in a backwards compatible manner. However, = it seems=20 to me that Features would NOT be a good way to handle modifications to = the=20 Greetings message itself. Thus, it would be difficult to add support for = redirect in the Greetings message in the future without making a bit of = a=20 mess.  Also, a Feature advertised in a Greetings message = can't be relied upon to introduce protocol = elements that might=20 one day need to appear before the Greetings message (these are = admittedly=20 unlikely to appear and can probably be ignored as a = problem.)
    While profiles exist = for the=20 various application level exchanges that can flow over BXXP (I=20 assume profiles can be versioned), the underlying protocol has no = way of=20 advertising its own profile...
    Are there existing = plans to=20 handle version advertisement if a BXXP V1.1 or V2.0 is ever=20 defined?
    May I suggest that = the Greetings=20 message should have a "Version" attribute? i.e. the following would then = be a=20 valid greeting:

    L:=20 <greeting ver=3D'1.0.0.0'>
    = L:   =20 <profile uri=3D'http://xml.resource.org/profiles/TLS'=20 />
    L: = </greeting>
 
    Yes, I realize that = a version=20 identifier can be introduced in a later version and that one could write = a rule=20 that says that if no version is present then it must be V1.0. However, = we=20 recently went through this with HTTP and it was a real pain. The problem = was=20 people who had clients or servers that weren't = anticipating=20 versions in the headers they were receiving. It was quickly fixed since = there=20 weren't that many bits of code around at the time, but it would have = been=20 avoided if people knew up front that they would have to handle versions. =
    In BXXP, the server = sends its=20 Greetings first. Given that there will be many more clients than = servers, what=20 we have here is a case where a change to a small number of servers is = going to=20 need to be handled by a very large number of clients. It is inevitable = that some=20 idiot is going to code at least one or more of those clients in a way = that it=20 can't handle a version advertisement in an elegant way. Let's hope that = whatever=20 that client is, it isn't for some popular service. Otherwise, BXXP=20 evolution could be blocked by the stupid implementation. This is not = goodness=20 and it certainly wouldn't seem to address the BXXP goal of incorporating = the=20 best practices of protocol design into a single, reusable=20 framework.
 
        = bob=20 wyman
 
------=_NextPart_000_001A_01C081FB.586803C0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jan 19 14:05:16 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04480 for ; Fri, 19 Jan 2001 14:05:16 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA10343; Fri, 19 Jan 2001 11:04:12 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA10276 for ; Fri, 19 Jan 2001 11:04:10 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0JIpg306283; Fri, 19 Jan 2001 10:51:42 -0800 (PST) Message-ID: <012701c0824a$91df1180$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: <001d01c0823e$679539b0$d4f2fc9e@accrue.com> Subject: Re: [BXXPwg] Will there be only one beep? What about Versions? Date: Fri, 19 Jan 2001 11:03:54 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01C08207.834DCD70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_0123_01C08207.834DCD70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit the problem is that there is no such thing as an application protocol that has successfully done version evolution. if anyone disagrees, then step forward and name the counter-example. i think we should err towards simplicity, above all else. if someone wants a different way of doing greetings, they can do that, they just can't call it beep. if they want small deltas to the channel management profile, they can use the feature attribute (as you suggested for redirection). if they want to do different versions of other profiles, each side can advertise different URIs in their greetings. this gives you a versioning capability very inexpensively. /mtr ----- Original Message ----- From: Bob Wyman To: bxxpwg@lists.invisibleworlds.com Sent: Friday, January 19, 2001 09:36 Subject: [BXXPwg] Will there be only one beep? What about Versions? A practice followed by many protocols, is to provide version information as part of the initial handshake. However, there seems to be no way to determine what version of BXXP one is talking to. Admittedly, once finalized, the first version will be the only version, however, we can anticipate that someday someone is going to raise enough support for an idea that one will wish to extend the protocol through something other than Features. I might, for instance, get lucky and convince folk to support the redirect methods that I recently proposed. Features, since they are supported in the Greetings message, may be enough to handle extensions that only impact post-greetings protocol elements such as Start, End, etc. as long as extensions are built in a backwards compatible manner. However, it seems to me that Features would NOT be a good way to handle modifications to the Greetings message itself. Thus, it would be difficult to add support for redirect in the Greetings message in the future without making a bit of a mess. Also, a Feature advertised in a Greetings message can't be relied upon to introduce protocol elements that might one day need to appear before the Greetings message (these are admittedly unlikely to appear and can probably be ignored as a problem.) While profiles exist for the various application level exchanges that can flow over BXXP (I assume profiles can be versioned), the underlying protocol has no way of advertising its own profile... Are there existing plans to handle version advertisement if a BXXP V1.1 or V2.0 is ever defined? May I suggest that the Greetings message should have a "Version" attribute? i.e. the following would then be a valid greeting: L: L: L: Yes, I realize that a version identifier can be introduced in a later version and that one could write a rule that says that if no version is present then it must be V1.0. However, we recently went through this with HTTP and it was a real pain. The problem was people who had clients or servers that weren't anticipating versions in the headers they were receiving. It was quickly fixed since there weren't that many bits of code around at the time, but it would have been avoided if people knew up front that they would have to handle versions. In BXXP, the server sends its Greetings first. Given that there will be many more clients than servers, what we have here is a case where a change to a small number of servers is going to need to be handled by a very large number of clients. It is inevitable that some idiot is going to code at least one or more of those clients in a way that it can't handle a version advertisement in an elegant way. Let's hope that whatever that client is, it isn't for some popular service. Otherwise, BXXP evolution could be blocked by the stupid implementation. This is not goodness and it certainly wouldn't seem to address the BXXP goal of incorporating the best practices of protocol design into a single, reusable framework. bob wyman ------=_NextPart_000_0123_01C08207.834DCD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
the problem is that there is no such thing as an = application=20 protocol that has successfully done version evolution. if anyone = disagrees, then=20 step forward and name the counter-example.
 
i think we should err towards simplicity, above all = else. if=20 someone wants a different way of doing greetings, they can do that, they = just=20 can't call it beep.
 
if they want small deltas to the channel management = profile,=20 they can use the feature attribute (as you suggested for=20 redirection).
 
if they want to do different versions of other = profiles, each=20 side can advertise different URIs in their greetings. this gives you a=20 versioning capability very inexpensively.
 
/mtr
----- Original Message -----
From:=20 Bob=20 Wyman
To: bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Friday, January 19, 2001=20 09:36
Subject: [BXXPwg] Will there be = only one=20 beep? What about Versions?

    A practice = followed by many=20 protocols, is to provide version information as part of the initial = handshake.=20 However, there seems to be no way to determine what version of BXXP = one is=20 talking to. Admittedly, once finalized, the first version will be the = only=20 version, however, we can anticipate that someday someone is going to = raise=20 enough support for an idea that one will wish to extend the protocol = through=20 something other than Features. I might, for instance, get lucky and = convince=20 folk to support the redirect methods that I recently proposed. =
    Features, since = they=20 are supported in the Greetings message, may be enough to handle=20 extensions that only impact post-greetings protocol elements such as = Start,=20 End, etc. as long as extensions are built in a backwards compatible = manner.=20 However, it seems to me that Features would NOT be a good way to = handle=20 modifications to the Greetings message itself. Thus, it would be = difficult to=20 add support for redirect in the Greetings message in the future = without making=20 a bit of a mess.  Also, a Feature advertised in a Greetings = message=20 can't be relied upon to introduce = protocol=20 elements that might one day need to appear before the Greetings = message (these=20 are admittedly unlikely to appear and can probably be ignored as a=20 problem.)
    While profiles = exist for the=20 various application level exchanges that can flow over BXXP (I=20 assume profiles can be versioned), the underlying protocol has no = way of=20 advertising its own profile...
    Are there existing = plans to=20 handle version advertisement if a BXXP V1.1 or V2.0 is ever=20 defined?
    May I suggest that = the=20 Greetings message should have a "Version" attribute? i.e. the = following would=20 then be a valid greeting:

   =20 L: <greeting ver=3D'1.0.0.0'>
    = L:   =20 <profile uri=3D'http://xml.resource.org/profiles/TLS'=20 />
    L: = </greeting>
 
    Yes, I realize = that a version=20 identifier can be introduced in a later version and that one could = write a=20 rule that says that if no version is present then it must be V1.0. = However, we=20 recently went through this with HTTP and it was a real pain. The = problem was=20 people who had clients or servers that weren't = anticipating=20 versions in the headers they were receiving. It was quickly fixed = since there=20 weren't that many bits of code around at the time, but it would have = been=20 avoided if people knew up front that they would have to handle = versions.=20
    In BXXP, the = server sends its=20 Greetings first. Given that there will be many more clients than = servers, what=20 we have here is a case where a change to a small number of servers is = going to=20 need to be handled by a very large number of clients. It is inevitable = that=20 some idiot is going to code at least one or more of those clients in a = way=20 that it can't handle a version advertisement in an elegant way. Let's = hope=20 that whatever that client is, it isn't for some popular service.=20 Otherwise, BXXP evolution could be blocked by the stupid = implementation. This=20 is not goodness and it certainly wouldn't seem to address the BXXP = goal of=20 incorporating the best practices of protocol design into a single, = reusable=20 framework.
 
        = bob=20 wyman
 
------=_NextPart_000_0123_01C08207.834DCD70-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 22 13:33:24 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11275 for ; Mon, 22 Jan 2001 13:33:23 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA28042; Mon, 22 Jan 2001 10:31:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA27901 for ; Mon, 22 Jan 2001 10:26:40 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11127; Mon, 22 Jan 2001 13:26:36 -0500 (EST) Message-Id: <200101221826.NAA11127@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: bxxpwg@invisible.net From: The IESG Date: Mon, 22 Jan 2001 13:26:36 -0500 Subject: [BXXPwg] Protocol Action: Mapping the BXXP Framework onto TCP to Proposed Standard Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net The IESG has approved the following Internet-Drafts for publication as Proposed Standards: o The Blocks Extensible Exchange Protocol Framework o Mapping the BXXP Framework onto TCP These documents are the product of the Blocks Extensible Exchange Protocol Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary BEEP provides a generic application protocol framework for connection-oriented, asynchronous interactions. At the core of the BEEP framework is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. Messages are arbitrary MIME[1] content, but are usually textual (structured using XML[2]). All exchanges occur in the context of a channel -- a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BEEP is the notion of channel management. In addition to defining BEEP's channel management profile, this document defines: o the TLS[3] transport security profile; and, o the SASL[4] family of profiles. Other profiles, such as those used for data exchange, are defined by an application protocol designer. Working Group Summary The BEEP WG expanded on the BLOCKS protocol work done by Marshall Rose and Carl Malamud. BLOCKS in turn drew on many existing IETF protocols and the design goals discussed at the APPLCORE BOF. Protocol Quality Ned Freed reviewed the BEEP specification for the IESG. Note to RFC Editor: In draft-ietf-beep-tcpmapping-06, please add the following paragraph just after the two bullet items in section 2: A simultaneous TCP OPEN would result in both BEEP peers believing they are the initiator and neither peer will be able to start any channels. Because of this, services based on BEEP must be designed so that simultaenous TCP OPENs cannot occur. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jan 25 13:31:56 2001 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05630 for ; Thu, 25 Jan 2001 13:31:50 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA26887; Thu, 25 Jan 2001 10:29:56 -0800 (PST) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA26871 for ; Thu, 25 Jan 2001 10:29:55 -0800 (PST) Received: from w2kbwyman (sdn-ar-004casfrMP074.dialsprint.net [158.252.211.76]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id KAA26321 for ; Thu, 25 Jan 2001 10:29:36 -0800 (PST) Message-ID: <05b801c086fc$b2107f00$bdf0fc9e@accrue.com> Reply-To: "Bob Wyman" From: "Bob Wyman" To: Date: Thu, 25 Jan 2001 10:29:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B5_01C086B9.A3037B40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] Profile or Profiles? Is it too late for edits? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_05B5_01C086B9.A3037B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is it too late for edits? Section 2 of draft-ietf-beep-framework-11.txt says: "When a session is established, each BEEP peer advertises the profile it = supports." Shouldn't this sentence have referred to "profiles" (i.e. plural?).=20 Also, it would appear from 2.3.1.1 that peers only advertise the = profiles that they support while acting in a server role. This = distinction is not made in this text. Given these two observations, I = would suggest that the sentence in Section 2 would read better as: "When a session is established, each BEEP peer advertises the profile[s] = it supports [when acting in a server role]." Section 2.3 says: "Channel management allows each BEEP peer to advertise the profiles that = it supports..." This sentence may have a problem similar to the one in Section 2., = although it isn't stating a requirement -- only reflecting on the = purposes of channel management. It might read better as: "Channel management allows each BEEP peer to advertise the profiles that = it supports [when acting in a server role]...." Also, I'm curious, other than the "TASK=3D0" of DECnet, I can't think of = any other protocol that works the way BEEP does in that the protocol or = profile is specified after the connection is made. Please forgive me if = I'm missing something obvious. Can anyone provide other examples? bob wyman ------=_NextPart_000_05B5_01C086B9.A3037B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is it too late for edits?
 
Section 2 of = draft-ietf-beep-framework-11.txt=20 says:
"When a session is established, each BEEP peer advertises the = profile=20 it supports."
Shouldn't this sentence have referred = to "profiles"=20 (i.e. plural?).
 
Also, it would appear from 2.3.1.1 that = peers only=20 advertise the profiles that they support while acting in a server role. = This=20 distinction is not made in this text. Given these two observations, I = would=20 suggest that the sentence in Section 2 would read better = as:
"When a session is established, each = BEEP peer=20 advertises the profile[s] it supports [when acting in a server=20 role]."
 
Section 2.3 says:
"Channel management allows each BEEP = peer to=20 advertise the profiles that it supports..."
This sentence may have a problem = similar to the one=20 in Section 2., although it isn't stating a requirement -- only = reflecting on the=20 purposes of channel management. It might read better as:
"Channel management allows each BEEP = peer to=20 advertise the profiles that it supports [when acting in a server=20 role]...."
 
Also, I'm curious, other than the = "TASK=3D0" of=20 DECnet, I can't think of any other protocol that works the way BEEP does = in that=20 the protocol or profile is specified after the connection is made. = Please=20 forgive me if I'm missing something obvious. Can anyone provide other=20 examples?
 
        bob=20 wyman
 
------=_NextPart_000_05B5_01C086B9.A3037B40-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jan 29 02:06:26 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27864 for ; Mon, 29 Jan 2001 02:06:25 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id XAA19369; Sun, 28 Jan 2001 23:04:42 -0800 (PST) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id XAA19356 for ; Sun, 28 Jan 2001 23:04:41 -0800 (PST) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f0T6pF306027; Sun, 28 Jan 2001 22:51:15 -0800 (PST) Message-ID: <00a101c089c1$baaedf90$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: <05b801c086fc$b2107f00$bdf0fc9e@accrue.com> Subject: Re: [BXXPwg] Profile or Profiles? Is it too late for edits? Date: Sun, 28 Jan 2001 23:04:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01C0897E.AC3DA6A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_009D_01C0897E.AC3DA6A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Is it too late for edits? probably. we've already had two working group last calls and an extended iesg last call. other than the punctuation typo you mention, i'm disinclined to argue with the rfc editor to hold the presses and get everyone to agree to the changes... /mtr ----- Original Message ----- From: Bob Wyman To: bxxpwg@lists.invisibleworlds.com Sent: Thursday, January 25, 2001 10:29 Subject: [BXXPwg] Profile or Profiles? Is it too late for edits? Is it too late for edits? Section 2 of draft-ietf-beep-framework-11.txt says: "When a session is established, each BEEP peer advertises the profile it supports." Shouldn't this sentence have referred to "profiles" (i.e. plural?). Also, it would appear from 2.3.1.1 that peers only advertise the profiles that they support while acting in a server role. This distinction is not made in this text. Given these two observations, I would suggest that the sentence in Section 2 would read better as: "When a session is established, each BEEP peer advertises the profile[s] it supports [when acting in a server role]." Section 2.3 says: "Channel management allows each BEEP peer to advertise the profiles that it supports..." This sentence may have a problem similar to the one in Section 2., although it isn't stating a requirement -- only reflecting on the purposes of channel management. It might read better as: "Channel management allows each BEEP peer to advertise the profiles that it supports [when acting in a server role]...." Also, I'm curious, other than the "TASK=0" of DECnet, I can't think of any other protocol that works the way BEEP does in that the protocol or profile is specified after the connection is made. Please forgive me if I'm missing something obvious. Can anyone provide other examples? bob wyman ------=_NextPart_000_009D_01C0897E.AC3DA6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> Is it too late for = edits?
 
probably. we've already had two working = group last=20 calls and an extended iesg last call. other than the punctuation typo = you=20 mention, i'm disinclined to argue with the rfc editor to hold the = presses and=20 get everyone to agree to the changes...
 
/mtr
----- Original Message -----
From:=20 Bob=20 Wyman
To: bxxpwg@lists.invisiblewo= rlds.com=20
Sent: Thursday, January 25, = 2001=20 10:29
Subject: [BXXPwg] Profile or = Profiles? Is=20 it too late for edits?

Is it too late for = edits?
 
Section 2 of = draft-ietf-beep-framework-11.txt=20 says:
"When a session is established, each BEEP peer advertises the = profile=20 it supports."
Shouldn't this sentence have referred = to=20 "profiles" (i.e. plural?).
 
Also, it would appear from 2.3.1.1 = that peers=20 only advertise the profiles that they support while acting in a server = role.=20 This distinction is not made in this text. Given these two = observations, I=20 would suggest that the sentence in Section 2 would read better=20 as:
"When a session is established, each = BEEP peer=20 advertises the profile[s] it supports [when acting in a server=20 role]."
 
Section 2.3 says:
"Channel management allows each BEEP = peer to=20 advertise the profiles that it supports..."
This sentence may have a problem = similar to the=20 one in Section 2., although it isn't stating a requirement -- only = reflecting=20 on the purposes of channel management. It might read better = as:
"Channel management allows each BEEP = peer to=20 advertise the profiles that it supports [when acting in a server=20 role]...."
 
Also, I'm curious, other than the = "TASK=3D0" of=20 DECnet, I can't think of any other protocol that works the way BEEP = does in=20 that the protocol or profile is specified after the connection is = made. Please=20 forgive me if I'm missing something obvious. Can anyone provide other=20 examples?
 
        bob=20 wyman
 
------=_NextPart_000_009D_01C0897E.AC3DA6A0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg