From bxxpwg-admin@lists.invisibleworlds.com Wed Jun 6 17:50:51 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 RAA09650 for ; Wed, 6 Jun 2001 17:50:50 -0400 (EDT) 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 OAA21186; Wed, 6 Jun 2001 14:49:41 -0700 (PDT) Received: from joda.cis.temple.edu (joda.cis.temple.edu [155.247.71.60]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA21160 for ; Wed, 6 Jun 2001 14:49:40 -0700 (PDT) Received: from bluehen.joda.cis.temple.edu (chaka.cis.temple.edu [155.247.170.18]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id RAA27276; Wed, 6 Jun 2001 17:49:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20010606155839.0256ad60@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 17:36:54 -0400 To: IETF beep working group From: "Phillip T. Conrad" Cc: conrad@joda.cis.temple.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [BXXPwg] Channel Number Range 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 WG'ers: I'm working on a new version of the BEEP over SCTP Mapping draft. A previous draft version authored by Marshall Rose indicates that: >the mapping between BEEP channel numbers and SCTP stream >identifiers is the identity function While this is an ideal solution because of its simplicity, I am concerned that this may create some problems. Consider the following: * RFC3080 (BEEP) specifies that the valid range for a channel number is: 1..2147483647 * RFC3080 (BEEP) specifies that an endpoint "should" support at least 257 concurrent channels. * RFC2960 (SCTP) specifies that the stream identifier is an unsigned 16 bit integer (i.e. range 0..65535). Discussion: It is implied that an endpoint "may" support as few as 257 concurrent channels. (Presumably, reasonable implementations might support fewer, say 512, 1024, or 8192. However, it is not specified that these channels have to be numbered in the range 1-514 (odd on one side, even on the other), or that the range of possible sequence numbers be limited in any way. Presumably the channel numbers could be arbitrarily chosen (respecting the odd/even rule) from the full range of 1..2147483647, provided the total *number* of concurrent open channels doesn't exceed the implementation limit. Question: (1) Is it reasonable for a BEEP implementation to reject a channel open request because the channel number request is out of some implementation dependent supported range? If so, what error message would the BEEP implementation issue? My initial thought would be that this should NOT happen... that a BEEP implemenation "MUST" support the entire channel number range, though a limit may be placed on the "number" of open channels. (2) If the answer to (1) is "yes", is it reasonable to have the channel number range be limited differently for different transport mappings? (e.g. the full range 1..2147483647 for BEEP over TCP, but only 1..65535 for BEEP over SCTP?) (3) While it would increase complexity of implementation somewhat, is there any other reason that a dynamic mapping (handled by the mapping layer) between BEEP channel and SCTP stream number would create problems? (4) In practice, a number of the initial SCTP implementation don't provide the entire 0..65536 channel range... is this true of the initial BEEP implementations also? (5) Can anyone developing profiles for BEEP Application Layer Protocols comment on how they see channel numbers being used in their protocols? More specifically, are there real situations where one might forsee a need to use channel numbers that exceed 65535? Thanks, Phill Conrad Asst. Professor, CIS Dept., Temple University http://www.cis.temple.edu/~conrad, http://netlab.cis.temple.edu _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jun 6 21:10:33 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 VAA11425 for ; Wed, 6 Jun 2001 21:10:32 -0400 (EDT) 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 SAA22210; Wed, 6 Jun 2001 18:09:47 -0700 (PDT) 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 SAA22191 for ; Wed, 6 Jun 2001 18:09:46 -0700 (PDT) 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 f5718kH02824; Wed, 6 Jun 2001 18:08:46 -0700 (PDT) Message-ID: <018101c0eeee$84440010$8753cf3f@FATORA> From: "Marshall T. Rose" To: "IETF beep working group" , "Phillip T. Conrad" Cc: , "Marshall Rose" References: <4.3.2.7.2.20010606155839.0256ad60@joda.cis.temple.edu> Subject: Re: [BXXPwg] Channel Number Range Date: Wed, 6 Jun 2001 18:09:34 -0700 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) Is it reasonable for a BEEP implementation to reject a channel open request because the channel number request is out of some implementation dependent supported range? If so, what error message would the BEEP implementation issue? yes, it's reasonable. as far as the error message, that's an api issue, which is out of scope for the protocol spec. > (2) If the answer to (1) is "yes", is it reasonable to have the channel number range be limited differently for different transport mappings? (e.g. the full range 1..2147483647 for BEEP over TCP, but only 1..65535 for BEEP over SCTP?) yes. > (3) While it would increase complexity of implementation somewhat, is there any other reason that a dynamic mapping (handled by the mapping layer) between BEEP channel and SCTP stream number would create problems? complexity is a problem. > (4) In practice, a number of the initial SCTP implementation don't provide the entire 0..65536 channel range... is this true of the initial BEEP implementations also? it depends on the implementation. i suspect that someone writing beep for the pocketpc, may decide to use some simple datastructures that require some limitations... > (5) Can anyone developing profiles for BEEP Application Layer Protocols comment on how they see channel numbers being used in their protocols? More specifically, are there real situations where one might forsee a need to use channel numbers that exceed 65535? with freedom comes responsibility. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 11 07:48:05 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 HAA07029 for ; Mon, 11 Jun 2001 07:48:03 -0400 (EDT) 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 EAA24244; Mon, 11 Jun 2001 04:46:28 -0700 (PDT) Received: from watervalley.net (mail.WaterValley.Net [216.220.140.3]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id EAA24216 for ; Mon, 11 Jun 2001 04:46:26 -0700 (PDT) Received: from [24.29.193.111] (HELO [10.0.1.7]) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0003622210 for ; Mon, 11 Jun 2001 05:47:08 -0600 Mime-Version: 1.0 X-Sender: bdist-cmh@mail.bdistributed.com (Unverified) Message-Id: Date: Mon, 11 Jun 2001 06:45:23 -0500 To: BXXPwg@lists.invisibleworlds.com From: Chris Hanson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [BXXPwg] C implementation, Open Source? 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 Is anyone working on an Open Source implementation of BEEP in C for Unix? -- Chris -- Chris Hanson bDistributed.com: Making Business Distributed _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 11 16:05:02 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 ESMTP id QAA17944 for ; Mon, 11 Jun 2001 16:05:01 -0400 (EDT) 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 NAA27198; Mon, 11 Jun 2001 13:02:13 -0700 (PDT) Received: from invisible.net (qawoor.not.invisible.net [204.62.247.23]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA27172 for ; Mon, 11 Jun 2001 13:02:12 -0700 (PDT) Received: from ballistic (c525276-a.ptlum1.sfba.home.com [24.20.129.105]) by invisible.net (8.9.3/8.9.3) with SMTP id MAA13987 for ; Mon, 11 Jun 2001 12:53:49 -0700 (PDT) Message-ID: <015701c0f2b1$59abfa30$8a00a8c0@ballistic> From: "Kristopher Magnusson" To: References: Subject: Re: [BXXPwg] C implementation, Open Source? Date: Mon, 11 Jun 2001 13:01:48 -0700 Organization: Invisible Worlds, Inc. 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Invisible Worlds is working on Beepcore-C for Linux. This project will be covered by the Blocks Public License. We estimate it will be available early- to mid-August. We'll post the project at Beepcore.org and make an announcement to the list. Thanks! ........... kris Kris Magnusson kris@invisible.net Product Management, Invisible Worlds http://invisible.net/ ----- Original Message ----- From: "Chris Hanson" To: Sent: Monday, June 11, 2001 4:45 AM Subject: [BXXPwg] C implementation, Open Source? > Is anyone working on an Open Source implementation of BEEP in C for Unix? > > -- Chris > > -- > Chris Hanson > bDistributed.com: Making Business Distributed > > _______________________________________________ > 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 Jun 12 22:14:01 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 ESMTP id WAA28973 for ; Tue, 12 Jun 2001 22:14:00 -0400 (EDT) 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 TAA10844; Tue, 12 Jun 2001 19:13:18 -0700 (PDT) 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 TAA10828 for ; Tue, 12 Jun 2001 19:13:17 -0700 (PDT) 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 f5D2BcH15174; Tue, 12 Jun 2001 19:11:39 -0700 (PDT) Message-ID: <00c101c0f3ae$5eefb240$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Eamon O'Tuathail" Date: Tue, 12 Jun 2001 19:13:00 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BE_01C0F373.B21086B0" 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] SOAP over BEEP 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_00BE_01C0F373.B21086B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Your comments are solicited. TXT version at http://www.ietf.org/internet-drafts/draft-etal-beep-soap-00.txt HTML version at http://beepcore.org/beepcore/beep-soap.jsp /mtr ------=_NextPart_000_00BE_01C0F373.B21086B0 Content-Type: message/rfc822; name="I-D ACTION_draft-etal-beep-soap-00.txt.eml" Content-Disposition: attachment; filename="I-D ACTION_draft-etal-beep-soap-00.txt.eml" Delivery-Date: Tue, 12 Jun 2001 07:45:42 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with ESMTP id f5CEjcH14366 for ; Tue, 12 Jun 2001 07:45:38 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA09436 for ietf-123-outbound.10@ietf.org; Tue, 12 Jun 2001 09:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA08989 for ; Tue, 12 Jun 2001 08:05:31 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12317 for ; Tue, 12 Jun 2001 08:05:31 -0400 (EDT) Message-Id: <200106121205.IAA12317@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-etal-beep-soap-00.txt Date: Tue, 12 Jun 2001 08:05:30 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using SOAP in BEEP Author(s) : E. O'Tuathail, M. Rose Filename : draft-etal-beep-soap-00.txt Pages : 12 Date : 11-Jun-01 SOAP is an XML-based messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. A SOAP binding describes how SOAP messages are transmitted in the network. This memo specifies a SOAP binding to BEEP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-etal-beep-soap-00.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-etal-beep-soap-00.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-etal-beep-soap-00.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: <20010611074708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-etal-beep-soap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-etal-beep-soap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010611074708.I-D@ietf.org> --OtherAccess-- --NextPart-- ------=_NextPart_000_00BE_01C0F373.B21086B0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jun 13 06:38:30 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 ESMTP id GAA18118 for ; Wed, 13 Jun 2001 06:38:29 -0400 (EDT) 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 DAA12385; Wed, 13 Jun 2001 03:37:54 -0700 (PDT) Received: from mail5.registeredsite.com (mail5.registeredsite.com [64.224.9.14]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id DAA12365 for ; Wed, 13 Jun 2001 03:37:53 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail5.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5DAbqm32059 for ; Wed, 13 Jun 2001 06:37:52 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id A438F1A00A0; Wed, 13 Jun 2001 06:45:12 -0400 Reply-To: From: "Eamon O'Tuathail" To: Subject: [BXXPwg] Channel Number Range Date: Wed, 13 Jun 2001 11:40:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 >> While it would increase complexity of implementation somewhat, is there >> any other reason that a dynamic mapping (handled by the mapping layer) >> between BEEP channel and SCTP stream number would create problems? One issue to worry about is sequence numbering. The sequence number is used to ensure correct ordering of frames in one direction on one channel. If there are M channels, and N distinct data flows (SCTP streams in this case), then sequence number checking should work as expected if: N = 1 (e.g. RFC 3081) M = N (the idea of mapping each channel onto a distinct SCTP stream) M > N, and you map M/N channels onto each data flow - and this mapping is fixed (e.g. channel 7 frames always travel on data flow 3). The two places I could see potential for problems are: M > N, where the mapping is dynamic (e.g. channel 7 frames sometimes travel on data flow 3, and other times travel on data flow 11) N > M (e.g. you have one high-traffic channel, yet two TCP connections) The rules of sequence numbering mean you can only compare the sequence number of the current frame with that of the immediately previous frame - so how do you check sequence numbering if a frame is travelling on a data flow different from the previous frame on the same channel. The two solutions I can immediately think of are either to forbid this (e.g. forbid M>N with dynamic mapping and forbid N>M) or to come up with some solution based on new transport mapping frames, which could help re-combine groups of frames for the same channel coming in on separate data flows. >> In practice, a number of the initial SCTP implementation don't provide >> the entire 0..65536 channel range... is this true of the initial BEEP >> implementations also? Clipcode.com's BEEP implementation for MS .NET does support the full range, but all the values are certainly not expected to be used (even over TCP). It is supported simply because the channel id is an int. >> ... are there real situations where one might forsee a need to >> use channel numbers that exceed 65535? I think most people would find a few hundred channels to be suitable for most needs - so I don't see limiting the number of channel for a particular transport mapping to be a problem. 65535 channels seems ample. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jun 13 20:19: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 ESMTP id UAA03802 for ; Wed, 13 Jun 2001 20:19:42 -0400 (EDT) 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 RAA16609; Wed, 13 Jun 2001 17:18:44 -0700 (PDT) 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 RAA16593 for ; Wed, 13 Jun 2001 17:18:43 -0700 (PDT) Received: (qmail 90906 invoked by uid 3039); 14 Jun 2001 00:18:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jun 2001 00:18:42 -0000 Date: Wed, 13 Jun 2001 17:18:41 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Marshall T. Rose" cc: , "Eamon O'Tuathail" Subject: Re: [BXXPwg] SOAP over BEEP In-Reply-To: <00c101c0f3ae$5eefb240$8753cf3f@FATORA> Message-ID: 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 One question this brings up w/r/t SOAP is that of URLs - is there such a thing as a BEEP endpoint URL? The reason I ask is that WSDL (the web services description language) tries to describe a SOAP endpoint with (among other attributes) an HTTP URL. So, it seems that if SOAP/BEEP is deployed, the WSDL folks are going to want to be able to specify a BEEP URL similarly to the way they specify a HTTP URL: from http://msdn.microsoft.com/xml/general/wsdl.asp (example 6): Now, of course, this is WSDL and not SOAP or BEEP, so we aren't here to solve the WSDL description of a BEEP endpoint -- but is now an appropriate time to discuss URLs in the context of BEEP/TCP ? Or are URLs not really appropriate? -Gabe On Tue, 12 Jun 2001, Marshall T. Rose wrote: > Your comments are solicited. > > TXT version at > http://www.ietf.org/internet-drafts/draft-etal-beep-soap-00.txt > > HTML version at http://beepcore.org/beepcore/beep-soap.jsp > > /mtr > > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jun 13 22:24:08 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 ESMTP id WAA05497 for ; Wed, 13 Jun 2001 22:24:07 -0400 (EDT) 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 TAA17174; Wed, 13 Jun 2001 19:23:21 -0700 (PDT) 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 TAA17153 for ; Wed, 13 Jun 2001 19:23:20 -0700 (PDT) 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 f5E2LYH18894; Wed, 13 Jun 2001 19:21:34 -0700 (PDT) Message-ID: <04b601c0f478$ef6217d0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Gabe Wachob" Cc: , "Eamon O'Tuathail" , "Marshall Rose" References: Subject: Re: [BXXPwg] SOAP over BEEP Date: Wed, 13 Jun 2001 19:23:00 -0700 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 hi. i don't think it makes sense to talk about a BEEP URL, because BEEP, by itself, isn't a protocol like HTTP or FTP or SMTP is. i suspect there is some general "issue" in the URL architecture that needs to get resolved before we will find a satisfactory answer to the question. for example, in the case of wsdl or soap or ipp or whatever, i can always say http://example.com/ but how is anyone to know that the http server there is really a front-end to wsdl or soap or ipp? my point is that there's something semantic going on here that isn't visible in the URL, instead you somehow have to know from context that if you see a URL inside a certain kind of message then there's an expectation that a special kind of process is sitting at the http server. i noted that the wcip draft says this about naming: wcip://" domain-name ":" port "/" channel-name "?proto=beep" but you could just as easily have "?proto=http" tacked onto the end. i'm not suggesting that this is the "right way" but it does bear some thinking. /mtr ----- Original Message ----- From: "Gabe Wachob" To: "Marshall T. Rose" Cc: ; "Eamon O'Tuathail" Sent: Wednesday, June 13, 2001 17:18 Subject: Re: [BXXPwg] SOAP over BEEP > One question this brings up w/r/t SOAP is that of URLs - is there such a > thing as a BEEP endpoint URL? The reason I ask is that WSDL (the web > services description language) tries to describe a SOAP endpoint with > (among other attributes) an HTTP URL. So, it seems that if SOAP/BEEP is > deployed, the WSDL folks are going to want to be able to specify a BEEP > URL similarly to the way they specify a HTTP URL: > > from http://msdn.microsoft.com/xml/general/wsdl.asp (example 6): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, of course, this is WSDL and not SOAP or BEEP, so we aren't here to > solve the WSDL description of a BEEP endpoint -- but is now an > appropriate time to discuss URLs in the context of BEEP/TCP ? Or are URLs > not really appropriate? > > -Gabe > > On Tue, 12 Jun 2001, Marshall T. Rose wrote: > > > Your comments are solicited. > > > > TXT version at > > http://www.ietf.org/internet-drafts/draft-etal-beep-soap-00.txt > > > > HTML version at http://beepcore.org/beepcore/beep-soap.jsp > > > > /mtr > > > > > > > _______________________________________________ > 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 Wed Jun 13 22:32: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 ESMTP id WAA06466 for ; Wed, 13 Jun 2001 22:32:47 -0400 (EDT) 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 TAA17251; Wed, 13 Jun 2001 19:32:18 -0700 (PDT) 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 TAA17230 for ; Wed, 13 Jun 2001 19:32:16 -0700 (PDT) Received: (qmail 8042 invoked by uid 3039); 14 Jun 2001 02:32:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jun 2001 02:32:15 -0000 Date: Wed, 13 Jun 2001 19:32:15 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Marshall T. Rose" cc: , "Eamon O'Tuathail" , Marshall Rose Subject: Re: [BXXPwg] SOAP over BEEP In-Reply-To: <04b601c0f478$ef6217d0$8753cf3f@FATORA> Message-ID: 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 I think HTTP URLs have come to mean at least two things, notwithstanding the specs or original intent: 1) A place where you can get a WWW resource and 2) An endpoint which consists of a hostname/ip, a port, and a "relative path" (and possibly a "query" part). We need almost everything (and something more) in #2 for describing a BEEP endpoint, so an HTTP URL looks (perhaps deceptively) close to something useful for BEEP. I think (and have always thought) that there should be a well-specified (unambiguous) locator format of BEEP endpoint that can be used (for example) for pointing a BEEP peer to another BEEP peer. Whether it would include the profile which the describer intends the endpoint to be used for is not clear to me. And then there is the issue of how to describe endpoints across multiple types of transport (with TCP, its pretty simple, but what about non IP/port transports?) -Gabe On Wed, 13 Jun 2001, Marshall T. Rose wrote: > hi. i don't think it makes sense to talk about a BEEP URL, because BEEP, by > itself, isn't a protocol like HTTP or FTP or SMTP is. > > i suspect there is some general "issue" in the URL architecture that needs > to get resolved before we will find a satisfactory answer to the question. > for example, in the case of wsdl or soap or ipp or whatever, i can always > say > > http://example.com/ > > but how is anyone to know that the http server there is really a front-end > to wsdl or soap or ipp? my point is that there's something semantic going on > here that isn't visible in the URL, instead you somehow have to know from > context that if you see a URL inside a certain kind of message then there's > an expectation that a special kind of process is sitting at the http server. > > i noted that the wcip draft says this about naming: > > wcip://" domain-name ":" port "/" channel-name "?proto=beep" > > but you could just as easily have "?proto=http" tacked onto the end. > > i'm not suggesting that this is the "right way" but it does bear some > thinking. > > /mtr > > ----- Original Message ----- > From: "Gabe Wachob" > To: "Marshall T. Rose" > Cc: ; "Eamon O'Tuathail" > > Sent: Wednesday, June 13, 2001 17:18 > Subject: Re: [BXXPwg] SOAP over BEEP > > > > One question this brings up w/r/t SOAP is that of URLs - is there such a > > thing as a BEEP endpoint URL? The reason I ask is that WSDL (the web > > services description language) tries to describe a SOAP endpoint with > > (among other attributes) an HTTP URL. So, it seems that if SOAP/BEEP is > > deployed, the WSDL folks are going to want to be able to specify a BEEP > > URL similarly to the way they specify a HTTP URL: > > > > from http://msdn.microsoft.com/xml/general/wsdl.asp (example 6): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, of course, this is WSDL and not SOAP or BEEP, so we aren't here to > > solve the WSDL description of a BEEP endpoint -- but is now an > > appropriate time to discuss URLs in the context of BEEP/TCP ? Or are URLs > > not really appropriate? > > > > -Gabe > > > > On Tue, 12 Jun 2001, Marshall T. Rose wrote: > > > > > Your comments are solicited. > > > > > > TXT version at > > > http://www.ietf.org/internet-drafts/draft-etal-beep-soap-00.txt > > > > > > HTML version at http://beepcore.org/beepcore/beep-soap.jsp > > > > > > /mtr > > > > > > > > > > > > _______________________________________________ > > 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 Wed Jun 13 23:35:32 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 ESMTP id XAA07281 for ; Wed, 13 Jun 2001 23:35:32 -0400 (EDT) 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 UAA17580; Wed, 13 Jun 2001 20:34:59 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id UAA17558 for ; Wed, 13 Jun 2001 20:34:58 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5E3Yvd15711 for ; Wed, 13 Jun 2001 20:34:57 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5E3YuL15460; Wed, 13 Jun 2001 20:34:56 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5E3V7t01358; Wed, 13 Jun 2001 20:31:07 -0700 Date: Wed, 13 Jun 2001 20:31:07 -0700 From: "Roy T. Fielding" To: "Marshall T. Rose" Cc: Gabe Wachob , bxxpwg@invisible.net, "Eamon O'Tuathail" , Marshall Rose Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010613203107.D1183@waka.ebuilt.net> References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <04b601c0f478$ef6217d0$8753cf3f@FATORA>; from mrose+mtr.netnews@dbc.mtview.ca.us on Wed, Jun 13, 2001 at 07:23:00PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Wed, Jun 13, 2001 at 07:23:00PM -0700, Marshall T. Rose wrote: > hi. i don't think it makes sense to talk about a BEEP URL, because BEEP, by > itself, isn't a protocol like HTTP or FTP or SMTP is. Yes, though to be a little more accurate, BEEP isn't a service like HTTP or FTP servers. The URI scheme doesn't refer to the protocol. > i suspect there is some general "issue" in the URL architecture that needs > to get resolved before we will find a satisfactory answer to the question. > for example, in the case of wsdl or soap or ipp or whatever, i can always > say > > http://example.com/ > > but how is anyone to know that the http server there is really a front-end > to wsdl or soap or ipp? my point is that there's something semantic going on > here that isn't visible in the URL, instead you somehow have to know from > context that if you see a URL inside a certain kind of message then there's > an expectation that a special kind of process is sitting at the http server. That is already true. The "http" URI defines a namespace with hierarchical characteristics that is resolved by communicating with the naming authority (server) using one of the HTTP family of protocols, but such resolution only takes place when it is used within specific references as a hypertext link or submit button. Otherwise, it is just an identifier. They could define a beep URL that had the property of discovering which profile to be used as part of the connection, but that isn't very useful. URI schemes are more like TCP reserved ports -- they correspond to the type of service rather than the specific protocol to use (i.e., port 80 is reserved for WWW, not HTTP/1.0). > i noted that the wcip draft says this about naming: > > wcip://" domain-name ":" port "/" channel-name "?proto=beep" > > but you could just as easily have "?proto=http" tacked onto the end. > > i'm not suggesting that this is the "right way" but it does bear some > thinking. YUCK! wcip needs to learn about hierarchy violations. wcip.beep://authority/path would be better, but still misses the point. The URI scheme should answer the question of "what application interface should I expect?", which is a a lot more than "what protocol should I use?". Cheers, Roy T. Fielding, Chief Scientist, eBuilt, Inc. 2652 McGaw Avenue Irvine, CA 92614-5840 fax:+1.949.609.0001 (fielding@ebuilt.com) Chairman, The Apache Software Foundation (fielding@apache.org) _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 00:44:07 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 ESMTP id AAA07913 for ; Thu, 14 Jun 2001 00:44:07 -0400 (EDT) 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 VAA17788; Wed, 13 Jun 2001 21:43:31 -0700 (PDT) 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 VAA17770 for ; Wed, 13 Jun 2001 21:43:30 -0700 (PDT) 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 f5E4bxH19222; Wed, 13 Jun 2001 21:37:59 -0700 (PDT) Message-ID: <055b01c0f48b$fe524590$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Roy T. Fielding" Cc: "Gabe Wachob" , , "Eamon O'Tuathail" , "Marshall Rose" References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> <20010613203107.D1183@waka.ebuilt.net> Subject: Re: [BXXPwg] SOAP over BEEP Date: Wed, 13 Jun 2001 21:39:26 -0700 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 roy - i think i get what you're saying, but i'm still not entirely clear. setting aside for the moment whether HTTP is a protocol or a service, let's skip to this part: > > YUCK! wcip needs to learn about hierarchy violations. > > wcip.beep://authority/path > > would be better, but still misses the point. The URI scheme should > answer the question of "what application interface should I expect?", > which is a a lot more than "what protocol should I use?". and setting aside that i think you mean "layering" and not "hiearchy", let me ask the basic question: what should the uri look like for wcip over beep? i suspect that a well-architected answer would provide guidance for the dozen or so different domains in which this question is being asked... thanks! /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 18:18:03 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 ESMTP id SAA10703 for ; Thu, 14 Jun 2001 18:18:03 -0400 (EDT) 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 PAA22256; Thu, 14 Jun 2001 15:15:12 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA22243 for ; Thu, 14 Jun 2001 15:15:11 -0700 (PDT) Received: from norman.cp10.es.xerox.com (norman.cp10.es.xerox.com [13.240.124.12]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id SAA15233 for ; Thu, 14 Jun 2001 18:15:01 -0400 (EDT) Received: from x-crt-es-ms1.es.cp10.es.xerox.com (x-crt-es-ms1 [13.240.124.41]) by norman.cp10.es.xerox.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21981 for ; Thu, 14 Jun 2001 15:14:59 -0700 (PDT) Received: by x-crt-es-ms1.cp10.es.xerox.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 15:14:51 -0700 Message-ID: <918C79AB552BD211A2BD00805F15CE850532C337@x-crt-es-ms1.cp10.es.xerox.com> From: "Halsema, Aillil I" To: bxxpwg@lists.invisibleworlds.com Date: Thu, 14 Jun 2001 15:14:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [BXXPwg] IPP mapping onto bxxp 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 Is anyone working on mapping IPP onto bxxp? Ian Halsema XR&T/XAC/DDA Document Services Component Development Telephone:310-333-5417 Intelnet: 8*823-5417 _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 18:36: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 ESMTP id SAA10866 for ; Thu, 14 Jun 2001 18:36:57 -0400 (EDT) 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 PAA22439; Thu, 14 Jun 2001 15:36:27 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA22419 for ; Thu, 14 Jun 2001 15:36:26 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5EMaQd32047 for ; Thu, 14 Jun 2001 15:36:26 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5EMaOL31796; Thu, 14 Jun 2001 15:36:24 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5EMZ8U01097; Thu, 14 Jun 2001 15:35:08 -0700 Date: Thu, 14 Jun 2001 15:35:08 -0700 From: "Roy T. Fielding" To: "Marshall T. Rose" Cc: Gabe Wachob , bxxpwg@invisible.net, "Eamon O'Tuathail" , Marshall Rose Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010614153508.A909@waka.ebuilt.net> References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> <20010613203107.D1183@waka.ebuilt.net> <055b01c0f48b$fe524590$8753cf3f@FATORA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <055b01c0f48b$fe524590$8753cf3f@FATORA>; from mrose+mtr.netnews@dbc.mtview.ca.us on Wed, Jun 13, 2001 at 09:39:26PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Wed, Jun 13, 2001 at 09:39:26PM -0700, Marshall T. Rose wrote: > roy - i think i get what you're saying, but i'm still not entirely clear. > > setting aside for the moment whether HTTP is a protocol or a service, let's > skip to this part: > > > > > YUCK! wcip needs to learn about hierarchy violations. > > > > wcip.beep://authority/path > > > > would be better, but still misses the point. The URI scheme should > > answer the question of "what application interface should I expect?", > > which is a a lot more than "what protocol should I use?". > > and setting aside that i think you mean "layering" and not "hiearchy", let Nope, I meant the URI has a hierarchical syntax that drops from left to right, so, unless you consider "wcip over beep" and "wcip over somethng else" to be under the same naming authority, then beep should be to the left of the name. Layering is protocol design. URI are just names. > me ask the basic question: what should the uri look like for wcip over beep? > i suspect that a well-architected answer would provide guidance for the > dozen or so different domains in which this question is being asked... wcip is a little odd in that I don't undertand the purpose of the path within the URI. If there is no chance of relative URI being used, then the question of left-to-right hierarchy is not really an issue (aside from aesthetics). In general, if the service is available via multiple protocols and the naming syntax for those protocols will differ, then use a protocol-specific addition to the URI scheme (like the wcip.beep scheme above). That is the normal way of doing it because the authority syntax is often dependent on the transport used (e.g., TCP ports and defaults). OTOH, if the syntax for naming will be the same, but the naming authority will differ based on the lower-layer protocol, then I would include beep within the authority component. However, I have yet to see a good example of this in practice. If the beep-ness of the resource isn't part of its name at all, then I would use two separate identifiers -- a URI for the resource and some other URI (possibly implied by context) to indicate the communication mechanism. This is no different from how HTTP proxies are specified -- one URL for the proxy within the client configuration/environment and another URI for the resource being accessed through the proxy. My suspicion, however, is that there is no wcip resource -- that, in fact, the only thing they are using the URL for is selection of a channel. In that case, they should not have created a wcip URL at all. Instead, they should have used existing URL schemes to identify the channel and simply define a new one for beep channels (with care taken to only identify aspects of beep that are not specific to one profile). ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 19:00: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 ESMTP id TAA10991 for ; Thu, 14 Jun 2001 19:00:19 -0400 (EDT) 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 PAA22551; Thu, 14 Jun 2001 15:59:48 -0700 (PDT) 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 PAA22536 for ; Thu, 14 Jun 2001 15:59:47 -0700 (PDT) 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 f5EMvqH22361; Thu, 14 Jun 2001 15:57:52 -0700 (PDT) Message-ID: <09f301c0f525$a7481cd0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Roy T. Fielding" Cc: "Gabe Wachob" , , "Eamon O'Tuathail" References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> <20010613203107.D1183@waka.ebuilt.net> <055b01c0f48b$fe524590$8753cf3f@FATORA> <20010614153508.A909@waka.ebuilt.net> Subject: Re: [BXXPwg] SOAP over BEEP Date: Thu, 14 Jun 2001 15:59:22 -0700 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 roy - thanks. > In general, if the service is available via multiple protocols and the > naming syntax for those protocols will differ, then use a protocol-specific > addition to the URI scheme (like the wcip.beep scheme above). That is the > normal way of doing it because the authority syntax is often dependent on > the transport used (e.g., TCP ports and defaults). > > OTOH, if the syntax for naming will be the same, but the naming authority > will differ based on the lower-layer protocol, then I would include beep > within the authority component. However, I have yet to see a good example > of this in practice. in most of the recent cases that i have seen, the only thing that differs is how the data gets moved, e.g., going from soap/http to soap/beep, or ice/http to ice/beep, etc. in both cases, you have a situation where the path is going to be the same, and i have difficulty understanding whether the "use beep" bit should be present in the scheme component or the authority component. for example, http://example.com/ may very well be a valid thing for someone doing soap over http. so, what should we be using for the soap over beep case? here are four possibilities, i'm sure there are more... beep://example.com/ soap.beep://example.com/ soap://example.com/?proto=beep beep://example.com?profile=http://iana.org/beep/soap ideally, i would prefer to avoid having to use a new scheme everytime someone moves yet another service on top of beep. thanks, /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 21:01:52 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 ESMTP id VAA12345 for ; Thu, 14 Jun 2001 21:01:51 -0400 (EDT) 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 RAA23057; Thu, 14 Jun 2001 17:57:26 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id RAA23043 for ; Thu, 14 Jun 2001 17:57:26 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5F0vQd24180 for ; Thu, 14 Jun 2001 17:57:26 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5F0vOL24014; Thu, 14 Jun 2001 17:57:24 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5F0tAF01189; Thu, 14 Jun 2001 17:55:10 -0700 Date: Thu, 14 Jun 2001 17:55:10 -0700 From: "Roy T. Fielding" To: "Marshall T. Rose" Cc: Gabe Wachob , bxxpwg@invisible.net, "Eamon O'Tuathail" Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010614175510.D909@waka.ebuilt.net> References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> <20010613203107.D1183@waka.ebuilt.net> <055b01c0f48b$fe524590$8753cf3f@FATORA> <20010614153508.A909@waka.ebuilt.net> <09f301c0f525$a7481cd0$8753cf3f@FATORA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <09f301c0f525$a7481cd0$8753cf3f@FATORA>; from mrose+mtr.netnews@dbc.mtview.ca.us on Thu, Jun 14, 2001 at 03:59:22PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 > in most of the recent cases that i have seen, the only thing that differs is > how the data gets moved, e.g., going from soap/http to soap/beep, or > ice/http to ice/beep, etc. in both cases, you have a situation where the > path is going to be the same, and i have difficulty understanding whether > the "use beep" bit should be present in the scheme component or the > authority component. for example, > > http://example.com/ > > may very well be a valid thing for someone doing soap over http. so, what > should we be using for the soap over beep case? here are four possibilities, > i'm sure there are more... > > beep://example.com/ > > soap.beep://example.com/ > > soap://example.com/?proto=beep > > beep://example.com?profile=http://iana.org/beep/soap Too many bits, and the ? really should be reserved for supplying information to resources rather than general identification.. > ideally, i would prefer to avoid having to use a new scheme everytime > someone moves yet another service on top of beep. Hmmm, why? Logically, they are distinct services. Keep in mind that the "http" URL is specific to HTTP over TCP, even though HTTP itself is not dependent on TCP. If we were to deploy a new HTTP-over-SCTP service, we would need a new URL scheme because the authority syntax of hostname:port is specific to TCP, not HTTP. If I were to invent it from scratch, I would probably choose something like web://example.com:http.tcp.80/path web://example.com:http.udp.7149/path soap://example.com:beep.tcp.21212/path with the first ":http.tcp.80" being the default for the web. Obviously, that is getting pretty ugly. For some reason I think this looks better http://example.com/path web.http.udp://example.com:7149/path soap.beep.tcp://example.com:21212/path It also better fits the architecture of most URI handling software, which typically consists of a table of (scheme name , handler routine) tuples. Cheers, ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 21:14:08 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 ESMTP id VAA12499 for ; Thu, 14 Jun 2001 21:14:07 -0400 (EDT) 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 SAA23179; Thu, 14 Jun 2001 18:13:37 -0700 (PDT) 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 SAA23158 for ; Thu, 14 Jun 2001 18:13:35 -0700 (PDT) Received: (qmail 164 invoked by uid 3039); 15 Jun 2001 01:13:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jun 2001 01:13:30 -0000 Date: Thu, 14 Jun 2001 18:13:30 -0700 (PDT) From: Gabe Wachob X-Sender: To: Bill Mills cc: "'Marshall T. Rose'" , "Roy T. Fielding" , , "Eamon O'Tuathail" Subject: RE: [BXXPwg] SOAP over BEEP In-Reply-To: Message-ID: 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 what about beep:hostname:port:? e.g. beep:beephost.wiredobjects.com:10087:http://www.resource.org/SOAP ew, thats long. -Gabe On Thu, 14 Jun 2001, Bill Mills wrote: > >ideally, i would prefer to avoid having to use a new scheme everytime > >someone moves yet another service on top of beep. > > To satisfy the above seems reasonable and sane. Thus the URL for a > resource provisioned on BEEP to have the scheme "beep", i.e. > > beep: > > Are there major objections to this? Mostly what I have seen so far > is that there is yet a lot to think about and no firm path has yet > been taken. > > It makes sense to me that the URL should specify in some way that BEEP is > in use. Perhaps the scheme should encode the the transport mode as well > so that: > > beep: beep over tcp > beeps: beep over ssl > beepsc: beep over sctp > > We then have other vectors that need to be dealt with, host/port are > pretty easy. It's profile that gets ugly. Is it reasonable to adopt > well known abbreviations for specific profiles? The most painful thing > about profiles in the URL is that you need to encode a second URL within > the first one, I don't think anyone wants to go there... > > To expand on MTR's 4 examples below we might end up with > > beep:soap://example.com/ > > It seems like there is enough thoguht in this that we might be > proceeding to a decision, or at least the start of the discussion which > will lead to one. As has been said there are many ways to do this, > and no one solution is necessarily preferred, but there are clearly some > with pitfalls to be avoided. > > regards, > > -bill > > -----Original Message----- > From: Marshall T. Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] > Sent: Thursday, June 14, 2001 3:59 PM > To: Roy T. Fielding > Cc: Gabe Wachob; bxxpwg@invisible.net; Eamon O'Tuathail > Subject: Re: [BXXPwg] SOAP over BEEP > > > roy - thanks. > > > In general, if the service is available via multiple protocols and the > > naming syntax for those protocols will differ, then use a > protocol-specific > > addition to the URI scheme (like the wcip.beep scheme above). That is the > > normal way of doing it because the authority syntax is often dependent on > > the transport used (e.g., TCP ports and defaults). > > > > OTOH, if the syntax for naming will be the same, but the naming authority > > will differ based on the lower-layer protocol, then I would include beep > > within the authority component. However, I have yet to see a good example > > of this in practice. > > in most of the recent cases that i have seen, the only thing that differs is > how the data gets moved, e.g., going from soap/http to soap/beep, or > ice/http to ice/beep, etc. in both cases, you have a situation where the > path is going to be the same, and i have difficulty understanding whether > the "use beep" bit should be present in the scheme component or the > authority component. for example, > > http://example.com/ > > may very well be a valid thing for someone doing soap over http. so, what > should we be using for the soap over beep case? here are four possibilities, > i'm sure there are more... > > beep://example.com/ > > soap.beep://example.com/ > > soap://example.com/?proto=beep > > beep://example.com?profile=http://iana.org/beep/soap > > ideally, i would prefer to avoid having to use a new scheme everytime > someone moves yet another service on top of beep. > > thanks, > > /mtr > > > > _______________________________________________ > 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 Thu Jun 14 21:36: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 ESMTP id VAA13562 for ; Thu, 14 Jun 2001 21:36:57 -0400 (EDT) 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 SAA23292; Thu, 14 Jun 2001 18:36:26 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id SAA23277 for ; Thu, 14 Jun 2001 18:36:26 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5F1aPJ05570 for ; Thu, 14 Jun 2001 18:36:25 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5F1aOL05404; Thu, 14 Jun 2001 18:36:24 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5F1YxE01220; Thu, 14 Jun 2001 18:34:59 -0700 Date: Thu, 14 Jun 2001 18:34:59 -0700 From: "Roy T. Fielding" To: Gabe Wachob Cc: Bill Mills , "'Marshall T. Rose'" , bxxpwg@invisible.net, "Eamon O'Tuathail" Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010614183459.F909@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from gwachob@wachob.com on Thu, Jun 14, 2001 at 06:13:30PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 No, absolutely not. URNs would have been deployed seven years ago if the authors hadn't insisted on adding a colon to the syntax. You have no idea how many systems you would break simply by choosing beep:soap://example.com/ over soap.beep://example.com/ They may seem the same, but the first requires an algorithm change in every deployed piece of Web software, whereas the second just requires the addition of a plug-in handler. Also, it is soap.beep (not beep.soap) to preserve the hierarchical ordering. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 14 23:15: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 ESMTP id XAA15292 for ; Thu, 14 Jun 2001 23:15:36 -0400 (EDT) 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 UAA23603; Thu, 14 Jun 2001 20:15:00 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id SAA23118; Thu, 14 Jun 2001 18:08:12 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 18:20:47 -0700 Message-ID: From: Bill Mills To: "'Marshall T. Rose'" , "Roy T. Fielding" Cc: Gabe Wachob , bxxpwg@invisible.net, "Eamon O'Tuathail" Subject: RE: [BXXPwg] SOAP over BEEP Date: Thu, 14 Jun 2001 18:20:46 -0700 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 >ideally, i would prefer to avoid having to use a new scheme everytime >someone moves yet another service on top of beep. To satisfy the above seems reasonable and sane. Thus the URL for a resource provisioned on BEEP to have the scheme "beep", i.e. beep: Are there major objections to this? Mostly what I have seen so far is that there is yet a lot to think about and no firm path has yet been taken. It makes sense to me that the URL should specify in some way that BEEP is in use. Perhaps the scheme should encode the the transport mode as well so that: beep: beep over tcp beeps: beep over ssl beepsc: beep over sctp We then have other vectors that need to be dealt with, host/port are pretty easy. It's profile that gets ugly. Is it reasonable to adopt well known abbreviations for specific profiles? The most painful thing about profiles in the URL is that you need to encode a second URL within the first one, I don't think anyone wants to go there... To expand on MTR's 4 examples below we might end up with beep:soap://example.com/ It seems like there is enough thoguht in this that we might be proceeding to a decision, or at least the start of the discussion which will lead to one. As has been said there are many ways to do this, and no one solution is necessarily preferred, but there are clearly some with pitfalls to be avoided. regards, -bill -----Original Message----- From: Marshall T. Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] Sent: Thursday, June 14, 2001 3:59 PM To: Roy T. Fielding Cc: Gabe Wachob; bxxpwg@invisible.net; Eamon O'Tuathail Subject: Re: [BXXPwg] SOAP over BEEP roy - thanks. > In general, if the service is available via multiple protocols and the > naming syntax for those protocols will differ, then use a protocol-specific > addition to the URI scheme (like the wcip.beep scheme above). That is the > normal way of doing it because the authority syntax is often dependent on > the transport used (e.g., TCP ports and defaults). > > OTOH, if the syntax for naming will be the same, but the naming authority > will differ based on the lower-layer protocol, then I would include beep > within the authority component. However, I have yet to see a good example > of this in practice. in most of the recent cases that i have seen, the only thing that differs is how the data gets moved, e.g., going from soap/http to soap/beep, or ice/http to ice/beep, etc. in both cases, you have a situation where the path is going to be the same, and i have difficulty understanding whether the "use beep" bit should be present in the scheme component or the authority component. for example, http://example.com/ may very well be a valid thing for someone doing soap over http. so, what should we be using for the soap over beep case? here are four possibilities, i'm sure there are more... beep://example.com/ soap.beep://example.com/ soap://example.com/?proto=beep beep://example.com?profile=http://iana.org/beep/soap ideally, i would prefer to avoid having to use a new scheme everytime someone moves yet another service on top of beep. thanks, /mtr _______________________________________________ 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 Fri Jun 15 02:17:57 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 ESMTP id CAA27951 for ; Fri, 15 Jun 2001 02:17:56 -0400 (EDT) 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 XAA24112; Thu, 14 Jun 2001 23:17:19 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id SAA23210; Thu, 14 Jun 2001 18:16:07 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 18:28:42 -0700 Message-ID: From: Bill Mills To: "'Gabe Wachob'" , Bill Mills Cc: "'Marshall T. Rose'" , "Roy T. Fielding" , bxxpwg@invisible.net, "Eamon O'Tuathail" Subject: RE: [BXXPwg] SOAP over BEEP Date: Thu, 14 Jun 2001 18:28:40 -0700 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 still have not yet identified the resource within SOAP, just the profile... As I said, not sure we want to go there :) -bill -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Thursday, June 14, 2001 6:14 PM To: Bill Mills Cc: 'Marshall T. Rose'; Roy T. Fielding; bxxpwg@invisible.net; Eamon O'Tuathail Subject: RE: [BXXPwg] SOAP over BEEP what about beep:hostname:port:? e.g. beep:beephost.wiredobjects.com:10087:http://www.resource.org/SOAP ew, thats long. -Gabe On Thu, 14 Jun 2001, Bill Mills wrote: > >ideally, i would prefer to avoid having to use a new scheme everytime > >someone moves yet another service on top of beep. > > To satisfy the above seems reasonable and sane. Thus the URL for a > resource provisioned on BEEP to have the scheme "beep", i.e. > > beep: > > Are there major objections to this? Mostly what I have seen so far > is that there is yet a lot to think about and no firm path has yet > been taken. > > It makes sense to me that the URL should specify in some way that BEEP is > in use. Perhaps the scheme should encode the the transport mode as well > so that: > > beep: beep over tcp > beeps: beep over ssl > beepsc: beep over sctp > > We then have other vectors that need to be dealt with, host/port are > pretty easy. It's profile that gets ugly. Is it reasonable to adopt > well known abbreviations for specific profiles? The most painful thing > about profiles in the URL is that you need to encode a second URL within > the first one, I don't think anyone wants to go there... > > To expand on MTR's 4 examples below we might end up with > > beep:soap://example.com/ > > It seems like there is enough thoguht in this that we might be > proceeding to a decision, or at least the start of the discussion which > will lead to one. As has been said there are many ways to do this, > and no one solution is necessarily preferred, but there are clearly some > with pitfalls to be avoided. > > regards, > > -bill > > -----Original Message----- > From: Marshall T. Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] > Sent: Thursday, June 14, 2001 3:59 PM > To: Roy T. Fielding > Cc: Gabe Wachob; bxxpwg@invisible.net; Eamon O'Tuathail > Subject: Re: [BXXPwg] SOAP over BEEP > > > roy - thanks. > > > In general, if the service is available via multiple protocols and the > > naming syntax for those protocols will differ, then use a > protocol-specific > > addition to the URI scheme (like the wcip.beep scheme above). That is the > > normal way of doing it because the authority syntax is often dependent on > > the transport used (e.g., TCP ports and defaults). > > > > OTOH, if the syntax for naming will be the same, but the naming authority > > will differ based on the lower-layer protocol, then I would include beep > > within the authority component. However, I have yet to see a good example > > of this in practice. > > in most of the recent cases that i have seen, the only thing that differs is > how the data gets moved, e.g., going from soap/http to soap/beep, or > ice/http to ice/beep, etc. in both cases, you have a situation where the > path is going to be the same, and i have difficulty understanding whether > the "use beep" bit should be present in the scheme component or the > authority component. for example, > > http://example.com/ > > may very well be a valid thing for someone doing soap over http. so, what > should we be using for the soap over beep case? here are four possibilities, > i'm sure there are more... > > beep://example.com/ > > soap.beep://example.com/ > > soap://example.com/?proto=beep > > beep://example.com?profile=http://iana.org/beep/soap > > ideally, i would prefer to avoid having to use a new scheme everytime > someone moves yet another service on top of beep. > > thanks, > > /mtr > > > > _______________________________________________ > 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 Fri Jun 15 02:42:24 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 ESMTP id CAA29562 for ; Fri, 15 Jun 2001 02:42:24 -0400 (EDT) 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 XAA24285; Thu, 14 Jun 2001 23:41:28 -0700 (PDT) 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 XAA24262 for ; Thu, 14 Jun 2001 23:41:27 -0700 (PDT) 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 f5F6cHH23095; Thu, 14 Jun 2001 23:38:17 -0700 (PDT) Message-ID: <0a9701c0f565$f9dc4bc0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Halsema, Aillil I" , Cc: "Marshall Rose" References: <918C79AB552BD211A2BD00805F15CE850532C337@x-crt-es-ms1.cp10.es.xerox.com> Subject: Re: [BXXPwg] IPP mapping onto bxxp Date: Thu, 14 Jun 2001 23:39:49 -0700 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 anyone working on mapping IPP onto bxxp? i think that the large issue is that ipp is very carefully tailored to run over http. it has a number of design features that are http-assumptive. this doesn't mean that it can't be done or that it wouldn't be a good thing. but, it wouldn't be a brief memo like the one for soap onto beep. here's an example: every couple of weeks robert herriot surfaces a draft which attempts to define an effective multiplexing format for use in ipp. the motivation is that a network printer may be unable to store an entire page of a compound document internally before it can start rendering. a multiplexed approach would allow the printer to get parts of the "container" document and parts of the "components" (e.g., images) so that it can incrementally put the page together. everytime robert herriot surfaces the latest draft, someone responds that the root problem deals with a protocol issue not an encoding issue. the counter-response is usually to make the encoding more complex, e.g., by adding more granularity or whatever. in beep, it is trivial to solve a problem like this: the desktop establishes a session with the printer and starts sending the pages of the "container" document which contains references to the "components" via URIs. when the printer needs to stop working on the container and start working on a component, it requests the relevant URI over the same session. another issue deals with asynchronous notifications from the printer back to the desktop, which are hard to do with http, but easy to do with beep. my point here is that the guys who did ipp developed a fine-crafted protocol to work on top of what http gave them. you wouldn't get a lot of joy from replacing "ipp.http" with "ipp.beep", if you're going to change things, then you need to revisit some of the basic ipp mechanisms with beep in mind... m/tr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 02:46:15 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 ESMTP id CAA29820 for ; Fri, 15 Jun 2001 02:46:14 -0400 (EDT) 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 XAA24341; Thu, 14 Jun 2001 23:45:39 -0700 (PDT) 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 XAA24320 for ; Thu, 14 Jun 2001 23:45:38 -0700 (PDT) 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 f5F6hiH23105; Thu, 14 Jun 2001 23:43:44 -0700 (PDT) Message-ID: <0aa001c0f566$bcc17c00$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Roy T. Fielding" Cc: "Gabe Wachob" , , "Eamon O'Tuathail" , "Marshall Rose" References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> <20010613203107.D1183@waka.ebuilt.net> <055b01c0f48b$fe524590$8753cf3f@FATORA> <20010614153508.A909@waka.ebuilt.net> <09f301c0f525$a7481cd0$8753cf3f@FATORA> <20010614175510.D909@waka.ebuilt.net> Subject: Re: [BXXPwg] SOAP over BEEP Date: Thu, 14 Jun 2001 23:44:58 -0700 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 were to invent it from scratch, I would probably choose something like > > web://example.com:http.tcp.80/path > web://example.com:http.udp.7149/path > soap://example.com:beep.tcp.21212/path > > with the first ":http.tcp.80" being the default for the web. Obviously, > that is getting pretty ugly. For some reason I think this looks better > > http://example.com/path > web.http.udp://example.com:7149/path > soap.beep.tcp://example.com:21212/path > > It also better fits the architecture of most URI handling software, which > typically consists of a table of (scheme name , handler routine) tuples. 0. well, i agree that using "web:" instead of "http:" would certainly make things a lot more clear, but that's water under the bridge. 1. let me understand your reaction to > > ideally, i would prefer to avoid having to use a new scheme everytime > > someone moves yet another service on top of beep. > > Hmmm, why? Logically, they are distinct services. Keep in mind that the > "http" URL is specific to HTTP over TCP, even though HTTP itself is not > dependent on TCP. If we were to deploy a new HTTP-over-SCTP service, > we would need a new URL scheme because the authority syntax of hostname:port > is specific to TCP, not HTTP. i don't think that the http/tcp to http/sctp analogy is a good one. what i'm trying to understand is whether it is a good thing to define two schemes for soap.beep.tcp and ice.beep.tcp or to just have one scheme for beep over tcp. for all three schemes, the authority part remains the same. in guess i see your point that > > beep://example.com?profile=http://iana.org/beep/soap is pretty week. 2. anyway, in comparing: soap://example.com:beep.tcp.21212/path soap.beep.tcp://example.com:21212/path i guess i prefer the latter since when we move from "beep.tcp.21212" to "beep.ipv6.21212" the thing to the left is going to be funky. what isn't clear to me is whether the iana is going to be happy when i start registering url schemes in groups of three, e.g., ice: ice.beep: ice.beep.tcp: /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 03:07:29 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 ESMTP id DAA01245 for ; Fri, 15 Jun 2001 03:07:28 -0400 (EDT) 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 AAA24488; Fri, 15 Jun 2001 00:06:56 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id XAA24398; Thu, 14 Jun 2001 23:51:31 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 00:04:07 -0700 Message-ID: From: Bill Mills To: "'Roy T. Fielding'" , Gabe Wachob Cc: Bill Mills , "'Marshall T. Rose'" , bxxpwg@invisible.net, "Eamon O'Tuathail" Subject: RE: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 00:04:06 -0700 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 I am perfectly willing to believe that things would break. I had thought that "beep:soap://example.com/" to be valid construction of a URL per 1738, is this not the case? -bill -----Original Message----- From: Roy T. Fielding [mailto:fielding@ebuilt.com] Sent: Thursday, June 14, 2001 6:35 PM To: Gabe Wachob Cc: Bill Mills; 'Marshall T. Rose'; bxxpwg@invisible.net; Eamon O'Tuathail Subject: Re: [BXXPwg] SOAP over BEEP No, absolutely not. URNs would have been deployed seven years ago if the authors hadn't insisted on adding a colon to the syntax. You have no idea how many systems you would break simply by choosing beep:soap://example.com/ over soap.beep://example.com/ They may seem the same, but the first requires an algorithm change in every deployed piece of Web software, whereas the second just requires the addition of a plug-in handler. Also, it is soap.beep (not beep.soap) to preserve the hierarchical ordering. ....Roy _______________________________________________ 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 Fri Jun 15 11:20: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 ESMTP id LAA11610 for ; Fri, 15 Jun 2001 11:20:33 -0400 (EDT) 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 IAA26592; Fri, 15 Jun 2001 08:19:56 -0700 (PDT) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA26534; Fri, 15 Jun 2001 08:19:54 -0700 (PDT) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA06956; Fri, 15 Jun 2001 08:19:53 -0700 (PDT) Message-Id: <200106151519.IAA06956@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: [BXXPwg] SOAP over BEEP To: Bill Mills cc: "'Roy T. Fielding'" , Gabe Wachob , "'Marshall T. Rose'" , bxxpwg@invisible.net, "Eamon O'Tuathail" In-reply-to: Bill Mills 's message of Fri, 15 Jun 2001 00:04:06 -0700 From: Jeff.Hodges@kingsmountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 08:19:53 -0700 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 > I am perfectly willing to believe that things would break. > > I had thought that "beep:soap://example.com/" to be valid > construction of a URL per 1738, is this not the case? It looks to me that "beep:soap://example.com" is only sorta parsable by the bnf given in section 5 of 1738. It seems it would parse to a with a of "beep" and an implicitly opaque that is just a string of "xchar" (because "soap://example.com" isn't parseable using the production. In anycase, 1738 is "updated" by 2396. Given 2396's bnf (appendix A), it appears that the above URI would parse to an with a of "beep" and an of "soap://example.com". I presume that the opaque_part production is a more-or-less explicit "placeholder" to allow for future scheme-specific URI syntax definitions. So one could presumably define a bnf that "plugs in to" the production and would parse "soap://example.com"-like stuff (that appears after the "scheme:" in the URI), but it doesn't seem to be presently defined (unless there's some more-recent-than-rfc2396 doc that specifies such). But this is diving into URIs per se, and is perhaps more appropriate for the uri@w3.org list (tho one might argue that this entire thread has been ovarall appropriate for that list -- this is stuff we need to get figgered out in general, these questions are just going to keep coming up, they aren't going to go away by themselves). JeffH _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 12:15:25 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 ESMTP id MAA13195 for ; Fri, 15 Jun 2001 12:15:24 -0400 (EDT) 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 JAA27011; Fri, 15 Jun 2001 09:14:54 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA26987 for ; Fri, 15 Jun 2001 09:14:53 -0700 (PDT) Received: from norman.cp10.es.xerox.com (norman.cp10.es.xerox.com [13.240.124.12]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id MAA12543; Fri, 15 Jun 2001 12:14:49 -0400 (EDT) Received: from x-crt-es-ms1.es.cp10.es.xerox.com (x-crt-es-ms1 [13.240.124.41]) by norman.cp10.es.xerox.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25653; Fri, 15 Jun 2001 09:14:55 -0700 (PDT) Received: by x-crt-es-ms1.cp10.es.xerox.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 09:14:46 -0700 Message-ID: <918C79AB552BD211A2BD00805F15CE8504F81C6F@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: "'Marshall T. Rose'" , "Halsema, Aillil I" , bxxpwg@lists.invisibleworlds.com Cc: Marshall Rose , "Herriot, Robert" Subject: RE: [BXXPwg] IPP mapping onto bxxp Date: Fri, 15 Jun 2001 09:14:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Marshall, Bob Herriot's proposals for MIME types are not directly related to IPP. The examples that you give in your message have to do with printing over UPnP rather than over IPP... 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 -----Original Message----- From: Marshall T. Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] Sent: Thursday, June 14, 2001 11:40 PM To: Halsema, Aillil I; bxxpwg@lists.invisibleworlds.com Cc: Marshall Rose Subject: Re: [BXXPwg] IPP mapping onto bxxp > Is anyone working on mapping IPP onto bxxp? i think that the large issue is that ipp is very carefully tailored to run over http. it has a number of design features that are http-assumptive. this doesn't mean that it can't be done or that it wouldn't be a good thing. but, it wouldn't be a brief memo like the one for soap onto beep. here's an example: every couple of weeks robert herriot surfaces a draft which attempts to define an effective multiplexing format for use in ipp. the motivation is that a network printer may be unable to store an entire page of a compound document internally before it can start rendering. a multiplexed approach would allow the printer to get parts of the "container" document and parts of the "components" (e.g., images) so that it can incrementally put the page together. everytime robert herriot surfaces the latest draft, someone responds that the root problem deals with a protocol issue not an encoding issue. the counter-response is usually to make the encoding more complex, e.g., by adding more granularity or whatever. in beep, it is trivial to solve a problem like this: the desktop establishes a session with the printer and starts sending the pages of the "container" document which contains references to the "components" via URIs. when the printer needs to stop working on the container and start working on a component, it requests the relevant URI over the same session. another issue deals with asynchronous notifications from the printer back to the desktop, which are hard to do with http, but easy to do with beep. my point here is that the guys who did ipp developed a fine-crafted protocol to work on top of what http gave them. you wouldn't get a lot of joy from replacing "ipp.http" with "ipp.beep", if you're going to change things, then you need to revisit some of the basic ipp mechanisms with beep in mind... m/tr _______________________________________________ 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 Fri Jun 15 14:14: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 ESMTP id OAA20861 for ; Fri, 15 Jun 2001 14:14:47 -0400 (EDT) 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 LAA27666; Fri, 15 Jun 2001 11:14:15 -0700 (PDT) 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 LAA27652 for ; Fri, 15 Jun 2001 11:14:14 -0700 (PDT) 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 f5FIB1H25589; Fri, 15 Jun 2001 11:11:02 -0700 (PDT) Message-ID: <0bd001c0f5c6$c1ae76e0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Manros, Carl-Uno B" , "Halsema, Aillil I" , Cc: "Herriot, Robert" , "Marshall Rose" References: <918C79AB552BD211A2BD00805F15CE8504F81C6F@x-crt-es-ms1.cp10.es.xerox.com> Subject: Re: [BXXPwg] IPP mapping onto bxxp Date: Fri, 15 Jun 2001 11:12:36 -0700 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 > Bob Herriot's proposals for MIME types are not directly related to IPP. > > The examples that you give in your message have to do with printing over > UPnP > rather than over IPP... err, okay, my mistake i guess, other than to note that the printer thing always comes up when the multiplexing encoding is discussed. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 14:37: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 ESMTP id OAA22063 for ; Fri, 15 Jun 2001 14:37:36 -0400 (EDT) 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 LAA27847; Fri, 15 Jun 2001 11:37:05 -0700 (PDT) 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 LAA27832; Fri, 15 Jun 2001 11:37:04 -0700 (PDT) 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 f5FIZ8H25684; Fri, 15 Jun 2001 11:35:08 -0700 (PDT) Message-ID: <0c3b01c0f5ca$2027c4d0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bill Mills" , Cc: "'Roy T. Fielding'" , "Gabe Wachob" , , "Eamon O'Tuathail" References: <200106151519.IAA06956@breakaway.Stanford.EDU> Subject: Re: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 11:36:43 -0700 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 > But this is diving into URIs per se, and is perhaps more appropriate for the > uri@w3.org list (tho one might argue that this entire thread has been ovarall > appropriate for that list -- this is stuff we need to get figgered out in > general, these questions are just going to keep coming up, they aren't going > to go away by themselves). my take from the past history of the uri mailing list is that the topic comes up from time to time, but there hasn't been a resolution. am i wrong? /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 15:32:52 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 ESMTP id PAA25257 for ; Fri, 15 Jun 2001 15:32:51 -0400 (EDT) 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 MAA28182; Fri, 15 Jun 2001 12:32:20 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA28166 for ; Fri, 15 Jun 2001 12:32:19 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [BXXPwg] SOAP over BEEP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Jun 2001 15:33:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: Thread-Topic: [BXXPwg] SOAP over BEEP Thread-Index: AcD10iAM77MEQxdYR+mfVZYLiWVw4g== From: "Bob Wyman" To: "Bill Mills" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id MAA28167 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: 8bit Bill Mills wrote: > Perhaps the scheme should encode the the transport mode > as well so that: > > beep: beep over tcp > beeps: beep over ssl > beepsc: beep over sctp Please don't do this. The transport protocols are correctly defined distinctly from the application protocols and should be dealt with distinctly. If they are bound together, then every introduction of a new transport, tunnelling spec, etc. forces updates to a potentially large number of specifications, implementations, etc. The mere fact that http and https exist may be precedent, however, it doesn't establish the binding of application and transport protocols as best practice. bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 16:27:41 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 ESMTP id QAA28296 for ; Fri, 15 Jun 2001 16:27:41 -0400 (EDT) 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 NAA28566; Fri, 15 Jun 2001 13:27:11 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA28541; Fri, 15 Jun 2001 13:27:03 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 13:39:41 -0700 Message-ID: From: Bill Mills To: "'Ward Harold'" , Bob Wyman Cc: Bill Mills , bxxpwg@invisible.net Subject: RE: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 13:39:30 -0700 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 Well, I had intended it to be comparable to http and https, which is distict from any encryption layer withing the BEEP framework. The vector that I thought needed to be dealt with is the underlying transport mapping. Let's leave it at TCP and SCTP and ignore SSL for now then. The question stands. -----Original Message----- From: Ward Harold [mailto:wharold@tivoli.com] Sent: Friday, June 15, 2001 1:23 PM To: Bob Wyman Cc: Bill Mills; bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP Bob Wyman wrote: > Bill Mills wrote: > > Perhaps the scheme should encode the the transport mode > > as well so that: > > > > beep: beep over tcp > > beeps: beep over ssl > > beepsc: beep over sctp > > Please don't do this. The transport protocols are correctly defined > distinctly from the application protocols and should be dealt with > distinctly. If they are bound together, then every introduction of a new > transport, tunnelling spec, etc. forces updates to a potentially large > number of specifications, implementations, etc. The mere fact that http > and https exist may be precedent, however, it doesn't establish the > binding of application and transport protocols as best practice. Not to mention the fact that ssl is only one of a number of security layers that a beep profile might use. Yes, please don't do this. ... WkH _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 16:27:49 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 ESMTP id QAA28321 for ; Fri, 15 Jun 2001 16:27:48 -0400 (EDT) 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 NAA28610; Fri, 15 Jun 2001 13:27:19 -0700 (PDT) Received: from mail4.registeredsite.com (mail4.registeredsite.com [64.224.9.13]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA28591 for ; Fri, 15 Jun 2001 13:27:18 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail4.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5FKR8X21832 for ; Fri, 15 Jun 2001 16:27:17 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id A15064D400BC; Fri, 15 Jun 2001 16:34:24 -0400 Reply-To: From: "Eamon O'Tuathail" To: Subject: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 21:29:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal 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 >> > beep: beep over tcp >> > beeps: beep over ssl >> > beepsc: beep over sctp >> >> Please don't do this. I agree - we should not be combining the names like that. We need a solution that will work robustly with, say, a couple of dozen transport mappings and thousands of profiles. RFC3081 will be the most popular transport mapping by far, so I agree with the idea of defaulting "beep.tcp" to just "beep", but permitting use of "beep.tcp" and "beep.". Eamon _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 17:25:07 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 ESMTP id RAA29892 for ; Fri, 15 Jun 2001 17:25:06 -0400 (EDT) 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 OAA28926; Fri, 15 Jun 2001 14:24:31 -0700 (PDT) Received: from mail4.registeredsite.com (mail4.registeredsite.com [64.224.9.13]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28897 for ; Fri, 15 Jun 2001 14:24:26 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail4.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5FLOOX05024; Fri, 15 Jun 2001 17:24:24 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id AEBC20B500B8; Fri, 15 Jun 2001 17:31:40 -0400 Reply-To: From: "Eamon O'Tuathail" To: Cc: , Subject: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 22:26:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal 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 >> The vector that I thought needed to be dealt with is the underlying >> transport mapping. Let's leave it at TCP and SCTP and ignore SSL for >> now then. The question stands. If we are only ever going to have two transport mappings, I would agree, but what happens when (not if) we have twenty transport mappings (over the next ten years). RFC 3080 is careful to separate out the transport mapping from the BEEP core, we really need to follow this good practice with the URI. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 18:03: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 ESMTP id SAA00547 for ; Fri, 15 Jun 2001 18:02:59 -0400 (EDT) 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 PAA29124; Fri, 15 Jun 2001 15:02:29 -0700 (PDT) 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 NAA28493; Fri, 15 Jun 2001 13:22:48 -0700 (PDT) Received: from tivoli.com (dhcp38-74.dev.tivoli.com [146.84.38.74]) by devmail.dev.tivoli.com (8.9.1/8.9.1) with ESMTP id PAA19329; Fri, 15 Jun 2001 15:22:39 -0500 (CDT) Message-ID: <3B2A6E8D.918A8B9@tivoli.com> Date: Fri, 15 Jun 2001 15:22:37 -0500 From: Ward Harold Organization: Tivoli Systems X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Wyman CC: Bill Mills , bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP References: 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 Bob Wyman wrote: > Bill Mills wrote: > > Perhaps the scheme should encode the the transport mode > > as well so that: > > > > beep: beep over tcp > > beeps: beep over ssl > > beepsc: beep over sctp > > Please don't do this. The transport protocols are correctly defined > distinctly from the application protocols and should be dealt with > distinctly. If they are bound together, then every introduction of a new > transport, tunnelling spec, etc. forces updates to a potentially large > number of specifications, implementations, etc. The mere fact that http > and https exist may be precedent, however, it doesn't establish the > binding of application and transport protocols as best practice. Not to mention the fact that ssl is only one of a number of security layers that a beep profile might use. Yes, please don't do this. ... WkH _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 19:00:16 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 ESMTP id TAA01356 for ; Fri, 15 Jun 2001 19:00:15 -0400 (EDT) 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 PAA29370; Fri, 15 Jun 2001 15:59:43 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA29342; Fri, 15 Jun 2001 15:59:34 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 16:12:12 -0700 Message-ID: From: Bill Mills To: "'eamon.otuathail@clipcode.com'" , bxxpwg@lists.invisibleworlds.com Cc: wharold@tivoli.com Subject: RE: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 16:12:02 -0700 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 I do not then see how the dotted notation proposed in one of the earlier messages on this thread is any better. If I read 2396 right the scheme name is parsed complete, and would not itself be tokenized. I think using beep.: still implies a combinatorial explosion of schemes on the left had side? It would seem cleaner then to leave the protocol to be looked up with an SRV lookup i.e. beep://_beep._sctp.xml.resource.org/ Is this more palatable? -----Original Message----- From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com] Sent: Friday, June 15, 2001 2:27 PM To: bxxpwg@lists.invisibleworlds.com Cc: wmills@invisibleworlds.com; wharold@tivoli.com Subject: [BXXPwg] SOAP over BEEP >> The vector that I thought needed to be dealt with is the underlying >> transport mapping. Let's leave it at TCP and SCTP and ignore SSL for >> now then. The question stands. If we are only ever going to have two transport mappings, I would agree, but what happens when (not if) we have twenty transport mappings (over the next ten years). RFC 3080 is careful to separate out the transport mapping from the BEEP core, we really need to follow this good practice with the URI. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 21:53:57 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 ESMTP id VAA03687 for ; Fri, 15 Jun 2001 21:53:56 -0400 (EDT) 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 SAA29925; Fri, 15 Jun 2001 18:53:21 -0700 (PDT) Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3.email.verio.net [129.250.36.43]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id SAA29898 for ; Fri, 15 Jun 2001 18:53:19 -0700 (PDT) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp id 15B5H4-0000IP-00; Sat, 16 Jun 2001 01:53:18 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp1.email.verio.net with asmtp (110190536) id 15B5H4-00049M-00; Sat, 16 Jun 2001 01:53:18 +0000 From: "Dan Kohn" To: Cc: "Roy Fielding" Subject: RE: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 18:52:55 -0700 Message-ID: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 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 There is an imprecise and not fully defined mapping between application-level protocols, profiles those applications use, MIME types they carry, and transport layers they run over (including port number). One important data point on the design of HTTP URLs is RFC 2817 , which the IESG demanded so that every new protocol issued did not need 2 port numbers, one for over TCP and one for over TLS. In that sense, the https URL specification was grandfathered in but is not a good model going forward. Unfortunately, the conclusions to draw from this story are not obvious. The main question is, is there a default beep transport method (presumably beep over tcp) from which all other options can be negotiated (beep over sctp, beep over tls, etc.). If yes, at least the last layer of the ice.beep.tcp URL scheme name hierarchy is unnecessary, at the potential cost of an extra RTT or two (although appending ";transport=tls" would alleviate this cost). Another core question is whether there is an expectation of a generic beep client that speaks lots of profiles. It seems much more likely to me that my mailer, my browser, my im client, etc. will all be extended to use beep, perhaps in addition to other protocols. This implies that the beep URL scheme is not useful, since there is no obvious default beep client to invoke. An smtpbeep, webbeep, and imxp scheme would seem to work better. So, my strawman proposal is: + Any given beep profile is welcome to define it's own URL scheme + Such a scheme should define it's transfer semantics as based on beep (e.g., ice, imxp), so there's no need for "beep" to appear in the URL scheme name. + Use of alternate transport layers are negotiated upon invocation of the URL. This implies that all beep servers need to implement at least a stub TCP implementation to negotiate over to SCTP, TLS, etc. However, it's hard to imagine a more prevalent lowest common denominator than TCP support. + A default beep URL scheme should not be registered, since invocation of a beep URL has no default semantics. - dan -- Dan Kohn -----Original Message----- From: bxxpwg-admin@lists.invisibleworlds.com [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Bob Wyman Sent: Friday, June 15, 2001 12:34 To: Bill Mills Cc: bxxpwg@invisible.net Subject: RE: [BXXPwg] SOAP over BEEP Bill Mills wrote: > Perhaps the scheme should encode the the transport mode > as well so that: > > beep: beep over tcp > beeps: beep over ssl > beepsc: beep over sctp Please don't do this. The transport protocols are correctly defined distinctly from the application protocols and should be dealt with distinctly. If they are bound together, then every introduction of a new transport, tunnelling spec, etc. forces updates to a potentially large number of specifications, implementations, etc. The mere fact that http and https exist may be precedent, however, it doesn't establish the binding of application and transport protocols as best practice. bob wyman _______________________________________________ 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 Fri Jun 15 22:06: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 ESMTP id WAA03755 for ; Fri, 15 Jun 2001 22:06:42 -0400 (EDT) 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 TAA00014; Fri, 15 Jun 2001 19:06:09 -0700 (PDT) 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 TAA29983 for ; Fri, 15 Jun 2001 19:06:08 -0700 (PDT) Received: (qmail 18786 invoked by uid 3039); 16 Jun 2001 02:05:58 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Jun 2001 02:05:58 -0000 Date: Fri, 15 Jun 2001 19:05:58 -0700 (PDT) From: Gabe Wachob X-Sender: To: Dan Kohn cc: , Roy Fielding Subject: RE: [BXXPwg] SOAP over BEEP In-Reply-To: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> Message-ID: 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 Hi Dan- Your suggestion is interesting, but I don't think its a workable solution as presented. I think requiring TCP transport for all BEEP peers is a problem because there are some beep peers which are explicitly only going to able to support connection over one particular transport mechanism (say, something stupid like BEEP/WTLS in the wireless space - not saying its practical today, but maybe someday). In some cases, TCP connectivity just may not exist. Take also BEEP over something like the serial bluetooth profile... the IP profile simply may not exist on that personal area network (or whatever the bluetooth people call it). I'm not sure if you are actually suggesting that TCP be a required transport for all BEEP peers, but it sounds like it... -Gabe On Fri, 15 Jun 2001, Dan Kohn wrote: > There is an imprecise and not fully defined mapping between > application-level protocols, profiles those applications use, MIME types > they carry, and transport layers they run over (including port number). > One important data point on the design of HTTP URLs is RFC 2817 > , which the IESG demanded so > that every new protocol issued did not need 2 port numbers, one for over > TCP and one for over TLS. > > In that sense, the https URL specification > was grandfathered in but is > not a good model going forward. > > Unfortunately, the conclusions to draw from this story are not obvious. > The main question is, is there a default beep transport method > (presumably beep over tcp) from which all other options can be > negotiated (beep over sctp, beep over tls, etc.). If yes, at least the > last layer of the ice.beep.tcp URL scheme name hierarchy is unnecessary, > at the potential cost of an extra RTT or two (although appending > ";transport=tls" would alleviate this cost). > > Another core question is whether there is an expectation of a generic > beep client that speaks lots of profiles. It seems much more likely to > me that my mailer, my browser, my im client, etc. will all be extended > to use beep, perhaps in addition to other protocols. This implies that > the beep URL scheme is not useful, since there is no obvious default > beep client to invoke. An smtpbeep, webbeep, and imxp scheme would seem > to work better. > > So, my strawman proposal is: > > + Any given beep profile is welcome to define it's own URL scheme > + Such a scheme should define it's transfer semantics as based on beep > (e.g., ice, imxp), so there's no need for "beep" to appear in the URL > scheme name. > + Use of alternate transport layers are negotiated upon invocation of > the URL. This implies that all beep servers need to implement at least > a stub TCP implementation to negotiate over to SCTP, TLS, etc. However, > it's hard to imagine a more prevalent lowest common denominator than TCP > support. > + A default beep URL scheme should not be registered, since invocation > of a beep URL has no default semantics. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: bxxpwg-admin@lists.invisibleworlds.com > [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Bob Wyman > Sent: Friday, June 15, 2001 12:34 > To: Bill Mills > Cc: bxxpwg@invisible.net > Subject: RE: [BXXPwg] SOAP over BEEP > > > Bill Mills wrote: > > Perhaps the scheme should encode the the transport mode > > as well so that: > > > > beep: beep over tcp > > beeps: beep over ssl > > beepsc: beep over sctp > > Please don't do this. The transport protocols are correctly defined > distinctly from the application protocols and should be dealt with > distinctly. If they are bound together, then every introduction of a new > transport, tunnelling spec, etc. forces updates to a potentially large > number of specifications, implementations, etc. The mere fact that http > and https exist may be precedent, however, it doesn't establish the > binding of application and transport protocols as best practice. > > bob wyman > > _______________________________________________ > 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 Fri Jun 15 22:24:03 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 ESMTP id WAA03840 for ; Fri, 15 Jun 2001 22:24:03 -0400 (EDT) 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 TAA00092; Fri, 15 Jun 2001 19:23:33 -0700 (PDT) Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3.email.verio.net [129.250.36.43]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id TAA00075 for ; Fri, 15 Jun 2001 19:23:32 -0700 (PDT) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp id 15B5kK-0002DT-00; Sat, 16 Jun 2001 02:23:32 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp4.email.verio.net with asmtp (110190536) id 15B5kJ-0002mB-00; Sat, 16 Jun 2001 02:23:31 +0000 From: "Dan Kohn" To: "'Gabe Wachob'" Cc: , "'Roy Fielding'" Subject: RE: [BXXPwg] SOAP over BEEP Date: Fri, 15 Jun 2001 19:23:19 -0700 Message-ID: <002001c0f60b$4fcf4230$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 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 first, an awful number of things currently more critical to the Internet infrastructure than BEEP would break if TCP were to go away. But, on reflection, I have a modified third point to my strawman: + Each URL scheme for a BEEP profile specifies the default transport mapping. Communication is begun on that transport but can then be negotiated on to a different one. Given TCP's obvious ubiquity, it would seem a real mistake to require that a client invoking a BEEP URL scheme support SCTP, TLS, WTLS, etc. OTOH, there's no reason to a priori prohibit it. - dan -- Dan Kohn -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Friday, June 15, 2001 19:06 To: Dan Kohn Cc: bxxpwg@invisible.net; Roy Fielding Subject: RE: [BXXPwg] SOAP over BEEP Hi Dan- Your suggestion is interesting, but I don't think its a workable solution as presented. I think requiring TCP transport for all BEEP peers is a problem because there are some beep peers which are explicitly only going to able to support connection over one particular transport mechanism (say, something stupid like BEEP/WTLS in the wireless space - not saying its practical today, but maybe someday). In some cases, TCP connectivity just may not exist. Take also BEEP over something like the serial bluetooth profile... the IP profile simply may not exist on that personal area network (or whatever the bluetooth people call it). I'm not sure if you are actually suggesting that TCP be a required transport for all BEEP peers, but it sounds like it... -Gabe On Fri, 15 Jun 2001, Dan Kohn wrote: > There is an imprecise and not fully defined mapping between > application-level protocols, profiles those applications use, MIME types > they carry, and transport layers they run over (including port number). > One important data point on the design of HTTP URLs is RFC 2817 > , which the IESG demanded so > that every new protocol issued did not need 2 port numbers, one for over > TCP and one for over TLS. > > In that sense, the https URL specification > was grandfathered in but is > not a good model going forward. > > Unfortunately, the conclusions to draw from this story are not obvious. > The main question is, is there a default beep transport method > (presumably beep over tcp) from which all other options can be > negotiated (beep over sctp, beep over tls, etc.). If yes, at least the > last layer of the ice.beep.tcp URL scheme name hierarchy is unnecessary, > at the potential cost of an extra RTT or two (although appending > ";transport=tls" would alleviate this cost). > > Another core question is whether there is an expectation of a generic > beep client that speaks lots of profiles. It seems much more likely to > me that my mailer, my browser, my im client, etc. will all be extended > to use beep, perhaps in addition to other protocols. This implies that > the beep URL scheme is not useful, since there is no obvious default > beep client to invoke. An smtpbeep, webbeep, and imxp scheme would seem > to work better. > > So, my strawman proposal is: > > + Any given beep profile is welcome to define it's own URL scheme > + Such a scheme should define it's transfer semantics as based on beep > (e.g., ice, imxp), so there's no need for "beep" to appear in the URL > scheme name. > + Use of alternate transport layers are negotiated upon invocation of > the URL. This implies that all beep servers need to implement at least > a stub TCP implementation to negotiate over to SCTP, TLS, etc. However, > it's hard to imagine a more prevalent lowest common denominator than TCP > support. > + A default beep URL scheme should not be registered, since invocation > of a beep URL has no default semantics. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: bxxpwg-admin@lists.invisibleworlds.com > [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Bob Wyman > Sent: Friday, June 15, 2001 12:34 > To: Bill Mills > Cc: bxxpwg@invisible.net > Subject: RE: [BXXPwg] SOAP over BEEP > > > Bill Mills wrote: > > Perhaps the scheme should encode the the transport mode > > as well so that: > > > > beep: beep over tcp > > beeps: beep over ssl > > beepsc: beep over sctp > > Please don't do this. The transport protocols are correctly defined > distinctly from the application protocols and should be dealt with > distinctly. If they are bound together, then every introduction of a new > transport, tunnelling spec, etc. forces updates to a potentially large > number of specifications, implementations, etc. The mere fact that http > and https exist may be precedent, however, it doesn't establish the > binding of application and transport protocols as best practice. > > bob wyman > > _______________________________________________ > 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 Fri Jun 15 22:43: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 ESMTP id WAA05047 for ; Fri, 15 Jun 2001 22:43:08 -0400 (EDT) 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 TAA00185; Fri, 15 Jun 2001 19:42:39 -0700 (PDT) Received: from pretender.boolean.net (router.boolean.net [198.144.206.49]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id TAA00166 for ; Fri, 15 Jun 2001 19:42:38 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f5G2cR046297; Sat, 16 Jun 2001 02:38:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010615193006.00ae82d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Jun 2001 19:41:25 -0700 To: "Dan Kohn" From: "Kurt D. Zeilenga" Subject: RE: [BXXPwg] SOAP over BEEP Cc: In-Reply-To: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> References: 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 At 06:52 PM 6/15/2001, Dan Kohn wrote: >So, my strawman proposal is: > >+ Any given beep profile is welcome to define it's own URL scheme >+ Such a scheme should define it's transfer semantics as based on beep >(e.g., ice, imxp), so there's no need for "beep" to appear in the URL >scheme name. >+ Use of alternate transport layers are negotiated upon invocation of >the URL. This implies that all beep servers need to implement at least >a stub TCP implementation to negotiate over to SCTP, TLS, etc. However, >it's hard to imagine a more prevalent lowest common denominator than TCP >support. >+ A default beep URL scheme should not be registered, since invocation >of a beep URL has no default semantics. This sounds like a fairly reasonable proposal. I note that LDAPext had a discussion about how to construct URL for various LDAP mappings. While URLs which explicitly specify a mapping can be useful: ldap.tcp://example.net/ ldap.udp://example.net/ ldap.sctp://example.net/ ldap.beep://example.net/ ldap.beep.sctp://example.net/ ldap.beep.tcp://example.net/ It is often advantageous just to say: ldap://example.net/ and let the client figure out the best way to locate the service. A client can use DNS SRV or other means (including querying the service over the default mapping) to determine which mappings are supported. Kurt _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 22:54:17 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 ESMTP id WAA05111 for ; Fri, 15 Jun 2001 22:54:16 -0400 (EDT) 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 TAA00274; Fri, 15 Jun 2001 19:53:36 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id TAA00251 for ; Fri, 15 Jun 2001 19:53:36 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5G2rSR26307 for ; Fri, 15 Jun 2001 19:53:28 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5G2rML26056; Fri, 15 Jun 2001 19:53:26 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5G2oPU01178; Fri, 15 Jun 2001 19:50:25 -0700 Date: Fri, 15 Jun 2001 19:50:25 -0700 From: "Roy T. Fielding" To: "Marshall T. Rose" Cc: Gabe Wachob , bxxpwg@invisible.net, "Eamon O'Tuathail" , Marshall Rose Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010615195025.E920@waka.ebuilt.net> References: <04b601c0f478$ef6217d0$8753cf3f@FATORA> <20010613203107.D1183@waka.ebuilt.net> <055b01c0f48b$fe524590$8753cf3f@FATORA> <20010614153508.A909@waka.ebuilt.net> <09f301c0f525$a7481cd0$8753cf3f@FATORA> <20010614175510.D909@waka.ebuilt.net> <0aa001c0f566$bcc17c00$8753cf3f@FATORA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <0aa001c0f566$bcc17c00$8753cf3f@FATORA>; from mrose+mtr.netnews@dbc.mtview.ca.us on Thu, Jun 14, 2001 at 11:44:58PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 > 1. let me understand your reaction to > > > > ideally, i would prefer to avoid having to use a new scheme everytime > > > someone moves yet another service on top of beep. > > > > Hmmm, why? Logically, they are distinct services. Keep in mind that the > > "http" URL is specific to HTTP over TCP, even though HTTP itself is not > > dependent on TCP. If we were to deploy a new HTTP-over-SCTP service, > > we would need a new URL scheme because the authority syntax of > hostname:port > > is specific to TCP, not HTTP. > > i don't think that the http/tcp to http/sctp analogy is a good one. what i'm > trying to understand is whether it is a good thing to define two schemes for > soap.beep.tcp and ice.beep.tcp or to just have one scheme for beep over tcp. > for all three schemes, the authority part remains the same. The dns name within the authority part may be the same, but its interpretation tends to be specific to the URI scheme. The reason I used the tcp/sctp analogy is because that is the slimmest margin of difference, and yet it does require a different URI scheme because example.com:80 (tcp) and example.com:80 (sctp) are two different naming authorities -- the software listening to TCP port 80 is not capable of giving authoritative answers for the resources named by SCTP port 80, for the same reason that a web server at TCP port 8001 is not allowed to give authoritative answers for another web server on TCP port 80. > in guess i see your point that > > > > beep://example.com?profile=http://iana.org/beep/soap > > is pretty week. The biggest problem with it in practice is what happens when you do want to name a resource within beep, and that resource has the ability to accept data. You can't have more than one ? in the URI syntax. However, what people really want to do is name the resources made available by the upper-layer protocol -- beep and its profile names are less significant to the name even if they are a dependency. That's why I wouldn't define a "beep" URL scheme, unless there is some resource to be named within the beep service itself [such as a management interface]. > 2. anyway, in comparing: > > soap://example.com:beep.tcp.21212/path > soap.beep.tcp://example.com:21212/path > > i guess i prefer the latter since when we move from "beep.tcp.21212" to > "beep.ipv6.21212" the thing to the left is going to be funky. what isn't > clear to me is whether the iana is going to be happy when i start > registering url schemes in groups of three, e.g., > > ice: > ice.beep: > ice.beep.tcp: I think that it is only necessary to register the default as ice and additional ones only when they differ from the default. IANA may not be happy with it, but that is better than requiring every handler of "ice" URLs to implement (or at least know about) every possible layering. Applications tend to implement only one application-layer at a time. I don't think that "beep.ipv6.21212" would ever be necessary because the IP layer is defined by the hostname, and is therefore already represented within the authority component. Note that ipv6 literals can already be included within URLs via the square-bracketed ipv6-literal syntax. Likewise, if ice were to use some DNS attribute to select which session layer protocol should be used, rather than encoding it within the URL, then you wouldn't need ice.beep at all. Someone might want it anyway, though, just to be able to override the DNS response. *shrug* As a WWW software developer, I would prefer to implement it as a new scheme. However, as a protocol architect, I think that if I were inventing it from scratch and not worrying about the already deployed authority parsers, then I would include this information in the authority component rather than the scheme. It is possible that we may end up being forced in that direction when RFC 2396 is revised, regardless of the running code. Please keep in mind, however, that the protocol stuff within a URL only defines how the naming authority is contacted when it needs to be contacted, and thus doesn't directly tell the client what to do -- a client chooses what to do for a given URL according to its own configuration and the context in which the URL was found. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 15 23:54:02 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 ESMTP id XAA05843 for ; Fri, 15 Jun 2001 23:54:01 -0400 (EDT) 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 UAA00523; Fri, 15 Jun 2001 20:53:25 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id UAA00459 for ; Fri, 15 Jun 2001 20:53:23 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5G3rNK03642 for ; Fri, 15 Jun 2001 20:53:23 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5G3rML03561; Fri, 15 Jun 2001 20:53:22 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5G3qXg01219; Fri, 15 Jun 2001 20:52:33 -0700 Date: Fri, 15 Jun 2001 20:52:33 -0700 From: "Roy T. Fielding" To: Dan Kohn Cc: bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010615205233.F920@waka.ebuilt.net> References: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com>; from dan@dankohn.com on Fri, Jun 15, 2001 at 06:52:55PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Fri, Jun 15, 2001 at 06:52:55PM -0700, Dan Kohn wrote: > There is an imprecise and not fully defined mapping between > application-level protocols, profiles those applications use, MIME types > they carry, and transport layers they run over (including port number). > One important data point on the design of HTTP URLs is RFC 2817 > , which the IESG demanded so > that every new protocol issued did not need 2 port numbers, one for over > TCP and one for over TLS. > > In that sense, the https URL specification > was grandfathered in but is > not a good model going forward. That is not sufficient. The client must know whether or not the connection must be secured before it makes the first resource request of the server. In order to know that, the information must be in the URI. The mechanism used to establish the secure session might be present in the protocol, as it is with HTTP/1.1 Upgrade, but the decision to make that upgrade mandatory prior to sending any sensitive information is something that the client must make using only the URI as a guide. The IESG objected to multiple TCP ports per protocol, not multiple scheme names. There is no reason why a new "s" scheme cannot be defined with the same default port as the normal scheme, just as there is no reason why https services cannot be located on port 80. The client, however, still needs the distinct schemes in order to know how it should contact the server. https, in particular, not only requires that contact with the naming authority be secure, it also requires that all application hops along the way to the naming authority be secure, and further that nothing on that chain be cachable by default. https therefore defines much more than simply HTTP over SSL. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 16 00:11:56 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 ESMTP id AAA05948 for ; Sat, 16 Jun 2001 00:11:56 -0400 (EDT) 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 VAA00608; Fri, 15 Jun 2001 21:11:24 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA00594 for ; Fri, 15 Jun 2001 21:11:23 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5G4BNl05721 for ; Fri, 15 Jun 2001 21:11:23 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5G4BNL05640; Fri, 15 Jun 2001 21:11:23 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5G49Wm01234; Fri, 15 Jun 2001 21:09:32 -0700 Date: Fri, 15 Jun 2001 21:09:32 -0700 From: "Roy T. Fielding" To: Jeff.Hodges@kingsmountain.com Cc: bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010615210932.G920@waka.ebuilt.net> References: <200106151519.IAA06956@breakaway.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <200106151519.IAA06956@breakaway.Stanford.EDU>; from Jeff.Hodges@kingsmountain.com on Fri, Jun 15, 2001 at 08:19:53AM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 > I presume that the opaque_part production is a more-or-less explicit > "placeholder" to allow for future scheme-specific URI syntax definitions. So > one could presumably define a bnf that "plugs in to" the > production and would parse "soap://example.com"-like stuff (that appears > after the "scheme:" in the URI), but it doesn't seem to be presently defined > (unless there's some more-recent-than-rfc2396 doc that specifies such). It exists to support schemes that, for one (lame) reason or another, were defined with a syntax that does not allow relative forms. While the RFC allows such schemes, the implication of using them is that you don't want anyone to reuse code that already exists to parse the components of a URI in a common way. For some schemes, that is actually appropriate. Another way to think about it, or at least another point to consider, is that stubborn software developers like me often refuse to implement URI schemes that are designed to make our lives harder than they need to be. A good software architect will take that into consideration when designing a new application protocol. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 16 10:38: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 ESMTP id KAA24448 for ; Sat, 16 Jun 2001 10:38:08 -0400 (EDT) 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 HAA02047; Sat, 16 Jun 2001 07:37:32 -0700 (PDT) Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id HAA02031; Sat, 16 Jun 2001 07:37:31 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA21813; Sat, 16 Jun 2001 10:37:01 -0400 (EDT) Date: Sat, 16 Jun 2001 10:36:59 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Ward Harold Cc: Bob Wyman , Bill Mills , bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP In-Reply-To: Your message of Fri, 15 Jun 2001 15:22:37 -0500 Message-ID: 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 > Bob Wyman wrote: > > > Bill Mills wrote: > > > Perhaps the scheme should encode the the transport mode > > > as well so that: > > > > > > beep: beep over tcp > > > beeps: beep over ssl > > > beepsc: beep over sctp > > > > Please don't do this. The transport protocols are correctly defined > > distinctly from the application protocols and should be dealt with > > distinctly. If they are bound together, then every introduction of a new > > transport, tunnelling spec, etc. forces updates to a potentially large > > number of specifications, implementations, etc. The mere fact that http > > and https exist may be precedent, however, it doesn't establish the > > binding of application and transport protocols as best practice. > > Not to mention the fact that ssl is only one of a number of security layers > that a beep profile might use. Yes, please don't do this. > > ... WkH > Why not use something similar to the JDBC URLs in Java: beep:tcp beep:tcp:ssl beep:sctp _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 16 12:15: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 ESMTP id MAA24823 for ; Sat, 16 Jun 2001 12:15:19 -0400 (EDT) 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 JAA02308; Sat, 16 Jun 2001 09:14:49 -0700 (PDT) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA02294 for ; Sat, 16 Jun 2001 09:14:48 -0700 (PDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 15BIim-0005FB-00; Sat, 16 Jun 2001 16:14:48 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp3.email.verio.net with asmtp (110190536) id 15BIil-00014f-00; Sat, 16 Jun 2001 16:14:47 +0000 From: "Dan Kohn" To: "'Roy T. Fielding'" Cc: Subject: RE: [BXXPwg] SOAP over BEEP Date: Sat, 16 Jun 2001 09:14:35 -0700 Message-ID: <000001c0f67f$702ab360$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20010615205233.F920@waka.ebuilt.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 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 Roy, I think you make great points that a) the URL scheme can signify more than just secure or not (such as caching)) and that b) it's essential that the client not reveal more information than necessary by during the security negotiation. However, my read of RFC 3080 is that it is possible for the BEEP peer to provide a tuning profile that ONLY indicates upgrading to TLS (or whatever, including intricate combinations of transport and SASL profiles), and fails to return anything else. See, for example, the long example at the beginning of section 3. In that case, no cleartext data communication is made. Phrased differently, the first resource request -- if it is a request for a secure channel -- is always tuned in the clear, and so a single URL scheme should suffice. - dan -- Dan Kohn -----Original Message----- From: Roy T. Fielding [mailto:fielding@ebuilt.com] Sent: Friday, June 15, 2001 20:53 To: Dan Kohn Cc: bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP On Fri, Jun 15, 2001 at 06:52:55PM -0700, Dan Kohn wrote: > There is an imprecise and not fully defined mapping between > application-level protocols, profiles those applications use, MIME types > they carry, and transport layers they run over (including port number). > One important data point on the design of HTTP URLs is RFC 2817 > , which the IESG demanded so > that every new protocol issued did not need 2 port numbers, one for over > TCP and one for over TLS. > > In that sense, the https URL specification > was grandfathered in but is > not a good model going forward. That is not sufficient. The client must know whether or not the connection must be secured before it makes the first resource request of the server. In order to know that, the information must be in the URI. The mechanism used to establish the secure session might be present in the protocol, as it is with HTTP/1.1 Upgrade, but the decision to make that upgrade mandatory prior to sending any sensitive information is something that the client must make using only the URI as a guide. The IESG objected to multiple TCP ports per protocol, not multiple scheme names. There is no reason why a new "s" scheme cannot be defined with the same default port as the normal scheme, just as there is no reason why https services cannot be located on port 80. The client, however, still needs the distinct schemes in order to know how it should contact the server. https, in particular, not only requires that contact with the naming authority be secure, it also requires that all application hops along the way to the naming authority be secure, and further that nothing on that chain be cachable by default. https therefore defines much more than simply HTTP over SSL. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 16 12:45: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 ESMTP id MAA24910 for ; Sat, 16 Jun 2001 12:45:33 -0400 (EDT) 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 JAA02417; Sat, 16 Jun 2001 09:45:02 -0700 (PDT) Received: from mail3.registeredsite.com (mail3.registeredsite.com [64.224.9.12]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA02404 for ; Sat, 16 Jun 2001 09:45:01 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail3.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5GGirj25858 for ; Sat, 16 Jun 2001 12:44:57 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id AEC18900E2; Sat, 16 Jun 2001 12:52:17 -0400 Reply-To: From: "Eamon O'Tuathail" To: Subject: [BXXPwg] SOAP over BEEP Date: Sat, 16 Jun 2001 17:47:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 >> Why not use something similar to the JDBC URLs in Java: >> >> beep:tcp >> beep:tcp:ssl >> beep:sctp As Roy says at: http://lists.invisible.net/pipermail/bxxpwg/2001-June/000523.html "You have no idea how many systems you would break simply by choosing beep:soap://example.com/ over soap.beep://example.com/ They may seem the same, but the first requires an algorithm change in every deployed piece of Web software, whereas the second just requires the addition of a plug-in handler." _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sun Jun 17 19:42: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 ESMTP id TAA12935 for ; Sun, 17 Jun 2001 19:42:19 -0400 (EDT) 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 QAA07248; Sun, 17 Jun 2001 16:41:24 -0700 (PDT) Received: from watervalley.net (mail.WaterValley.Net [216.220.140.3]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id QAA07229 for ; Sun, 17 Jun 2001 16:41:22 -0700 (PDT) Received: from [24.29.193.111] (HELO [10.0.1.7]) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0003853120 for ; Sun, 17 Jun 2001 17:42:30 -0600 Mime-Version: 1.0 X-Sender: bdist-cmh@mail.bdistributed.com Message-Id: In-Reply-To: References: Date: Sun, 17 Jun 2001 13:56:12 -0500 To: bxxpwg@lists.invisibleworlds.com From: Chris Hanson Subject: RE: [BXXPwg] SOAP over BEEP Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 4:12 PM -0700 6/15/01, Bill Mills wrote: >It would seem cleaner then to leave the protocol to be looked up with an SRV >lookup i.e. > > beep://_beep._sctp.xml.resource.org/ > >Is this more palatable? I for one don't want to see SRV lookups relied upon too heavily. There are quite a few people who will be able to deploy BEEP services on servers they control within DNS spaces they *don't*. One of the great things about the web is that in the common case setting up a web server doesn't require involvement from unreliable third parties (in this case, site administrators). -- Chris -- Chris Hanson bDistributed.com: Making Business Distributed _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 02:13:59 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 ESMTP id CAA27835 for ; Mon, 18 Jun 2001 02:13:58 -0400 (EDT) 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 XAA08318; Sun, 17 Jun 2001 23:13:06 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id XAA08298 for ; Sun, 17 Jun 2001 23:13:06 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5I6D2f22322 for ; Sun, 17 Jun 2001 23:13:02 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5I6CwL22241; Sun, 17 Jun 2001 23:13:02 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5I69i001016; Sun, 17 Jun 2001 23:09:44 -0700 Date: Sun, 17 Jun 2001 23:09:44 -0700 From: "Roy T. Fielding" To: Dan Kohn Cc: bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010617230944.E908@waka.ebuilt.net> References: <20010615205233.F920@waka.ebuilt.net> <000001c0f67f$702ab360$6a01a8c0@skymoonventures.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <000001c0f67f$702ab360$6a01a8c0@skymoonventures.com>; from dan@dankohn.com on Sat, Jun 16, 2001 at 09:14:35AM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Sat, Jun 16, 2001 at 09:14:35AM -0700, Dan Kohn wrote: > However, my read of RFC 3080 is that it is possible for the BEEP peer to > provide a tuning profile that ONLY indicates upgrading to TLS (or > whatever, including intricate combinations of transport and SASL > profiles), and fails to return anything else. See, for example, the > long example at the beginning of section 3. > > In that case, no cleartext data communication is made. Phrased > differently, the first resource request -- if it is a request for a > secure channel -- is always tuned in the clear, and so a single URL > scheme should suffice. Yes, if the protocol is designed such that the client must read a message from the server prior to it sending any data across the connection, then the security context can be established prior to the client sending data. That is, assuming that the server knows what the security context should be when it establishes the connection. The problem with such a mechanism is that it doesn't work with intermediaries. A client with a long-lived session connected to a peer acting like an http proxy isn't likely to be negotiating a new channel context before making each request. Thus, such an architecture would require that all proxy communication be restricted to the GCD of all possible security profiles, unless the identifiers contain the security information regardless. Fortunately, HTTP doesn't have that feature. ;-) ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 14:57:03 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 ESMTP id OAA16705 for ; Mon, 18 Jun 2001 14:57:02 -0400 (EDT) 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 LAA11821; Mon, 18 Jun 2001 11:56:18 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA11808; Mon, 18 Jun 2001 11:56:17 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 12:09:03 -0700 Message-ID: From: Bill Mills To: "'eamon.otuathail@clipcode.com'" , bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 12:09:02 -0700 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 I had not asked this before, but does this indicate that the algorithms currently in use do not conform to the RFC per se? Admittedly we fall into the vague : type of construction. -----Original Message----- From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com] Sent: Saturday, June 16, 2001 9:47 AM To: bxxpwg@lists.invisibleworlds.com Subject: [BXXPwg] SOAP over BEEP >> Why not use something similar to the JDBC URLs in Java: >> >> beep:tcp >> beep:tcp:ssl >> beep:sctp As Roy says at: http://lists.invisible.net/pipermail/bxxpwg/2001-June/000523.html "You have no idea how many systems you would break simply by choosing beep:soap://example.com/ over soap.beep://example.com/ They may seem the same, but the first requires an algorithm change in every deployed piece of Web software, whereas the second just requires the addition of a plug-in handler." _______________________________________________ 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 Mon Jun 18 16:20:45 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 ESMTP id QAA20036 for ; Mon, 18 Jun 2001 16:20:44 -0400 (EDT) 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 NAA12374; Mon, 18 Jun 2001 13:20:10 -0700 (PDT) Received: from mail4.registeredsite.com (mail4.registeredsite.com [64.224.9.13]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA12350 for ; Mon, 18 Jun 2001 13:20:09 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail4.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5IKK3x29287; Mon, 18 Jun 2001 16:20:03 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id A4205EAB012C; Mon, 18 Jun 2001 16:27:12 -0400 Reply-To: From: "Eamon O'Tuathail" To: "Bill Mills" , Subject: RE: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 21:22:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 Bill, RFC 2396 - section 3, first paragraph - The scheme name is up to the first ':'. Most pieces of deployed software only look at that and then branch off to a handler - and these handlers are usually configurable based on the scheme name. They will give you the (from just past to the first ':' to the end). If you plan to use a ':' separated scheme name, then you will need some sort of super-handler that is smart enough to work out the second part of the scheme name. If you use the '.' notation (e.g. "soap.beep"), then you can directly activate a suitable soap handler. >> does this indicate that the algorithms >> currently in use do not conform to the RFC per se? Which algorithms are you talking about? To which specs / drafts do they belong? Eamon _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 16:37:56 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 ESMTP id QAA20478 for ; Mon, 18 Jun 2001 16:37:54 -0400 (EDT) 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 NAA12490; Mon, 18 Jun 2001 13:37:26 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA12470; Mon, 18 Jun 2001 13:37:16 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 13:50:03 -0700 Message-ID: From: Bill Mills To: "'eamon.otuathail@clipcode.com'" , Bill Mills , bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 13:50:02 -0700 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 I was in fact thinking of a super-handler type thing. My thought was that it would be worthwhile to reduce the required number of handlers, especially when we have the addidtional vector of transport type (tcp/sctp/...). -bill -----Original Message----- From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com] Sent: Monday, June 18, 2001 1:22 PM To: Bill Mills; bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] SOAP over BEEP Bill, RFC 2396 - section 3, first paragraph - The scheme name is up to the first ':'. Most pieces of deployed software only look at that and then branch off to a handler - and these handlers are usually configurable based on the scheme name. They will give you the (from just past to the first ':' to the end). If you plan to use a ':' separated scheme name, then you will need some sort of super-handler that is smart enough to work out the second part of the scheme name. If you use the '.' notation (e.g. "soap.beep"), then you can directly activate a suitable soap handler. >> does this indicate that the algorithms >> currently in use do not conform to the RFC per se? Which algorithms are you talking about? To which specs / drafts do they belong? Eamon _______________________________________________ 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 Mon Jun 18 17:01: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 ESMTP id RAA21070 for ; Mon, 18 Jun 2001 17:01:33 -0400 (EDT) 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 OAA12644; Mon, 18 Jun 2001 14:01:04 -0700 (PDT) Received: from mail2.registeredsite.com (mail2.registeredsite.com [64.224.9.11]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA12623 for ; Mon, 18 Jun 2001 14:00:56 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail2.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5IL0Vw30805; Mon, 18 Jun 2001 17:00:32 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id AD902C900C8; Mon, 18 Jun 2001 17:07:28 -0400 Reply-To: From: "Eamon O'Tuathail" To: "Bill Mills" , Subject: RE: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 22:02:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 The idea of a superhandler would be neat, but ... from a practical viewpoint, having multiple ':' could well trip up many generic implementations, and >From a standards perspective, RFC 2396, states: "Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI." reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," and later: "Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved." You don't have to follow the "scheme>://?" approach - but the vast majority of implementations do. "The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI." The BNF in RFC 2396, appendix A does permit use of ':' in the opaque_part. The more you stray from what people expect, the more likely things will be broken. Eamon _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 17:08:28 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 ESMTP id RAA21221 for ; Mon, 18 Jun 2001 17:08:27 -0400 (EDT) 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 OAA12716; Mon, 18 Jun 2001 14:07:58 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA12698; Mon, 18 Jun 2001 14:07:49 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 14:20:36 -0700 Message-ID: From: Bill Mills To: "'eamon.otuathail@clipcode.com'" , bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 14:20:35 -0700 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 I don't know if I like it as much but what about beep://foo.com:::/ This would allow us to stay near the current usages for URL's. It has the disadvantage of significantly overloading the current usage for port specification in HTTP. Again I think the ugliest thing here is if we end up needing a full URL to identify the profile. -bil -----Original Message----- From: Eamon O'Tuathail [mailto:eamon.otuathail@clipcode.com] Sent: Monday, June 18, 2001 2:03 PM To: Bill Mills; bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] SOAP over BEEP The idea of a superhandler would be neat, but ... from a practical viewpoint, having multiple ':' could well trip up many generic implementations, and >From a standards perspective, RFC 2396, states: "Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI." reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," and later: "Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved." You don't have to follow the "scheme>://?" approach - but the vast majority of implementations do. "The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI." The BNF in RFC 2396, appendix A does permit use of ':' in the opaque_part. The more you stray from what people expect, the more likely things will be broken. Eamon _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 17:16:17 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 ESMTP id RAA21449 for ; Mon, 18 Jun 2001 17:16:16 -0400 (EDT) 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 OAA12795; Mon, 18 Jun 2001 14:15:47 -0700 (PDT) Received: from mutley.ebuilt.net ([209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA12778 for ; Mon, 18 Jun 2001 14:15:46 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5ILEPX06071 for ; Mon, 18 Jun 2001 14:14:25 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5ILEPL05990; Mon, 18 Jun 2001 14:14:25 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5ILCrM07410; Mon, 18 Jun 2001 14:12:53 -0700 Date: Mon, 18 Jun 2001 14:12:53 -0700 From: "Roy T. Fielding" To: Bill Mills Cc: "'eamon.otuathail@clipcode.com'" , bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010618141253.C901@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from wmills@invisibleworlds.com on Mon, Jun 18, 2001 at 12:09:02PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Mon, Jun 18, 2001 at 12:09:02PM -0700, Bill Mills wrote: > I had not asked this before, but does this indicate that the algorithms > currently in use do not conform to the RFC per se? Admittedly we fall into > the vague : type of construction. Yes, there are still a significant number of applications that do not conform to RFC 2396. Older versions of Netscape Navigator are the worst. In any case, the scheme1:scheme2:* syntax makes it impossible for the URL to be used with relative URI, and prevents generic URI parsing code from being used to separate the URI into components for use. It is therefore a bad design unless it is the designer's intention to make it harder to implement the URI with relative forms and existing parsers. The "." was included in the URI scheme syntax specifically for this purpose. I don't understand why anyone would try to avoid it. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 17:30:29 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 ESMTP id RAA21681 for ; Mon, 18 Jun 2001 17:30:28 -0400 (EDT) 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 OAA12905; Mon, 18 Jun 2001 14:29:57 -0700 (PDT) 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 OAA12885 for ; Mon, 18 Jun 2001 14:29:53 -0700 (PDT) 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 f5ILRSF10478; Mon, 18 Jun 2001 14:27:30 -0700 (PDT) Message-ID: <147a01c0f83d$cbe0e160$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" References: Subject: Re: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 14:29:28 -0700 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 don't know if I like it as much but what about > > beep://foo.com:::/ > > This would allow us to stay near the current usages for URL's. It has > the disadvantage of significantly overloading the current usage for port > specification in HTTP. > > Again I think the ugliest thing here is if we end up needing a full > URL to identify the profile. i'll pass. this is abstracting the wrong thing. beep isn't a protocol or a service. it doesn't make sense to specify a url scheme for it. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 19:49:08 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 ESMTP id TAA24384 for ; Mon, 18 Jun 2001 19:49:08 -0400 (EDT) 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 QAA13682; Mon, 18 Jun 2001 16:48:33 -0700 (PDT) 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 QAA13660 for ; Mon, 18 Jun 2001 16:48:32 -0700 (PDT) Received: (qmail 88383 invoked by uid 3039); 18 Jun 2001 23:48:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Jun 2001 23:48:23 -0000 Date: Mon, 18 Jun 2001 16:48:23 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Marshall T. Rose" cc: , Marshall Rose Subject: Re: [BXXPwg] SOAP over BEEP In-Reply-To: <147a01c0f83d$cbe0e160$8753cf3f@FATORA> Message-ID: 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 On Mon, 18 Jun 2001, Marshall T. Rose wrote: > i'll pass. this is abstracting the wrong thing. beep isn't a protocol or a > service. it doesn't make sense to specify a url scheme for it. I think I started this thread, so let me say thats its become clear that what I was really asking about (though in my fuzzy thinking I may not have actually stated such) was how to pass around an endpoint descriptor - for example, to configure an application to talk to a particular BEEP listener. Its become clear from this discussion, at least to me, that in almost any use case I can come up with, all that is really needed is a hostname/ip & port number (for TCP binding). The application consuming this endpoint descriptor will presumably know whats there; if it didn't know what profile to use there, how could it be doing anything useful. In other words, for a given endpoint, I don't see a situation where the profile to be used (or profiles) isn't implied by the context in which the endpoint is being used. Thus, no real need for URLs except something very basic like beep:: Counterexamples? -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 19:58:46 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 ESMTP id TAA24568 for ; Mon, 18 Jun 2001 19:58:45 -0400 (EDT) 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 QAA13764; Mon, 18 Jun 2001 16:58:16 -0700 (PDT) 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 QAA13746 for ; Mon, 18 Jun 2001 16:58:15 -0700 (PDT) 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 f5INtuF11043; Mon, 18 Jun 2001 16:55:56 -0700 (PDT) Message-ID: <170301c0f852$887f8880$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Gabe Wachob" Cc: References: Subject: Re: [BXXPwg] SOAP over BEEP Date: Mon, 18 Jun 2001 16:58:11 -0700 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 > Thus, no real need for URLs except something very basic like > beep:: > > Counterexamples? i think that it makes sense to define a URL scheme for a protocol that is based on beep, e.g., soap.beep://example.com?resource=stockTicker what makes no sense to me is defining a URL scheme for beep, per se. in the example that you give, how is one to know what profile to start? /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 18 20:07:47 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 ESMTP id UAA24775 for ; Mon, 18 Jun 2001 20:07:46 -0400 (EDT) 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 RAA13837; Mon, 18 Jun 2001 17:07:17 -0700 (PDT) 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 RAA13821 for ; Mon, 18 Jun 2001 17:07:16 -0700 (PDT) Received: (qmail 90969 invoked by uid 3039); 19 Jun 2001 00:07:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2001 00:07:15 -0000 Date: Mon, 18 Jun 2001 17:07:15 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Marshall T. Rose" cc: Subject: Re: [BXXPwg] SOAP over BEEP In-Reply-To: <170301c0f852$887f8880$8753cf3f@FATORA> Message-ID: 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 In the example I give, I am giving the endpoint to an application, or another person to stick in their application. I presume the application will know what to do... e.g. the profile to start. Are there going to be applications which can run arbitrary BEEP profiles? In which case, yes, you'd have to include the profile with the endpoint... I'm trying to figure out a real example of such... I guess maybe there is increasingly a new class of applications where the "physical transport" is not specified and that somehow that physical transport (or something even above it like BEEP) must be specified along with the protocol's logical endpoint naming scheme (a la soap.beep naming below). I just don't have a feel for how that will actually play out - will SOAP clients be frequently using HTTP transport along side BEEP transport, or will this be a toggle/preference/configuration issue that is not done on a per-interaction basis? -Gabe On Mon, 18 Jun 2001, Marshall T. Rose wrote: > > Thus, no real need for URLs except something very basic like > > beep:: > > > > Counterexamples? > > i think that it makes sense to define a URL scheme for a protocol that is > based on beep, e.g., > > soap.beep://example.com?resource=stockTicker > > what makes no sense to me is defining a URL scheme for beep, per se. > > in the example that you give, how is one to know what profile to start? > > /mtr > > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 00:11:33 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 ESMTP id AAA29968 for ; Tue, 19 Jun 2001 00:11:33 -0400 (EDT) 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 VAA14730; Mon, 18 Jun 2001 21:11:02 -0700 (PDT) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA14717 for ; Mon, 18 Jun 2001 21:11:01 -0700 (PDT) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 15CCqz-0007Ev-00; Tue, 19 Jun 2001 04:11:01 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp1.email.verio.net with asmtp (110190536) id 15CCqu-0005oU-00; Tue, 19 Jun 2001 04:10:57 +0000 From: "Dan Kohn" To: Cc: "Roy Fielding" Date: Mon, 18 Jun 2001 21:10:39 -0700 Message-ID: <001701c0f875$d04ea150$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal Subject: [BXXPwg] Updated strawman for BEEP protocol URIs 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 The counterexample for Gabe is a beep listener that, for whatever reason, supports profiles for two or more services on the same port. Which is why I'd like to suggest the following (updated) proposal: Any protocol built over beep is welcome to define it's own URL scheme. This registration must include what profile is supported and the default port number and transport layer. Since URL schemes will map one-to-one to BEEP profiles, the profile should not be separately specified in the URL. Thus, for a "web over beep" service, the following scheme would be registered using RFC 2396 notation: web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [ "?" query ]] transport = "tcp" / "sctp" / "udp" / "tls" And where lack of specified transport defaults to TCP (for this scheme name, although not necessarily for others). The listener and/or initiator can still cause the transport to be negotiated (e.g., from tcp to tls), but the transport in the URI specifies what to start with. web is used instead of web.beep because web is not previously defined over other session layers. Similarly, imxp, syslog.raw, and syslog.cooked are all good URL scheme names, where if soap is registered as a scheme name using HTTP transport semantics, then SOAP over BEEP should use "soap.beep". A default beep URL scheme should not be registered, since invocation of a beep URL would have no default semantics and no default application to call. - dan -- Dan Kohn -----Original Message----- From: bxxpwg-admin@lists.invisibleworlds.com [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Gabe Wachob Sent: Monday, June 18, 2001 17:07 To: Marshall T. Rose Cc: bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] SOAP over BEEP In the example I give, I am giving the endpoint to an application, or another person to stick in their application. I presume the application will know what to do... e.g. the profile to start. Are there going to be applications which can run arbitrary BEEP profiles? In which case, yes, you'd have to include the profile with the endpoint... I'm trying to figure out a real example of such... I guess maybe there is increasingly a new class of applications where the "physical transport" is not specified and that somehow that physical transport (or something even above it like BEEP) must be specified along with the protocol's logical endpoint naming scheme (a la soap.beep naming below). I just don't have a feel for how that will actually play out - will SOAP clients be frequently using HTTP transport along side BEEP transport, or will this be a toggle/preference/configuration issue that is not done on a per-interaction basis? -Gabe On Mon, 18 Jun 2001, Marshall T. Rose wrote: > > Thus, no real need for URLs except something very basic like > > beep:: > > > > Counterexamples? > > i think that it makes sense to define a URL scheme for a protocol that is > based on beep, e.g., > > soap.beep://example.com?resource=stockTicker > > what makes no sense to me is defining a URL scheme for beep, per se. > > in the example that you give, how is one to know what profile to start? > > /mtr > > _______________________________________________ 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 Jun 19 00:49:18 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 ESMTP id AAA00284 for ; Tue, 19 Jun 2001 00:49:18 -0400 (EDT) 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 VAA14862; Mon, 18 Jun 2001 21:48:29 -0700 (PDT) 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 VAA14843 for ; Mon, 18 Jun 2001 21:48:28 -0700 (PDT) Received: (qmail 26987 invoked by uid 3039); 19 Jun 2001 04:48:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2001 04:48:26 -0000 Date: Mon, 18 Jun 2001 21:48:26 -0700 (PDT) From: Gabe Wachob X-Sender: To: Dan Kohn cc: , Roy Fielding Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs In-Reply-To: <001701c0f875$d04ea150$6a01a8c0@skymoonventures.com> Message-ID: 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 On Mon, 18 Jun 2001, Dan Kohn wrote: > The counterexample for Gabe is a beep listener that, for whatever > reason, supports profiles for two or more services on the same port. > Which is why I'd like to suggest the following (updated) proposal: Wait, why would a listener need a URL format? Only initiators are going to need this URL containing a profile.. Only an initiator is going to have to make a decision about *why* they are entering into a BEEP connection .. In other words, in BEEP, a "location" is not visible within the protocol - if you talk to a BEEP endpoint (listener), that listener basically only cares really that you connected, and the negotiation for what profile to "execute" is part of the greeting and channel creation - no URL neccesary. -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 00:54:45 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 ESMTP id AAA00336 for ; Tue, 19 Jun 2001 00:54:44 -0400 (EDT) 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 VAA14917; Mon, 18 Jun 2001 21:54:16 -0700 (PDT) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id VAA14901 for ; Mon, 18 Jun 2001 21:54:15 -0700 (PDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15CDWp-0002E5-00; Tue, 19 Jun 2001 04:54:15 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp3.email.verio.net with asmtp (110190536) id 15CDWo-00055J-00; Tue, 19 Jun 2001 04:54:14 +0000 From: "Dan Kohn" To: "'Gabe Wachob'" Cc: , "'Roy Fielding'" Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs Date: Mon, 18 Jun 2001 21:54:02 -0700 Message-ID: <002001c0f87b$dcac0220$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal 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 The initiator needs the URL, but the unique scheme names per profile are required if the listener is offering multiple profiles on the same port. A BEEP initiator is told by a URL to begin a session. The listener supports two profiles on the same port, IMXP and raw syslog. A hypothetical "beep" URL would not be able to specify which profile should be selected. But, an imxp or syslog.raw URL scheme name is by definition bound to a single BEEP profile, so there is no confusion over which profile to select. - dan -- Dan Kohn -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Monday, June 18, 2001 21:48 To: Dan Kohn Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs On Mon, 18 Jun 2001, Dan Kohn wrote: > The counterexample for Gabe is a beep listener that, for whatever > reason, supports profiles for two or more services on the same port. > Which is why I'd like to suggest the following (updated) proposal: Wait, why would a listener need a URL format? Only initiators are going to need this URL containing a profile.. Only an initiator is going to have to make a decision about *why* they are entering into a BEEP connection .. In other words, in BEEP, a "location" is not visible within the protocol - if you talk to a BEEP endpoint (listener), that listener basically only cares really that you connected, and the negotiation for what profile to "execute" is part of the greeting and channel creation - no URL neccesary. -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 01:00:06 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 ESMTP id BAA00394 for ; Tue, 19 Jun 2001 01:00:05 -0400 (EDT) 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 VAA14979; Mon, 18 Jun 2001 21:59:36 -0700 (PDT) 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 VAA14966 for ; Mon, 18 Jun 2001 21:59:35 -0700 (PDT) Received: (qmail 28236 invoked by uid 3039); 19 Jun 2001 04:59:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2001 04:59:34 -0000 Date: Mon, 18 Jun 2001 21:59:34 -0700 (PDT) From: Gabe Wachob X-Sender: To: Dan Kohn cc: , "'Roy Fielding'" Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs In-Reply-To: <002001c0f87b$dcac0220$6a01a8c0@skymoonventures.com> Message-ID: 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 I'm having a hard time understaning in what situation an application would think "hmm, I have this endpoint, should I do IMXP or syslog-raw?" I mean, even if it did both of those functions, wouldn't it know by context (eg different fill-in fields in some config screen) that the particular endpoint can be used for either profile? The application is not making the decision - "here's an endpoint, whats something interesting I can do with it". Rather, the logic is "I want to do profile X, do I have an endpoint with which to do profile X"... -Gabe On Mon, 18 Jun 2001, Dan Kohn wrote: > The initiator needs the URL, but the unique scheme names per profile are > required if the listener is offering multiple profiles on the same port. > > A BEEP initiator is told by a URL to begin a session. The listener > supports two profiles on the same port, IMXP and raw syslog. A > hypothetical "beep" URL would not be able to specify which profile > should be selected. But, an imxp or syslog.raw URL scheme name is by > definition bound to a single BEEP profile, so there is no confusion over > which profile to select. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: Gabe Wachob [mailto:gwachob@wachob.com] > Sent: Monday, June 18, 2001 21:48 > To: Dan Kohn > Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding > Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs > > > > On Mon, 18 Jun 2001, Dan Kohn wrote: > > > The counterexample for Gabe is a beep listener that, for whatever > > reason, supports profiles for two or more services on the same port. > > Which is why I'd like to suggest the following (updated) proposal: > > Wait, why would a listener need a URL format? Only initiators are going > to > need this URL containing a profile.. Only an initiator is going to have > to > make a decision about *why* they are entering into a BEEP connection .. > > In other words, in BEEP, a "location" is not visible within the protocol > - > if you talk to a BEEP endpoint (listener), that listener basically only > cares really that you connected, and the negotiation for what profile to > "execute" is part of the greeting and channel creation - no URL > neccesary. > > -Gabe > > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 01:10:19 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 ESMTP id BAA00739 for ; Tue, 19 Jun 2001 01:10:18 -0400 (EDT) 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 WAA15103; Mon, 18 Jun 2001 22:09:49 -0700 (PDT) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id WAA15081 for ; Mon, 18 Jun 2001 22:09:48 -0700 (PDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 15CDlr-0000Pr-00; Tue, 19 Jun 2001 05:09:47 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp3.email.verio.net with asmtp (110190536) id 15CDlr-0005Lz-00; Tue, 19 Jun 2001 05:09:47 +0000 From: "Dan Kohn" To: "'Gabe Wachob'" Cc: , "'Roy Fielding'" Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs Date: Mon, 18 Jun 2001 22:09:34 -0700 Message-ID: <002101c0f87e$087643f0$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal 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 the URL scheme were just "beep", the application would connect and see, I can do IMXP or syslog-raw. This would be fixed if there were a profile field in the beep URL scheme name, but that's very ugly because: A) who wants a URL in a URL, and B) it incorrectly assumes that there is a single BEEP client to be invoked, when in fact that are probably multiple applications, each of which speaks a certain BEEP profile. My proposal addresses this by mapping one-to-one between BEEP profiles and URL scheme names so that the right application is launched for any given profile. This additionally enables a listener to support multiple profiles on the same port without confusion, since the initiator knows which profile it should use from the scheme name. I don't know how to more clearly answer your question. Could I suggest you go back to my proposal from a few messages ago and, if you have an issue with it, suggest an alternative? - dan -- Dan Kohn -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Monday, June 18, 2001 22:00 To: Dan Kohn Cc: bxxpwg@lists.invisibleworlds.com; 'Roy Fielding' Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs I'm having a hard time understaning in what situation an application would think "hmm, I have this endpoint, should I do IMXP or syslog-raw?" I mean, even if it did both of those functions, wouldn't it know by context (eg different fill-in fields in some config screen) that the particular endpoint can be used for either profile? The application is not making the decision - "here's an endpoint, whats something interesting I can do with it". Rather, the logic is "I want to do profile X, do I have an endpoint with which to do profile X"... -Gabe On Mon, 18 Jun 2001, Dan Kohn wrote: > The initiator needs the URL, but the unique scheme names per profile are > required if the listener is offering multiple profiles on the same port. > > A BEEP initiator is told by a URL to begin a session. The listener > supports two profiles on the same port, IMXP and raw syslog. A > hypothetical "beep" URL would not be able to specify which profile > should be selected. But, an imxp or syslog.raw URL scheme name is by > definition bound to a single BEEP profile, so there is no confusion over > which profile to select. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: Gabe Wachob [mailto:gwachob@wachob.com] > Sent: Monday, June 18, 2001 21:48 > To: Dan Kohn > Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding > Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs > > > > On Mon, 18 Jun 2001, Dan Kohn wrote: > > > The counterexample for Gabe is a beep listener that, for whatever > > reason, supports profiles for two or more services on the same port. > > Which is why I'd like to suggest the following (updated) proposal: > > Wait, why would a listener need a URL format? Only initiators are going > to > need this URL containing a profile.. Only an initiator is going to have > to > make a decision about *why* they are entering into a BEEP connection .. > > In other words, in BEEP, a "location" is not visible within the protocol > - > if you talk to a BEEP endpoint (listener), that listener basically only > cares really that you connected, and the negotiation for what profile to > "execute" is part of the greeting and channel creation - no URL > neccesary. > > -Gabe > > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 01:18: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 ESMTP id BAA01205 for ; Tue, 19 Jun 2001 01:18:09 -0400 (EDT) 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 WAA15213; Mon, 18 Jun 2001 22:17:39 -0700 (PDT) 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 WAA15156 for ; Mon, 18 Jun 2001 22:17:37 -0700 (PDT) Received: (qmail 31222 invoked by uid 3039); 19 Jun 2001 05:17:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2001 05:17:36 -0000 Date: Mon, 18 Jun 2001 22:17:36 -0700 (PDT) From: Gabe Wachob X-Sender: To: Dan Kohn cc: , "'Roy Fielding'" Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs In-Reply-To: <002101c0f87e$087643f0$6a01a8c0@skymoonventures.com> Message-ID: 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 Ah, ok, I get it now - you are talking about the "click on this URL" mode of application. I had not considered that - I had not considered that there would be some way to launch an beep application from within (say) an HTML page. (I could embed a IMXP URL for example). Fair enough. Good counterexample. The initiator is still going to drive the decision of which profile to use (I was confused when you talked about the *listener* making a decision - that threw me off). -Gabe On Mon, 18 Jun 2001, Dan Kohn wrote: > If the URL scheme were just "beep", the application would connect and > see, I can do IMXP or syslog-raw. This would be fixed if there were a > profile field in the beep URL scheme name, but that's very ugly because: > > A) who wants a URL in a URL, and > B) it incorrectly assumes that there is a single BEEP client to be > invoked, when in fact that are probably multiple applications, each of > which speaks a certain BEEP profile. > > My proposal addresses this by mapping one-to-one between BEEP profiles > and URL scheme names so that the right application is launched for any > given profile. This additionally enables a listener to support multiple > profiles on the same port without confusion, since the initiator knows > which profile it should use from the scheme name. > > I don't know how to more clearly answer your question. Could I suggest > you go back to my proposal from a few messages ago and, if you have an > issue with it, suggest an alternative? > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: Gabe Wachob [mailto:gwachob@wachob.com] > Sent: Monday, June 18, 2001 22:00 > To: Dan Kohn > Cc: bxxpwg@lists.invisibleworlds.com; 'Roy Fielding' > Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs > > > I'm having a hard time understaning in what situation an application > would > think "hmm, I have this endpoint, should I do IMXP or syslog-raw?" I > mean, > even if it did both of those functions, wouldn't it know by context (eg > different fill-in fields in some config screen) that the particular > endpoint can be used for either profile? > > The application is not making the decision - "here's an endpoint, whats > something interesting I can do with it". Rather, the logic is "I want to > do profile X, do I have an endpoint with which to do profile X"... > > -Gabe > > > On Mon, 18 Jun 2001, Dan Kohn wrote: > > > The initiator needs the URL, but the unique scheme names per profile > are > > required if the listener is offering multiple profiles on the same > port. > > > > A BEEP initiator is told by a URL to begin a session. The listener > > supports two profiles on the same port, IMXP and raw syslog. A > > hypothetical "beep" URL would not be able to specify which profile > > should be selected. But, an imxp or syslog.raw URL scheme name is by > > definition bound to a single BEEP profile, so there is no confusion > over > > which profile to select. > > > > - dan > > -- > > Dan Kohn > > > > > > -----Original Message----- > > From: Gabe Wachob [mailto:gwachob@wachob.com] > > Sent: Monday, June 18, 2001 21:48 > > To: Dan Kohn > > Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding > > Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs > > > > > > > > On Mon, 18 Jun 2001, Dan Kohn wrote: > > > > > The counterexample for Gabe is a beep listener that, for whatever > > > reason, supports profiles for two or more services on the same port. > > > Which is why I'd like to suggest the following (updated) proposal: > > > > Wait, why would a listener need a URL format? Only initiators are > going > > to > > need this URL containing a profile.. Only an initiator is going to > have > > to > > make a decision about *why* they are entering into a BEEP connection > .. > > > > In other words, in BEEP, a "location" is not visible within the > protocol > > - > > if you talk to a BEEP endpoint (listener), that listener basically > only > > cares really that you connected, and the negotiation for what profile > to > > "execute" is part of the greeting and channel creation - no URL > > neccesary. > > > > -Gabe > > > > > > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 01:25: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 ESMTP id BAA01806 for ; Tue, 19 Jun 2001 01:25:42 -0400 (EDT) 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 WAA15299; Mon, 18 Jun 2001 22:25:14 -0700 (PDT) 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 WAA15278 for ; Mon, 18 Jun 2001 22:25:13 -0700 (PDT) Received: (qmail 32061 invoked by uid 3039); 19 Jun 2001 05:25:12 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2001 05:25:12 -0000 Date: Mon, 18 Jun 2001 22:25:12 -0700 (PDT) From: Gabe Wachob X-Sender: To: Dan Kohn cc: , Roy Fielding Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs In-Reply-To: <001701c0f875$d04ea150$6a01a8c0@skymoonventures.com> Message-ID: 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 OK, now that I buy your counterexample (a useful excercise IMHO).. I guess my only concern is the negotiation of transport - see my note below. On Mon, 18 Jun 2001, Dan Kohn wrote: > Any protocol built over beep is welcome to define it's own URL scheme. > This registration must include what profile is supported and the default > port number and transport layer. Since URL schemes will map one-to-one > to BEEP profiles, the profile should not be separately specified in the > URL. Thus, for a "web over beep" service, the following scheme would be > registered using RFC 2396 notation: > > web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [ > "?" query ]] > > transport = "tcp" / "sctp" / "udp" / "tls" Little nit - "port" may not have meaning in some transports.. i.e. a serial connection or bluetooth serial profile (if one were to go there, its been suggested not to). > And where lack of specified transport defaults to TCP (for this scheme > name, although not necessarily for others). The listener and/or > initiator can still cause the transport to be negotiated (e.g., from tcp > to tls), but the transport in the URI specifies what to start with. Outside of TCP->TLS, this negotiation isn't part of BEEP, is it? If I understand this proposal (you are not the first to make it), a listener can make an initial TCP connection, and then somehow negotiate that it wants to use a different transport (say sctp) and so the two magically make this new connection. OK, its not magic - probably a relatively simple profile for transport negotiatoin. Is that what you are suggesting? > A default beep URL scheme should not be registered, since invocation of > a beep URL would have no default semantics and no default application to > call. Right, we all agree thats clear now. BEEP endpoints don't need URLs, application endpoints do. -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 01:41:35 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 ESMTP id BAA02782 for ; Tue, 19 Jun 2001 01:41:34 -0400 (EDT) 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 WAA15380; Mon, 18 Jun 2001 22:41:05 -0700 (PDT) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id WAA15367 for ; Mon, 18 Jun 2001 22:41:04 -0700 (PDT) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15CEG8-0004S2-00; Tue, 19 Jun 2001 05:41:04 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp2.email.verio.net with asmtp (110190536) id 15CEG7-0004WJ-00; Tue, 19 Jun 2001 05:41:03 +0000 From: "Dan Kohn" To: "'Gabe Wachob'" Cc: , "Roy Fielding" Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs Date: Mon, 18 Jun 2001 22:40:50 -0700 Message-ID: <002601c0f882$66ba3490$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal 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 Yep, that's what I'm suggesting. TCP to SCTP seems like it could become common in addition to TCP to TLS. My original strawman suggested not to bother with a transport token in the URL, since you can always negotiate it later. But, one can imagine circumstances (say IMXP) where the listener supports both secure and insecure modes, but the webpage embedding the IMXP URL wants the initiator to start off secure. Without the tls token in the URL, there's no way to be sure that the initiator will bother to upgrade. This is analogous to the situation with http vs. https today. Although one could do different URL schemes for each transport, there's no obvious benefit to doing so, and it's a pain in terms of requiring multiple registrations. Also, URL schemes for all BEEP profiles are upward compatible with new transport mappings (e.g., BEEP over DNS) simply by having the transport mapping RFC specify an additional transport token. Finally, the fact that port may not be meaningful in certain transports is already handled by the fact that it's optional. - dan -- Dan Kohn -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Monday, June 18, 2001 22:25 To: Dan Kohn Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs OK, now that I buy your counterexample (a useful excercise IMHO).. I guess my only concern is the negotiation of transport - see my note below. On Mon, 18 Jun 2001, Dan Kohn wrote: > Any protocol built over beep is welcome to define it's own URL scheme. > This registration must include what profile is supported and the default > port number and transport layer. Since URL schemes will map one-to-one > to BEEP profiles, the profile should not be separately specified in the > URL. Thus, for a "web over beep" service, the following scheme would be > registered using RFC 2396 notation: > > web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [ > "?" query ]] > > transport = "tcp" / "sctp" / "udp" / "tls" Little nit - "port" may not have meaning in some transports.. i.e. a serial connection or bluetooth serial profile (if one were to go there, its been suggested not to). > And where lack of specified transport defaults to TCP (for this scheme > name, although not necessarily for others). The listener and/or > initiator can still cause the transport to be negotiated (e.g., from tcp > to tls), but the transport in the URI specifies what to start with. Outside of TCP->TLS, this negotiation isn't part of BEEP, is it? If I understand this proposal (you are not the first to make it), a listener can make an initial TCP connection, and then somehow negotiate that it wants to use a different transport (say sctp) and so the two magically make this new connection. OK, its not magic - probably a relatively simple profile for transport negotiatoin. Is that what you are suggesting? > A default beep URL scheme should not be registered, since invocation of > a beep URL would have no default semantics and no default application to > call. Right, we all agree thats clear now. BEEP endpoints don't need URLs, application endpoints do. -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 11:19: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 LAA23893 for ; Tue, 19 Jun 2001 11:18:59 -0400 (EDT) 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 IAA17500; Tue, 19 Jun 2001 08:16:16 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA17481 for ; Tue, 19 Jun 2001 08:16:14 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 19 Jun 2001 11:17:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: Thread-Topic: [BXXPwg] Updated strawman for BEEP protocol URIs Thread-Index: AcD4djHMj8bV94L+SCKHWFLfWVeIHQAW1kzA From: "Bob Wyman" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id IAA17482 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: 8bit I thought it might be useful to provide an example of how another system (Elvin) has addressed the issues being discussed here. Elvin produces URL's that follow the pattern: elvin:/protocol/endpoint-specification An example Elvin URL might look like: elvin:/tcp,ssl,xdr/machine.domain.com:1234;property=value The "protocol" element distinguishs between transport, security and marshalling bindings. Note: I'm providing this for information. I don't explicitly endorse what they are doing... The following more detailed discussion of the Elvin URL scheme is taken from: http://elvin.dstc.edu.au/doc/guides/elvin-admin.html#SEC8 ============= The Elvin router (@command{elvind}) accepts connections from client programs using one or more offered protocol stacks. A protocol stack is constructed from the available network transport, security and data marshalling modules, and exported by the @command{elvind} process. Elvin clients identify the server and protocol with which they connect using a uniform resource locator (URL). The URLs contain the information needs by the client libraries to contact the @command{elvind} process. An example of such an URL follows: elvin:/tcp,none,xdr/server.example.com:2917 Breaking that example URL into its components, we have elvin:/protocol/endpoint-specification The elvin is the scheme name, which distinguishes Elvin URLs from those of other schemes, like http, for example. Next is the protocol, which describes the protocol stack to be used. In the example, we are using a TCP transport, no security, and an XDR (External Data Representation) marshalling layer. The protocol field may be empty which implies the default elvin protocol of tcp,none,xdr. Next is the endpoint specification, which provides protocol-level connection information. This field is specific to the protocol stack. In this example, the server.example.com identifies a particular host machine, and the 2917 specifies a TCP port number. When used in the server configuration file, the special host field 0.0.0.0 can be used in an endpoint specification to mean all interfaces on the machine. Note that this is the standard Elvin protocol and uses Elvin's IANA allocated port for Elvin client to server communication. An example using a different protocol is: elvin:/unix,none,xdr/server.example.com/tmp/elvin Here the protocol used is unix, for Unix domain sockets which are useful for clients connected on the same machine. The endpoint specification specifies the machine and the path of the Unix domain socket, /tmp/elvin. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jun 19 11:44: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 LAA24571 for ; Tue, 19 Jun 2001 11:44:04 -0400 (EDT) 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 IAA17648; Tue, 19 Jun 2001 08:41:35 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA17630; Tue, 19 Jun 2001 08:40:57 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 08:53:46 -0700 Message-ID: From: Bill Mills To: "'Dan Kohn'" , "'Gabe Wachob'" Cc: bxxpwg@lists.invisibleworlds.com, Roy Fielding Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs Date: Tue, 19 Jun 2001 08:53:43 -0700 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 Actually I think TCP to SCTP might be an extremely bad example. Are not both of these connection oriented guaranteed delivery protocols on top of IP? -bill -----Original Message----- From: Dan Kohn [mailto:dan@dankohn.com] Sent: Monday, June 18, 2001 10:41 PM To: 'Gabe Wachob' Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs Yep, that's what I'm suggesting. TCP to SCTP seems like it could become common in addition to TCP to TLS. My original strawman suggested not to bother with a transport token in the URL, since you can always negotiate it later. But, one can imagine circumstances (say IMXP) where the listener supports both secure and insecure modes, but the webpage embedding the IMXP URL wants the initiator to start off secure. Without the tls token in the URL, there's no way to be sure that the initiator will bother to upgrade. This is analogous to the situation with http vs. https today. Although one could do different URL schemes for each transport, there's no obvious benefit to doing so, and it's a pain in terms of requiring multiple registrations. Also, URL schemes for all BEEP profiles are upward compatible with new transport mappings (e.g., BEEP over DNS) simply by having the transport mapping RFC specify an additional transport token. Finally, the fact that port may not be meaningful in certain transports is already handled by the fact that it's optional. - dan -- Dan Kohn -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Monday, June 18, 2001 22:25 To: Dan Kohn Cc: bxxpwg@lists.invisibleworlds.com; Roy Fielding Subject: Re: [BXXPwg] Updated strawman for BEEP protocol URIs OK, now that I buy your counterexample (a useful excercise IMHO).. I guess my only concern is the negotiation of transport - see my note below. On Mon, 18 Jun 2001, Dan Kohn wrote: > Any protocol built over beep is welcome to define it's own URL scheme. > This registration must include what profile is supported and the default > port number and transport layer. Since URL schemes will map one-to-one > to BEEP profiles, the profile should not be separately specified in the > URL. Thus, for a "web over beep" service, the following scheme would be > registered using RFC 2396 notation: > > web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [ > "?" query ]] > > transport = "tcp" / "sctp" / "udp" / "tls" Little nit - "port" may not have meaning in some transports.. i.e. a serial connection or bluetooth serial profile (if one were to go there, its been suggested not to). > And where lack of specified transport defaults to TCP (for this scheme > name, although not necessarily for others). The listener and/or > initiator can still cause the transport to be negotiated (e.g., from tcp > to tls), but the transport in the URI specifies what to start with. Outside of TCP->TLS, this negotiation isn't part of BEEP, is it? If I understand this proposal (you are not the first to make it), a listener can make an initial TCP connection, and then somehow negotiate that it wants to use a different transport (say sctp) and so the two magically make this new connection. OK, its not magic - probably a relatively simple profile for transport negotiatoin. Is that what you are suggesting? > A default beep URL scheme should not be registered, since invocation of > a beep URL would have no default semantics and no default application to > call. Right, we all agree thats clear now. BEEP endpoints don't need URLs, application endpoints do. -Gabe _______________________________________________ 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 Jun 19 12:31:30 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 MAA26180 for ; Tue, 19 Jun 2001 12:31:29 -0400 (EDT) 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 JAA17898; Tue, 19 Jun 2001 09:28:20 -0700 (PDT) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA17883 for ; Tue, 19 Jun 2001 09:28:19 -0700 (PDT) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 15COMU-000564-00 for bxxpwg@lists.invisibleworlds.com; Tue, 19 Jun 2001 16:28:18 +0000 Received: from [64.163.215.88] (helo=dan3480) by dfw-mmp1.email.verio.net with asmtp (110190536) id 15COMU-0003Fk-00 for bxxpwg@lists.invisibleworlds.com; Tue, 19 Jun 2001 16:28:18 +0000 From: "Dan Kohn" To: Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs Date: Tue, 19 Jun 2001 09:28:03 -0700 Message-ID: <007c01c0f8dc$d294baf0$6a01a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: Importance: Normal 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 The Elvin scheme breaks all of the relative URL parsing code that is in wide use today (see RFC 2396 sections 5.2 & Appendices B & C) but gives no advantages. It does not seem like a model. - dan -- Dan Kohn -----Original Message----- From: bxxpwg-admin@lists.invisibleworlds.com [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Bob Wyman Sent: Tuesday, June 19, 2001 08:18 To: bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs I thought it might be useful to provide an example of how another system (Elvin) has addressed the issues being discussed here. Elvin produces URL's that follow the pattern: elvin:/protocol/endpoint-specification An example Elvin URL might look like: elvin:/tcp,ssl,xdr/machine.domain.com:1234;property=value The "protocol" element distinguishs between transport, security and marshalling bindings. Note: I'm providing this for information. I don't explicitly endorse what they are doing... The following more detailed discussion of the Elvin URL scheme is taken from: http://elvin.dstc.edu.au/doc/guides/elvin-admin.html#SEC8 ============= The Elvin router (@command{elvind}) accepts connections from client programs using one or more offered protocol stacks. A protocol stack is constructed from the available network transport, security and data marshalling modules, and exported by the @command{elvind} process. Elvin clients identify the server and protocol with which they connect using a uniform resource locator (URL). The URLs contain the information needs by the client libraries to contact the @command{elvind} process. An example of such an URL follows: elvin:/tcp,none,xdr/server.example.com:2917 Breaking that example URL into its components, we have elvin:/protocol/endpoint-specification The elvin is the scheme name, which distinguishes Elvin URLs from those of other schemes, like http, for example. Next is the protocol, which describes the protocol stack to be used. In the example, we are using a TCP transport, no security, and an XDR (External Data Representation) marshalling layer. The protocol field may be empty which implies the default elvin protocol of tcp,none,xdr. Next is the endpoint specification, which provides protocol-level connection information. This field is specific to the protocol stack. In this example, the server.example.com identifies a particular host machine, and the 2917 specifies a TCP port number. When used in the server configuration file, the special host field 0.0.0.0 can be used in an endpoint specification to mean all interfaces on the machine. Note that this is the standard Elvin protocol and uses Elvin's IANA allocated port for Elvin client to server communication. An example using a different protocol is: elvin:/unix,none,xdr/server.example.com/tmp/elvin Here the protocol used is unix, for Unix domain sockets which are useful for clients connected on the same machine. The endpoint specification specifies the machine and the path of the Unix domain socket, /tmp/elvin. _______________________________________________ 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 Jun 19 12:42: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 MAA26453 for ; Tue, 19 Jun 2001 12:42:47 -0400 (EDT) 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 JAA18012; Tue, 19 Jun 2001 09:39:37 -0700 (PDT) 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 JAA17998 for ; Tue, 19 Jun 2001 09:39:35 -0700 (PDT) Received: (qmail 13938 invoked by uid 3039); 19 Jun 2001 16:39:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Jun 2001 16:39:27 -0000 Date: Tue, 19 Jun 2001 09:39:27 -0700 (PDT) From: Gabe Wachob X-Sender: To: Dan Kohn cc: Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs In-Reply-To: <007c01c0f8dc$d294baf0$6a01a8c0@skymoonventures.com> Message-ID: 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 Specifically, here's the most pertinent snippet: (a Perlish regular expression for parsing URI's): ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 12 3 4 5 6 7 8 9 The numbers in the second line above are only to assist readability; they indicate the reference points for each subexpression (i.e., each paired parenthesis). We refer to the value matched for subexpression as $. For example, matching the above expression to http://www.ics.uci.edu/pub/ietf/uri/#Related results in the following subexpression matches: $1 = http: $2 = http $3 = //www.ics.uci.edu $4 = www.ics.uci.edu $5 = /pub/ietf/uri/ $6 = $7 = $8 = #Related $9 = Related where indicates that the component is not present, as is the case for the query component in the above example. Therefore, we can determine the value of the four components and fragment as scheme = $2 authority = $4 path = $5 query = $7 fragment = $9 -Gabe On Tue, 19 Jun 2001, Dan Kohn wrote: > The Elvin scheme breaks all of the relative URL parsing code that is in > wide use today (see RFC 2396 sections 5.2 & Appendices B & C) but gives > no advantages. It does not seem like a model. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: bxxpwg-admin@lists.invisibleworlds.com > [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Bob Wyman > Sent: Tuesday, June 19, 2001 08:18 > To: bxxpwg@lists.invisibleworlds.com > Subject: RE: [BXXPwg] Updated strawman for BEEP protocol URIs > > > I thought it might be useful to provide an example of how another system > (Elvin) has addressed the issues being discussed here. Elvin produces > URL's that follow the pattern: > elvin:/protocol/endpoint-specification > An example Elvin URL might look like: > elvin:/tcp,ssl,xdr/machine.domain.com:1234;property=value > The "protocol" element distinguishs between transport, security and > marshalling bindings. > > Note: I'm providing this for information. I don't explicitly endorse > what they are doing... > > The following more detailed discussion of the Elvin URL scheme is taken > from: > http://elvin.dstc.edu.au/doc/guides/elvin-admin.html#SEC8 > > ============= > The Elvin router (@command{elvind}) accepts connections from client > programs using one or more offered protocol stacks. A protocol stack is > constructed from the available network transport, security and data > marshalling modules, and exported by the @command{elvind} process. > > Elvin clients identify the server and protocol with which they connect > using a uniform resource locator (URL). The URLs contain the information > needs by the client libraries to contact the @command{elvind} process. > > An example of such an URL follows: > > elvin:/tcp,none,xdr/server.example.com:2917 > > Breaking that example URL into its components, we have > > elvin:/protocol/endpoint-specification > > The elvin is the scheme name, which distinguishes Elvin URLs from those > of other schemes, like http, for example. > > Next is the protocol, which describes the protocol stack to be used. In > the example, we are using a TCP transport, no security, and an XDR > (External Data Representation) marshalling layer. The protocol field may > be empty which implies the default elvin protocol of tcp,none,xdr. > > Next is the endpoint specification, which provides protocol-level > connection information. This field is specific to the protocol stack. In > this example, the server.example.com identifies a particular host > machine, and the 2917 specifies a TCP port number. > > When used in the server configuration file, the special host field > 0.0.0.0 can be used in an endpoint specification to mean all interfaces > on the machine. > > Note that this is the standard Elvin protocol and uses Elvin's IANA > allocated port for Elvin client to server communication. > > An example using a different protocol is: > > elvin:/unix,none,xdr/server.example.com/tmp/elvin > > Here the protocol used is unix, for Unix domain sockets which are useful > for clients connected on the same machine. The endpoint specification > specifies the machine and the path of the Unix domain socket, > /tmp/elvin. > > _______________________________________________ > 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 Fri Jun 22 11:53:29 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 LAA27819 for ; Fri, 22 Jun 2001 11:53:28 -0400 (EDT) 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 IAA05893; Fri, 22 Jun 2001 08:52:11 -0700 (PDT) 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 IAA05830 for ; Fri, 22 Jun 2001 08:49:34 -0700 (PDT) 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 f5MFkrU02894; Fri, 22 Jun 2001 08:46:53 -0700 (PDT) Message-ID: <014401c0fb32$ebf28510$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Fri, 22 Jun 2001 08:49:14 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_013E_01C0FAF8.36BFB260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [BXXPwg] new penultimate version available 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_013E_01C0FAF8.36BFB260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HTML version at http://beepcore.org/beepcore/beep-soap.jsp this one has a typo, which is corrected in the next release. whenever you see "?resource=stockQuote", ignore it. new in this version: - soap packages - feature extensibility - new approach to profile initialization - a URL for soap over beep /mtr ------=_NextPart_000_013E_01C0FAF8.36BFB260 Content-Type: message/rfc822; name="I-D ACTION_draft-etal-beep-soap-01.txt.eml" Content-Disposition: attachment; filename="I-D ACTION_draft-etal-beep-soap-01.txt.eml" Delivery-Date: Fri, 22 Jun 2001 07:57:16 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with ESMTP id f5MEvCU02738 for ; Fri, 22 Jun 2001 07:57:13 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA08314 for ietf-123-outbound.10@ietf.org; Fri, 22 Jun 2001 09:55:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA06705 for ; Fri, 22 Jun 2001 07:12:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16039 for ; Fri, 22 Jun 2001 07:12:54 -0400 (EDT) Message-Id: <200106221112.HAA16039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-etal-beep-soap-01.txt Date: Fri, 22 Jun 2001 07:12:54 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using SOAP in BEEP Author(s) : E. O'Tuathail, M. Rose Filename : draft-etal-beep-soap-01.txt Pages : 20 Date : 21-Jun-01 SOAP is an XML-based messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. A SOAP binding describes how SOAP messages are transmitted in the network. This memo specifies a SOAP binding to BEEP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-etal-beep-soap-01.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-etal-beep-soap-01.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-etal-beep-soap-01.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: <20010621134507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-etal-beep-soap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-etal-beep-soap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134507.I-D@ietf.org> --OtherAccess-- --NextPart-- ------=_NextPart_000_013E_01C0FAF8.36BFB260-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 12:26:40 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 MAA29298 for ; Fri, 22 Jun 2001 12:26:39 -0400 (EDT) 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 JAA06132; Fri, 22 Jun 2001 09:26:13 -0700 (PDT) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA06119 for ; Fri, 22 Jun 2001 09:26:12 -0700 (PDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 15DTl2-0004wz-00 for bxxpwg@invisible.net; Fri, 22 Jun 2001 16:26:08 +0000 Received: from [64.163.212.167] (helo=dan3480) by dfw-mmp3.email.verio.net with asmtp (110190536) id 15DTl2-0001PG-00 for bxxpwg@invisible.net; Fri, 22 Jun 2001 16:26:08 +0000 From: "Dan Kohn" To: Subject: RE: [BXXPwg] new penultimate version available Date: Fri, 22 Jun 2001 09:25:49 -0700 Message-ID: <014f01c0fb38$044bf100$6401a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal In-Reply-To: <014401c0fb32$ebf28510$8753cf3f@FATORA> 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 This looks great to me. My only concern is whether you want to support an optional transport token to support session initiation with TLS. Yes, it can always be negotiated, but there may be initiators and listeners that both support TLS but don't use it unless prompted (by the URL) to do so. This is analogous to the use of https vs. http URLs, but without needing to explode the URL space with a different scheme for every potential transport option. Note that the use of [ ":" transport ] is also upward compatible as BEEP is defined over new transport mappings. Here again, was my last proposal: Any protocol built over beep is welcome to define it's own URL scheme. This registration must include what profile is supported and the default port number and transport layer. Since URL schemes will map one-to-one to BEEP profiles, the profile should not be separately specified in the URL. Thus, for a "web over beep" service, the following scheme would be registered using RFC 2396 notation: web_URL = "web:" "//" host [ ":" transport ] [ ":" port ] [ abs_path [ "?" query ]] transport = "tcp" / "sctp" / "udp" / "tls" And where lack of specified transport defaults to TCP (for this scheme name, although not necessarily for others). The listener and/or initiator can still cause the transport to be negotiated (e.g., from tcp to tls), but the transport in the URI specifies what to start with. web is used instead of web.beep because web is not previously defined over other session layers. Similarly, imxp, syslog.raw, and syslog.cooked are all good URL scheme names, where if soap is registered as a scheme name using HTTP transport semantics, then SOAP over BEEP should use "soap.beep". A default beep URL scheme should not be registered, since invocation of a beep URL would have no default semantics and no default application to call. - dan -- Dan Kohn -----Original Message----- From: bxxpwg-admin@lists.invisibleworlds.com [mailto:bxxpwg-admin@lists.invisibleworlds.com] On Behalf Of Marshall T. Rose Sent: Friday, June 22, 2001 08:49 To: bxxpwg@invisible.net Cc: Marshall Rose Subject: [BXXPwg] new penultimate version available HTML version at http://beepcore.org/beepcore/beep-soap.jsp this one has a typo, which is corrected in the next release. whenever you see "?resource=stockQuote", ignore it. new in this version: - soap packages - feature extensibility - new approach to profile initialization - a URL for soap over beep /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 13:10:50 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 NAA00678 for ; Fri, 22 Jun 2001 13:10:49 -0400 (EDT) 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 KAA06431; Fri, 22 Jun 2001 10:09:42 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA06416 for ; Fri, 22 Jun 2001 10:09:41 -0700 (PDT) Subject: RE: [BXXPwg] new penultimate version available Date: Fri, 22 Jun 2001 13:11:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message Thread-Topic: [BXXPwg] new penultimate version available Thread-Index: AcD7OHAtmnR/i3QMRUC64PCVA4MLAAABEmkQ From: "Bob Wyman" To: "Dan Kohn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id KAA06417 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: 8bit Dan Kohn wrote: > web is used instead of web.beep because web is not > previously defined over other session layers. I would strongly suggest that if it is anticipated that "web" will one day be defined over other session layers, that we start with "web.beep" today in order to reduce the complexity for folk in the future. When writing standards, it would be good if things to appear to be as consistent as possible. If we start off with "web" today and then end up having to use historical -- not technical -- arguments to explain why "web" is different from "web.foo" and "web.bar," we 're just making life more difficult than necessary for the next few decades of implementers and users. It may be that "web" on its own could be considered to default to the semantics of "web.beep." However, if it is anticipated that "web.foo" will appear in the future, then we should define and register "web.beep" today. bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 15:49:59 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 PAA07314 for ; Fri, 22 Jun 2001 15:49:54 -0400 (EDT) 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 MAA07206; Fri, 22 Jun 2001 12:49:16 -0700 (PDT) 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 MAA07186 for ; Fri, 22 Jun 2001 12:49:15 -0700 (PDT) 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 f5MJkUU03481; Fri, 22 Jun 2001 12:46:30 -0700 (PDT) Message-ID: <02a001c0fb54$67db8c00$8753cf3f@FATORA> From: "Marshall T. Rose" To: , "Dan Kohn" Cc: "Roy T. Fielding" , "Marshall Rose" References: <014f01c0fb38$044bf100$6401a8c0@skymoonventures.com> Subject: Re: [BXXPwg] new penultimate version available Date: Fri, 22 Jun 2001 12:49:05 -0700 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 dan - thanks for the note. re: indicating tls in the "soap.beep" url scheme i guess i can go for making a change of this type, although i'm not entirely convinced. here's why: do "http:foo" and "https:foo" refer to different resources? probably not. the only difference here is an early-binding optimization saying that to get at the resource you need privacy enhancement. in the beep world, it seems to me that if the resource administrator wants that kind of policy, then when the listener sends its greeting, it identifies only the TLS profile. after you tune with that, the listener tells you what profiles it's now willing to let you use. similarly, if the initiator wants that kind of policy, the first thing you do is tune for TLS and then bind the desired profile. what i'm saying here is that the privacy thing looks more like a policy issue than a protocol issue. beep has a different way of signalling this than the http approach. so, it's not really clear to me that the "soap.beep" url scheme needs to externalize that policy. i'd be interested in hearing roy's comments. re: the proposal for a "web:" url scheme the problem i have is that i reject the notion of putting transport information on the RHS of the ":" in a URI. different transport mappings may imply different kinds of domains, addressing, etc. all of these things go in the RHS side. the LHS side tells you how to interpret the RHS side, so i think the transport mapping should go there. presumably roy has a more elegant way of stating this... /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 17:01:56 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 RAA10099 for ; Fri, 22 Jun 2001 17:01:56 -0400 (EDT) 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 OAA07680; Fri, 22 Jun 2001 14:01:09 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA07667 for ; Fri, 22 Jun 2001 14:01:09 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5ML0vF26435 for ; Fri, 22 Jun 2001 14:00:57 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5ML0pL26269; Fri, 22 Jun 2001 14:00:51 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5MKvPl01030; Fri, 22 Jun 2001 13:57:25 -0700 Date: Fri, 22 Jun 2001 13:57:25 -0700 From: "Roy T. Fielding" To: "Marshall T. Rose" Cc: bxxpwg@invisible.net, Dan Kohn Subject: Re: [BXXPwg] new penultimate version available Message-ID: <20010622135725.C901@waka.ebuilt.net> References: <014f01c0fb38$044bf100$6401a8c0@skymoonventures.com> <02a001c0fb54$67db8c00$8753cf3f@FATORA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <02a001c0fb54$67db8c00$8753cf3f@FATORA>; from mrose+mtr.netnews@dbc.mtview.ca.us on Fri, Jun 22, 2001 at 12:49:05PM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Fri, Jun 22, 2001 at 12:49:05PM -0700, Marshall T. Rose wrote: > in the beep world, it seems to me that if the resource administrator wants > that kind of policy, then when the listener sends its greeting, it > identifies only the TLS profile. after you tune with that, the listener > tells you what profiles it's now willing to let you use. Right, but it should be noted somewhere that this only applies to per-connection TLS, whereas things like https indicate the entire application route must be TLS (or equivalent) secure. The difference is encountered when you have a chain of peers acting in the same way as an HTTP proxy chain -- if the client must wait for the origin to tell it the type of profile, then how does the first peer tell the second peer to contact the third peer to get the profile and send it back to the first peer before the first peer makes a non-secure request on the second peer? I'm not saying that a separate URL scheme is the right way to handle this in BEEP (I'm not even sure if peer chains are a reasonable application of BEEP), but people who are coming from HTTP-land need to understand the difference between hop-by-hop security and tunnelled security. Something to think about, in any case, before somebody thinks that http-over-beep is a no-brainer. > similarly, if the initiator wants that kind of policy, the first thing you > do is tune for TLS and then bind the desired profile. Yes, easy to do if the initiater is always configured for TLS or if there is some other application state to tell it to do so. Traditionally, the Web has put that in the URI in order to support plain-text references. Otherwise, I think it would have been an HTML element or attribute. > re: the proposal for a "web:" url scheme > > the problem i have is that i reject the notion of putting transport > information on the RHS of the ":" in a URI. > > different transport mappings may imply different kinds of domains, > addressing, etc. all of these things go in the RHS side. > > the LHS side tells you how to interpret the RHS side, so i think the > transport mapping should go there. > > presumably roy has a more elegant way of stating this... Hmmm, elegant.... no, but a more geeky way to look at it is that the URI scheme is the key used to dynamically load all of the mechanisms needed to parse and resolve the RHS. If we place a bunch of conditional elements within the RHS, then we either have to do N dynamic loads (very expensive) or we have to load every possible option for the scheme (very expensive), and in any case makes it extremely hard for application developers to implement only those transports that they care to implement. Consider, for example, what that meant before export controls were lowered. In any case, regarding the proposal, there is no way that another ":" will be allowed within the authority component -- see the URI syntax for why that would be ambiguous. We did discuss the addition of a transport indicator to the port component (e.g., "example.com:tls.20202"), but I still prefer "s" schemes (or soap.beep.tls) over that. Or would that be soap.tls.beep? *shrug* That is, assuming peer chains are needed, since profiles are fine for neighbor exchanges. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 18:32:02 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 SAA13722 for ; Fri, 22 Jun 2001 18:32:02 -0400 (EDT) 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 PAA08080; Fri, 22 Jun 2001 15:31:28 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA08050 for ; Fri, 22 Jun 2001 15:31:27 -0700 (PDT) Received: from localhost (bfeinste@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) with ESMTP id f5MMVR828525; Fri, 22 Jun 2001 15:31:27 -0700 Date: Fri, 22 Jun 2001 15:31:26 -0700 (PDT) From: Ben Feinstein To: bxxpwg@invisible.net, "Roy T. Fielding" cc: "Marshall T. Rose" , Dan Kohn Subject: Re: [BXXPwg] new penultimate version available In-Reply-To: <20010622135725.C901@waka.ebuilt.net> Message-ID: 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 On Fri, 22 Jun 2001, Roy T. Fielding wrote: > Right, but it should be noted somewhere that this only applies to > per-connection TLS, whereas things like https indicate the entire > application route must be TLS (or equivalent) secure. The difference > is encountered when you have a chain of peers acting in the same way as > an HTTP proxy chain -- if the client must wait for the origin to tell > it the type of profile, then how does the first peer tell the second > peer to contact the third peer to get the profile and send it back to > the first peer before the first peer makes a non-secure request on the > second peer? > > I'm not saying that a separate URL scheme is the right way to handle > this in BEEP (I'm not even sure if peer chains are a reasonable application > of BEEP), but people who are coming from HTTP-land need to understand > the difference between hop-by-hop security and tunnelled security. > Something to think about, in any case, before somebody thinks that > http-over-beep is a no-brainer. For an example of BEEP peer chains and tunnelled security, see the TUNNEL profile (http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-tunnel-01.txt). In IDXP (http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-02.txt) we use the TUNNEL profile to provision a chain of peers, then tune with the desired security profile (most likely TLS) before binding the endpoints to the IDXP profile. Cheers, Ben Feinstein me@benfeinstein.net _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 18:41:05 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 SAA13908 for ; Fri, 22 Jun 2001 18:41:04 -0400 (EDT) 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 PAA08141; Fri, 22 Jun 2001 15:40:39 -0700 (PDT) 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 PAA08118 for ; Fri, 22 Jun 2001 15:40:38 -0700 (PDT) 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 f5MMbuU03820; Fri, 22 Jun 2001 15:37:56 -0700 (PDT) Message-ID: <035901c0fb6c$58ac4ae0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Roy T. Fielding" Cc: , "Dan Kohn" , "Marshall Rose" References: <014f01c0fb38$044bf100$6401a8c0@skymoonventures.com> <02a001c0fb54$67db8c00$8753cf3f@FATORA> <20010622135725.C901@waka.ebuilt.net> Subject: Re: [BXXPwg] new penultimate version available Date: Fri, 22 Jun 2001 15:40:32 -0700 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 > In any case, regarding the proposal, there is no way that another ":" will > be allowed within the authority component -- see the URI syntax for > why that would be ambiguous. We did discuss the addition of a transport > indicator to the port component (e.g., "example.com:tls.20202"), but I > still prefer "s" schemes (or soap.beep.tls) over that. Or would that > be soap.tls.beep? *shrug* That is, assuming peer chains are needed, > since profiles are fine for neighbor exchanges. hi. i guess i don't have a problem with something like soap.beeps: there are two kinds of profiles in beep: tuning and data. tuning profiles are the things you invoke serially to get the session the way you like it and data profiles are the things you use to get real work done. in terms of the semantics of https:, in beep there are two kinds of relaying strategies. first, you have the vc approach used by http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-tunnel-01.txt (which is what ben is talking about) lets the originator specify a source route and get an octet-transparent path to the ultimate destination. the second is the routing approach used by http://www.ietf.org/internet-drafts/draft-ietf-apex-core-03.txt is an generic application-layer relaying facility. i don't think that either of these map cleanly to the http intermediary model... /mtr ps: for those who thing "vc" stands for "venture capitalist" instead of "virtual circuit", you probably got subscribed to this list by mistake. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 22 19:01: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 TAA14484 for ; Fri, 22 Jun 2001 19:01:30 -0400 (EDT) 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 QAA08266; Fri, 22 Jun 2001 16:00:56 -0700 (PDT) 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 QAA08253 for ; Fri, 22 Jun 2001 16:00:55 -0700 (PDT) Received: (qmail 98453 invoked by uid 3039); 22 Jun 2001 23:00:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Jun 2001 23:00:45 -0000 Date: Fri, 22 Jun 2001 16:00:45 -0700 (PDT) From: Gabe Wachob X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [BXXPwg] BEEP for JXTA transport 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 I've been talking with JXTA devlepers on #jxta (on irc.openprojects.net) and inviting them over to #beepnik (on the same irc network) and there has recently been discussions about using BEEP as (a, the default) JXTA transport. These discussions apparently started on the jxta dev list: http://www.jxta.org/servlets/BrowseList?listName=dev&paged=false If anyone here is interested in JXTA, they might want to hop over to the JXTA list for a while and agitate if they feel so inclined... -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 23 11:50: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 LAA12479 for ; Sat, 23 Jun 2001 11:50:23 -0400 (EDT) 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 IAA10791; Sat, 23 Jun 2001 08:49:13 -0700 (PDT) Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id IAA10775 for ; Sat, 23 Jun 2001 08:49:12 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA17613; Sat, 23 Jun 2001 11:49:04 -0400 (EDT) Date: Sat, 23 Jun 2001 11:49:03 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Gabe Wachob Cc: Subject: Re: [BXXPwg] BEEP for JXTA transport In-Reply-To: Your message of Fri, 22 Jun 2001 16:00:45 -0700 (PDT) Message-ID: 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 > I've been talking with JXTA devlepers on #jxta (on irc.openprojects.net) > and inviting them over to #beepnik (on the same irc network) and there has > recently been discussions about using BEEP as (a, the default) JXTA > transport. > > These discussions apparently started on the jxta dev list: > > http://www.jxta.org/servlets/BrowseList?listName=dev&paged=false > > If anyone here is interested in JXTA, they might want to hop over to the > JXTA list for a while and agitate if they feel so inclined... > > -Gabe > There is currently active discussion on the use of BEEP as one of the core transport bindings in JXTA. "Krishna Sankar" is working on a preliminary binding. Anyone that might want to assist him is urged to contact him. The JXTA Core Specifications have been moved out of the Java Reference Implementation group into a new Specifications Project. This project http://spec.jxta.org/ will be responsible for revising the protocol and managing the standardizations effort for JXTA. This may very well include the formation of an IETF Working Group to ensure JXTA is developed in a language and corporate neutral manner. We welcome your input. - Jeffrey Altman Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 23 15:48: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 PAA16281 for ; Sat, 23 Jun 2001 15:48:00 -0400 (EDT) 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 MAA11601; Sat, 23 Jun 2001 12:46:02 -0700 (PDT) Received: from smtppop2pub.verizon.net (smtppop2pub.gte.net [206.46.170.21]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA11584 for ; Sat, 23 Jun 2001 12:46:01 -0700 (PDT) Received: from ksankarw2k (sj-dial-1-22.cisco.com [171.68.179.23]) by smtppop2pub.verizon.net with SMTP for ; id OAA169463203 Sat, 23 Jun 2001 14:45:55 -0500 (CDT) From: "Krishna Sankar" To: Date: Sat, 23 Jun 2001 12:48:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] BEEP Binding for JXTA 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 all, Jeffrey Altman from jxta referred me to this list. I would like to see if we can quickly form a virtual group to develop a JXTA BEEP binding. I am sure you all have a lot of ideas how this can be achieved and so we should be able to get to a strawperson version pretty quickly. cheers and have a nice weekend Jeffrey, would this be under the platform group's umbrella ? I am not sure where this would fit in as a few new groups are being formed. -----Original Message----- From: Jeffrey Altman [mailto:jaltman@columbia.edu] Sent: Saturday, June 23, 2001 8:43 AM To: dev@jxta.org Cc: dev@jxta.org Subject: RE: [JXTA dev] Beep Bad? XTalk good? > Hi all, > > I also support the use of a protocol above TCP and BEEP is an excellent > solution. We should be concentrating on the jxta layer providing better and > better P2P abstractions. IMHO, we leave it to others to solve the transport > problems and leverage their work. For now, BEEP looks like the best fit. > Actually I am working on a *very* preliminary prototype binding BEEP. > > my 2c > > cheers > This is great. You may very well want to communicate with the BEEP working group. There were some members who expressed interest in working on a JXTA BEEP binding. The BEEP mailing list is bxxpwg@invisible.net Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@jxta.org For additional commands, e-mail: dev-help@jxta.org _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 23 16:53:17 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 QAA17277 for ; Sat, 23 Jun 2001 16:53:17 -0400 (EDT) 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 NAA11833; Sat, 23 Jun 2001 13:52:17 -0700 (PDT) Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA11373 for ; Sat, 23 Jun 2001 11:55:16 -0700 (PDT) Received: from ksankarw2k (sj-dial-1-22.cisco.com [171.68.179.23]) by smtppop3pub.verizon.net with SMTP ; id NAA28131350 Sat, 23 Jun 2001 13:55:03 -0500 (CDT) From: "Krishna Sankar" To: , Cc: Date: Sat, 23 Jun 2001 11:57:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] FW: [JXTA dev] Beep Bad? XTalk good? 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 all, Jeffrey Altman from jxta referred me to this list. I would like to see if we can quickly form a virtual group to develop a JXTA BEEP binding. I am sure you all have a lot of ideas how this can be achieved and so we should be able to get to a strawperson version pretty quickly. cheers and have a nice weekend Jeffrey, would this be under the platform group's umbrella ? I am not sure where this would fit in as a few new groups are being formed. -----Original Message----- From: Jeffrey Altman [mailto:jaltman@columbia.edu] Sent: Saturday, June 23, 2001 8:43 AM To: dev@jxta.org Cc: dev@jxta.org Subject: RE: [JXTA dev] Beep Bad? XTalk good? > Hi all, > > I also support the use of a protocol above TCP and BEEP is an excellent > solution. We should be concentrating on the jxta layer providing better and > better P2P abstractions. IMHO, we leave it to others to solve the transport > problems and leverage their work. For now, BEEP looks like the best fit. > Actually I am working on a *very* preliminary prototype binding BEEP. > > my 2c > > cheers > This is great. You may very well want to communicate with the BEEP working group. There were some members who expressed interest in working on a JXTA BEEP binding. The BEEP mailing list is bxxpwg@invisible.net Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@jxta.org For additional commands, e-mail: dev-help@jxta.org _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sun Jun 24 18:03:30 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 SAA16367 for ; Sun, 24 Jun 2001 18:03:29 -0400 (EDT) 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 PAA16062; Sun, 24 Jun 2001 15:02:02 -0700 (PDT) Received: from mail1.registeredsite.com (mail1.registeredsite.com [64.224.9.10]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA16047 for ; Sun, 24 Jun 2001 15:02:01 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail1.registeredsite.com (8.11.1/8.11.1) with ESMTP id f5OM1fi26433; Sun, 24 Jun 2001 18:01:41 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id A50FC600034; Sun, 24 Jun 2001 18:09:19 -0400 Reply-To: From: "Eamon O'Tuathail" To: Cc: Subject: [BXXPwg] BEEP Binding for JXTA Date: Sun, 24 Jun 2001 23:04:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 see if we can quickly form a virtual >> group to develop a JXTA BEEP binding. Is there any reason why you would not consider using IETF APEX (which is based on BEEP) as the basis for peer-to-peer services, such as JXTA? http://www.ietf.org/html.charters/apex-charter.html Eamon _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sun Jun 24 19:59: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 TAA17021 for ; Sun, 24 Jun 2001 19:59:48 -0400 (EDT) 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 QAA16421; Sun, 24 Jun 2001 16:58:30 -0700 (PDT) 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 QAA16405 for ; Sun, 24 Jun 2001 16:58:29 -0700 (PDT) Received: (qmail 75205 invoked by uid 3039); 24 Jun 2001 23:58:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 24 Jun 2001 23:58:25 -0000 Date: Sun, 24 Jun 2001 16:58:25 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Eamon O'Tuathail" cc: , Subject: Re: [BXXPwg] BEEP Binding for JXTA In-Reply-To: Message-ID: 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 I have talked about this with the jxta developers on #jxta (irc). I will definitely be bringing this up in the jxta/beep workgroup that is forming. -Gabe On Sun, 24 Jun 2001, Eamon O'Tuathail wrote: > >> I would like to see if we can quickly form a virtual > >> group to develop a JXTA BEEP binding. > > Is there any reason why you would not consider using IETF APEX (which is > based on BEEP) as the basis for peer-to-peer services, such as JXTA? > > http://www.ietf.org/html.charters/apex-charter.html > > Eamon > > > _______________________________________________ > 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 Sun Jun 24 20:05:12 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 UAA17146 for ; Sun, 24 Jun 2001 20:05:11 -0400 (EDT) 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 RAA16513; Sun, 24 Jun 2001 17:04:09 -0700 (PDT) Received: from smtppop1pub.verizon.net (smtppop1pub.gte.net [206.46.170.20]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id RAA16494 for ; Sun, 24 Jun 2001 17:04:08 -0700 (PDT) Received: from ksankarw2k (dhcp-171-70-105-15.cisco.com [171.70.105.15]) by smtppop1pub.verizon.net with SMTP ; id TAA131306907 Sun, 24 Jun 2001 19:04:04 -0500 (CDT) From: "Krishna Sankar" To: , Cc: , "Nitin Borwankar" , "Kuldeep SIngh Pabla" , "Gabe Wachob" , "dac" , "akhil" , "Jeffrey Altman" Subject: RE: [BXXPwg] BEEP Binding for JXTA Date: Sun, 24 Jun 2001 17:06:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: 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 Good thought. I was not aware of APEX. Thanks for the pointer. I do not know whether if anyone in the group has looked into APEX. We will definitely look into APEX. In the meantime, would appreciate your comments, ideas, ... cheers |-----Original Message----- |From: bxxpwg-admin@lists.invisibleworlds.com |[mailto:bxxpwg-admin@lists.invisibleworlds.com]On Behalf Of Eamon |O'Tuathail |Sent: Sunday, June 24, 2001 3:05 PM |To: bxxpwg@lists.invisibleworlds.com |Cc: ksankar@gte.net |Subject: [BXXPwg] BEEP Binding for JXTA | | |>> I would like to see if we can quickly form a virtual |>> group to develop a JXTA BEEP binding. | |Is there any reason why you would not consider using IETF APEX (which is |based on BEEP) as the basis for peer-to-peer services, such as JXTA? | |http://www.ietf.org/html.charters/apex-charter.html | |Eamon | | |_______________________________________________ |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 Mon Jun 25 08:07:16 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 IAA12139 for ; Mon, 25 Jun 2001 08:07:16 -0400 (EDT) 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 FAA18466; Mon, 25 Jun 2001 05:06:09 -0700 (PDT) Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id FAA18450 for ; Mon, 25 Jun 2001 05:06:07 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA24130; Mon, 25 Jun 2001 08:06:04 -0400 (EDT) Date: Mon, 25 Jun 2001 8:06:04 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: "Krishna Sankar" Cc: , , , "Nitin Borwankar" , "Kuldeep SIngh Pabla" , "Gabe Wachob" , "dac" , "akhil" Subject: RE: [BXXPwg] BEEP Binding for JXTA In-Reply-To: Your message of Sun, 24 Jun 2001 17:06:13 -0700 Message-ID: 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 APEX relay mesh network can be implemented on top of JXTA as a set of peergroup services. JXTA and APEX serve two different worlds with JXTA being more distributed. However, there is no reason why JXTA and APEX networks cannot communicate with one another. - Jeff > Good thought. I was not aware of APEX. Thanks for the pointer. I do not know > whether if anyone in the group has looked into APEX. We will definitely look > into APEX. In the meantime, would appreciate your comments, ideas, ... > > cheers > > |-----Original Message----- > |From: bxxpwg-admin@lists.invisibleworlds.com > |[mailto:bxxpwg-admin@lists.invisibleworlds.com]On Behalf Of Eamon > |O'Tuathail > |Sent: Sunday, June 24, 2001 3:05 PM > |To: bxxpwg@lists.invisibleworlds.com > |Cc: ksankar@gte.net > |Subject: [BXXPwg] BEEP Binding for JXTA > | > | > |>> I would like to see if we can quickly form a virtual > |>> group to develop a JXTA BEEP binding. > | > |Is there any reason why you would not consider using IETF APEX (which is > |based on BEEP) as the basis for peer-to-peer services, such as JXTA? > | > |http://www.ietf.org/html.charters/apex-charter.html > | > |Eamon > | > | > |_______________________________________________ > |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 > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 25 15:00:17 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 PAA24225 for ; Mon, 25 Jun 2001 15:00:17 -0400 (EDT) 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 LAA20368; Mon, 25 Jun 2001 11:59:18 -0700 (PDT) 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 LAA20349 for ; Mon, 25 Jun 2001 11:59:16 -0700 (PDT) Received: (qmail 32302 invoked by uid 3039); 25 Jun 2001 18:59:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jun 2001 18:59:06 -0000 Date: Mon, 25 Jun 2001 11:59:06 -0700 (PDT) From: Gabe Wachob X-Sender: To: Jeffrey Altman cc: Krishna Sankar , , , , Nitin Borwankar , Kuldeep SIngh Pabla , dac , akhil Subject: RE: [BXXPwg] BEEP Binding for JXTA In-Reply-To: Message-ID: 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 APEX cannot run over JXTA - APEX is defined only over BEEP. I believe APEX provides the underlying messaging service that JXTA relies upon - I believe (with admittedly limited experience with JXTA) that there is an interesting, if not natural, role for APEX as a transport for JXTA messages. I also do not agree with the assertion that "JXTA being more distributed".. But, lets definitely dig into this and get a better understanding from both sides of the fence so we can come up with a good answer. -Gabe On Mon, 25 Jun 2001, Jeffrey Altman wrote: > The APEX relay mesh network can be implemented on top of JXTA as a set > of peergroup services. JXTA and APEX serve two different worlds with > JXTA being more distributed. However, there is no reason why JXTA and > APEX networks cannot communicate with one another. > > - Jeff > > > Good thought. I was not aware of APEX. Thanks for the pointer. I do not know > > whether if anyone in the group has looked into APEX. We will definitely look > > into APEX. In the meantime, would appreciate your comments, ideas, ... > > > > cheers > > > > |-----Original Message----- > > |From: bxxpwg-admin@lists.invisibleworlds.com > > |[mailto:bxxpwg-admin@lists.invisibleworlds.com]On Behalf Of Eamon > > |O'Tuathail > > |Sent: Sunday, June 24, 2001 3:05 PM > > |To: bxxpwg@lists.invisibleworlds.com > > |Cc: ksankar@gte.net > > |Subject: [BXXPwg] BEEP Binding for JXTA > > | > > | > > |>> I would like to see if we can quickly form a virtual > > |>> group to develop a JXTA BEEP binding. > > | > > |Is there any reason why you would not consider using IETF APEX (which is > > |based on BEEP) as the basis for peer-to-peer services, such as JXTA? > > | > > |http://www.ietf.org/html.charters/apex-charter.html > > | > > |Eamon > > | > > | > > |_______________________________________________ > > |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 > > > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available > The Kermit Project @ Columbia University includes Secure Telnet and FTP > http://www.kermit-project.org/ using Kerberos, SRP, and > kermit-support@kermit-project.org OpenSSL. SSH soon to follow. > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jun 25 16:03: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 QAA25796 for ; Mon, 25 Jun 2001 16:03:57 -0400 (EDT) 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 NAA20747; Mon, 25 Jun 2001 13:02:56 -0700 (PDT) Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA20729 for ; Mon, 25 Jun 2001 13:02:55 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA21137; Mon, 25 Jun 2001 15:59:55 -0400 (EDT) Date: Mon, 25 Jun 2001 15:59:54 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Gabe Wachob Cc: Krishna Sankar , , , , Nitin Borwankar , Kuldeep SIngh Pabla , dac , akhil Subject: RE: [BXXPwg] BEEP Binding for JXTA In-Reply-To: Your message of Mon, 25 Jun 2001 11:59:06 -0700 (PDT) Message-ID: 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 APEX is a set of services (presence, access control, message relaying). There is no reason why those services cannot be implemented within JXTA peer groups. BEEP is just a transport layer which is used by the relays to send APEX messages. There is no reason why those messages could not be sent using JXTA. Its just a question of redefining the underlying protocol. - Jeff > APEX cannot run over JXTA - APEX is defined only over BEEP. > > I believe APEX provides the underlying messaging service that JXTA relies > upon - I believe (with admittedly limited experience with JXTA) that there > is an interesting, if not natural, role for APEX as a transport for JXTA > messages. > > I also do not agree with the assertion that "JXTA being more > distributed".. > > But, lets definitely dig into this and get a better understanding from > both sides of the fence so we can come up with a good answer. > > -Gabe > > On Mon, 25 Jun 2001, Jeffrey Altman wrote: > > > The APEX relay mesh network can be implemented on top of JXTA as a set > > of peergroup services. JXTA and APEX serve two different worlds with > > JXTA being more distributed. However, there is no reason why JXTA and > > APEX networks cannot communicate with one another. > > > > - Jeff > > > > > Good thought. I was not aware of APEX. Thanks for the pointer. I do not know > > > whether if anyone in the group has looked into APEX. We will definitely look > > > into APEX. In the meantime, would appreciate your comments, ideas, ... > > > > > > cheers > > > > > > |-----Original Message----- > > > |From: bxxpwg-admin@lists.invisibleworlds.com > > > |[mailto:bxxpwg-admin@lists.invisibleworlds.com]On Behalf Of Eamon > > > |O'Tuathail > > > |Sent: Sunday, June 24, 2001 3:05 PM > > > |To: bxxpwg@lists.invisibleworlds.com > > > |Cc: ksankar@gte.net > > > |Subject: [BXXPwg] BEEP Binding for JXTA > > > | > > > | > > > |>> I would like to see if we can quickly form a virtual > > > |>> group to develop a JXTA BEEP binding. > > > | > > > |Is there any reason why you would not consider using IETF APEX (which is > > > |based on BEEP) as the basis for peer-to-peer services, such as JXTA? > > > | > > > |http://www.ietf.org/html.charters/apex-charter.html > > > | > > > |Eamon > > > | > > > | > > > |_______________________________________________ > > > |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 > > > > > > > > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available > > The Kermit Project @ Columbia University includes Secure Telnet and FTP > > http://www.kermit-project.org/ using Kerberos, SRP, and > > kermit-support@kermit-project.org OpenSSL. SSH soon to follow. > > > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 28 13:12:35 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 NAA05133 for ; Thu, 28 Jun 2001 13:12:34 -0400 (EDT) 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 KAA07884; Thu, 28 Jun 2001 10:11:20 -0700 (PDT) Received: from smtp3.san.rr.com (smtp3.san.rr.com [24.25.195.40]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA07871 for ; Thu, 28 Jun 2001 10:11:19 -0700 (PDT) Received: from san.rr.com (dt0f7n75.san.rr.com [24.94.25.117]) by smtp3.san.rr.com (8.11.3/8.11.3) with ESMTP id f5SHCGa16463; Thu, 28 Jun 2001 10:12:16 -0700 (PDT) Message-ID: <3B3B6531.56E7F684@san.rr.com> Date: Thu, 28 Jun 2001 10:11:13 -0700 From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Dan Kohn , bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP References: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> <20010615205233.F920@waka.ebuilt.net> 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 "Roy T. Fielding" wrote: > That is not sufficient. The client must know whether or not the > connection must be secured before it makes the first resource request of > the server. In order to know that, the information must be in the URI. Not really. If the server only advertises TLS in the greeting upon connection, it's pretty obvious to the client that that must be negotiated first. > The mechanism used to establish the secure session might be present > in the protocol, as it is with HTTP/1.1 Upgrade, but the decision to make > that upgrade mandatory prior to sending any sensitive information is > something that the client must make using only the URI as a guide. No, the server can enforce it. -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand. This is top-quality raw fish, the Rolls-Rice of Sushi! _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 28 14:08:46 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 OAA16317 for ; Thu, 28 Jun 2001 14:08:45 -0400 (EDT) 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 LAA08387; Thu, 28 Jun 2001 11:07:37 -0700 (PDT) Received: from ixion.tartarus.org (ixion.tartarus.org [195.153.205.133]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA08010 for ; Thu, 28 Jun 2001 10:18:29 -0700 (PDT) Received: from james by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 15FfQr-0002Y2-00; Thu, 28 Jun 2001 18:18:21 +0100 Date: Thu, 28 Jun 2001 18:18:21 +0100 From: James Aylett To: bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010628181821.H29453@tartarus.org> Mail-Followup-To: James Aylett , bxxpwg@invisible.net References: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> <20010615205233.F920@waka.ebuilt.net> <3B3B6531.56E7F684@san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3B6531.56E7F684@san.rr.com>; from dnew@san.rr.com on Thu, Jun 28, 2001 at 10:11:13AM -0700 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 Thu, Jun 28, 2001 at 10:11:13AM -0700, Darren New wrote: > > That is not sufficient. The client must know whether or not the > > connection must be secured before it makes the first resource request of > > the server. In order to know that, the information must be in the URI. > > Not really. If the server only advertises TLS in the greeting upon > connection, it's pretty obvious to the client that that must be > negotiated first. That's not the issue, is it? If there's a service which can either be secured using TLS or not, and some application somewhere wishes to explicitly link to the _secured_ version, then you need that in the URI. The counter argument to this is that in such a situation, the service should really be secured _always_, but I don't think this holds water. I'm sure there are ample situations where a sensible subset of operations could be safely performed over an unsecured connection (perhaps a search engine where a secured connection gives access to more sensitive data?) for this to be a real issue. James -- /--------------------------------------------------------------------------\ James Aylett www.zap.uk.eu.org james@tartarus.org www.footlights.org _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 28 14:29:46 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 OAA01241 for ; Thu, 28 Jun 2001 14:29:45 -0400 (EDT) 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 LAA08687; Thu, 28 Jun 2001 11:28:46 -0700 (PDT) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA08670 for ; Thu, 28 Jun 2001 11:28:45 -0700 (PDT) Received: from san.rr.com ([24.94.25.117]) by smtp2.san.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 28 Jun 2001 11:24:20 -0700 Message-ID: <3B3B7754.F1A70AAD@san.rr.com> Date: Thu, 28 Jun 2001 11:28:36 -0700 From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Aylett CC: bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP References: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> <20010615205233.F920@waka.ebuilt.net> <3B3B6531.56E7F684@san.rr.com> <20010628181821.H29453@tartarus.org> 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 James Aylett wrote: > That's not the issue, is it? If there's a service which can either be > secured using TLS or not, and some application somewhere wishes to > explicitly link to the _secured_ version, then you need that in the > URI. My apologies. I was away for the duration of the conversation, and my mail reader sorted things in a funny way, and I wound up answering before I read the entire thread. Nevermind. -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand. This is top-quality raw fish, the Rolls-Rice of Sushi! _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jun 28 17:48:33 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 RAA08774 for ; Thu, 28 Jun 2001 17:48:32 -0400 (EDT) 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 OAA09983; Thu, 28 Jun 2001 14:47:36 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA09970 for ; Thu, 28 Jun 2001 14:47:35 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5SLlZh31316 for ; Thu, 28 Jun 2001 14:47:35 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f5SLlYL31235; Thu, 28 Jun 2001 14:47:34 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5SLiT001142; Thu, 28 Jun 2001 14:44:29 -0700 Date: Thu, 28 Jun 2001 14:44:29 -0700 From: "Roy T. Fielding" To: Darren New Cc: Dan Kohn , bxxpwg@invisible.net Subject: Re: [BXXPwg] SOAP over BEEP Message-ID: <20010628144429.A1108@waka.ebuilt.net> References: <001e01c0f607$1747f690$6a01a8c0@skymoonventures.com> <20010615205233.F920@waka.ebuilt.net> <3B3B6531.56E7F684@san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <3B3B6531.56E7F684@san.rr.com>; from dnew@san.rr.com on Thu, Jun 28, 2001 at 10:11:13AM -0700 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) 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 Thu, Jun 28, 2001 at 10:11:13AM -0700, Darren New wrote: > > Not really. If the server only advertises TLS in the greeting upon > connection, it's pretty obvious to the client that that must be > negotiated first. The problem I was referring to is one where you have .------------> service peer client peer <=======> proxy peer -------------> service peer `------------> secure service peer wherein the client has a semi-permanent beep session with the proxy, which in turn accesses many different services. Because the profile is selected on a per-connection basis and negotiated up-front, the proxy doesn't find out that the third service peer requires security until after the client peer has sent a request in the clear to the proxy. The ways to avoid the problem are to require that beep proxy connections always be secure (not really practical), or require that an indicator of the secure connection requirement be supplied with the identifier, so that the client peer can know in advance that it must create a separate, secure connection to the proxy for that request. That is why the Web needed both http and https naming schemes. Note that this problem depends on the nature of the application architecture, but will certainly apply to soap over beep. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jun 29 17:30:28 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 RAA25624 for ; Fri, 29 Jun 2001 17:30:27 -0400 (EDT) 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 OAA17252; Fri, 29 Jun 2001 14:29:21 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA17232 for ; Fri, 29 Jun 2001 14:29:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 29 Jun 2001 17:30:57 -0400 Message-ID: Thread-Topic: Redirect Feature for BEEP (continued...) Thread-Index: AcEA4si66eqnk2t6TW6r5hdsjUWZ7g== From: "Bob Wyman" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id OAA17233 Subject: [BXXPwg] Redirect Feature for BEEP (continued...) 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: 8bit Folk will remember that back in January I proposed an HTTP-like "redirect" feature for BEEP. (see: http://lists.invisible.net/pipermail/bxxpwg/2001-January/000478.html) At the time, it was suggested that we wait until after the spec was published before registering features. The specs have been published... I'd like to see a "redirect" feature registered. This would result in greeting replies that look like the following: L: RPY 0 0 . 0 142 L: Content-Type: application/beep+xml L: L: L: L: L: END After having sent such a greeting, a BEEP peer could then respond to a start message with and error message something like the following: S: ERR 0 1 . 264 127 S: Content-Type: application/beep+xml S: S: service not available S: S: END Such an error message would inform the Peer that issued the start message that while the channel cannot be started on the target system, it might succeed if retried on the foo.bar.com system. If the unavailability of the service on the target system is temporary, the redirect would be attached to an error message with code 421. If the unavailability is believed to be permanent, the error code would be 521. Question #1: What is the best way to designate the endpoint to which one should redirect? The "fqdn" and "port" business is necessary since we don't have an URL for BEEP. I would, however, much prefer being able to say: S: or S: However, in the recent "SOAP over BEEP" discussions, it appeared to be widely held that a URI for BEEP was inappropriate... Does redirect present a different case? Question #2: I'd like to save potential round-trips by having the redirect feature provide for modification of the profile elements themselves. i.e. not requiring that one wait for a response to a start element in order to discover that redirection is required. Would it be reasonable to allow for greetings such as: L: L: L: L: Such a greeting would tell you that the JADE protocol might be handled locally, however, if you want "apex," you'll have to try beep at foo.bar.com. Question #3: In the case of temporary unavailability of service for a profile, should the system which issues a redirect be able to provide an estimate for how long the unavailability will last? For instance, the presence protocol provides for "availableUntil." Should redirects be able to state "availableAfter"? i.e.: or Thanks for your consideration. bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jun 30 14:26: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 OAA24431 for ; Sat, 30 Jun 2001 14:26:52 -0400 (EDT) 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 LAA20459; Sat, 30 Jun 2001 11:25:12 -0700 (PDT) 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 LAA20444 for ; Sat, 30 Jun 2001 11:25:11 -0700 (PDT) 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 f5UILHH07681; Sat, 30 Jun 2001 11:21:17 -0700 (PDT) Message-ID: <07fd01c10191$ea6e7e00$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Bob Wyman" , Cc: "Marshall Rose" References: Subject: Re: [BXXPwg] Redirect Feature for BEEP (continued...) Date: Sat, 30 Jun 2001 11:24:34 -0700 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 > After having sent such a greeting, a BEEP peer could then respond to a > start message with and error message something like the following: > > S: ERR 0 1 . 264 127 > S: Content-Type: application/beep+xml > S: > S: service not available > S: > S: END > > Such an error message would inform the Peer that issued the start > message that while the channel cannot be started on the target system, > it might succeed if retried on the foo.bar.com system. If the > unavailability of the service on the target system is temporary, the > redirect would be attached to an error message with code 421. If the > unavailability is believed to be permanent, the error code would be 521. hi. while we're discussing the finer details, could you give me an example or two as to how this would be used in practice. i understand how redirects work with the web and what they're used for. i'm just having difficulty crossing the chasm on this one. thanks, /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg