Re: Last Call: Using XML-RPC in BEEP to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]