Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
Ward Harold <wharold@us.ibm.com> Thu, 10 October 2002 19:47 UTC
Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21435; Thu, 10 Oct 2002 15:47:41 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA09115 for ietf-outbound.09@loki.ietf.org; Thu, 10 Oct 2002 15:32: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 PAA09033 for <ietf-mainout@loki.ietf.org>; Thu, 10 Oct 2002 15:25:59 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id PAA20611 for ietf-mainout@loki.ietf.org; Thu, 10 Oct 2002 15:23:52 -0400 (EDT)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from e34.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18167 for <ietf@IETF.ORG>; Thu, 10 Oct 2002 14:06:36 -0400 (EDT)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9AI8X8h031614; Thu, 10 Oct 2002 14:08:34 -0400
Received: from d03nm119.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9AIA66p129614; Thu, 10 Oct 2002 12:10:06 -0600
Reply-To: wharold@us.ibm.com
Subject: Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
To: Timur Shemsedinov <Timur@niist.ntu-kpi.kiev.ua>
Cc: ietf@ietf.org, mrose@dbc.mtview.ca.us
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Message-ID: <OF088ED4C8.B0FA782F-ON87256C4E.005EF00A@us.ibm.com>
From: Ward Harold <wharold@us.ibm.com>
Date: Thu, 10 Oct 2002 13:08:32 -0500
X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0|September 26, 2002) at 10/10/2002 12:08:32
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org
Timur, my responses to your questions follow: 1. The "uri" attribute associated with a "start" message's "profile" element is equivalent to an XML namespace name. It is a URI that uniquely identifies a BEEP profile; it is just an identifier and does not necessarily point to anything on the Web. 2. The methodCall, methodResponse, and associated parameter encodings are all defined by the XML-RPC specification: http://www.xmlrpc.com/spec. The draft explains how to use BEEP to transfer XML-RPC encoded messages between peers not how to actually do the encoding. 3. Grace and beauty are in the eye of the beholder; regarding brevity it is no doubt possible to define a more compact encoding, even using XML, but in this case the XML-RPC authors defined what they defined. ... WkH Timur Shemsedinov <Timur@niist.ntu-k To: Ward Harold/Austin/IBM@IBMUS pi.kiev.ua> cc: ietf@IETF.ORG Subject: Re: Last Call: Using XML-RPC in BEEP to Proposed Standard 10/10/2002 12:08 PM Please respond to Timur Shemsedinov > http://www.ietf.org/internet-drafts/draft-harold-beep-xmlrpc-00.txt There are some questions concerning xmlrpc and some, most probably, even beep. 1. How it can work in local networks if IANA is not accessible and profiles can be received neither from the client nor from the server of such network? Or they are placed locally, if so why URL refers to iana.org ? I believe that it works, but how? It is not clearly documented by BEEP specification and is not considered in mentioned draft. C: <start number='1' serverName='stateserver.example.com'> C: <profile uri='http://iana.org/beep/transient/xmlrpc'> C: <![CDATA[<bootmsg resource='/NumberToName' />]]> C: </profile> C: </start> 2. Few examples are given in the document, it is difficult to get complete understanding of the complex structured parameters representation. 3. Looking on the following example, any person can have idea, whether it is impossible to represent a call briefly and gracefully even using XML? I: MSG 1 1 . 0 364 I: Content-Type: application/xml I: I: <?xml version="1.0"?> I: <methodCall> I: <methodName>examples.getStateName</methodName> I: <params> I: <param> I: <value><i4>41</i4></value> I: </param> I: </params> I: </methodCall> I: END L: RPY 1 1 . 201 100 L: Content-type: application/xml L: L: <?xml version="1.0"?> L: <methodResponse> L: <params> L: <param> L: <value><string>South Dakota</string></value> L: </param> L: </params> L: </methodRespose> L: END -- Best regards, Timur mailto:Timur@niist.ntu-kpi.kiev.ua
- Re: Last Call: Using XML-RPC in BEEP to Proposed … Timur Shemsedinov
- Re: Last Call: Using XML-RPC in BEEP to Proposed … John Stracke
- Re: Last Call: Using XML-RPC in BEEP to Proposed … Ward Harold
- Re[2]: Last Call: Using XML-RPC in BEEP to Propos… Timur Shemsedinov
- Re: Last Call: Using XML-RPC in BEEP to Proposed … John Stracke
- Re: Re[2]: Last Call: Using XML-RPC in BEEP to Pr… Ward Harold
- Re: Re[2]: Last Call: Using XML-RPC in BEEP to Pr… Valdis.Kletnieks
- Re: Re[2]: Last Call: Using XML-RPC in BEEP to Pr… Lloyd Wood
- Re: Re[2]: Last Call: Using XML-RPC in BEEP to Pr… Caitlin Bestler
- Re[4]: Last Call: Using XML-RPC in BEEP to Propos… Timur Shemsedinov