Sorry it took so long. I had to develop an HTTP 1.1 compliant web
server to test the extending features that draft one placed on the
HTTP bound resource locations described in the magnet specification.
(i.e. http://127.0.0.1:451xx/magnet10/x-xmlmagnet.xml)

In testing I used 3 services: Azureus, Shareaza, and a test service I
made to test the xml specific features; I also tested 2 client
approaches: smart client (a local application to search for and
compile magnet information), and web client (a web page on a supposed
content providers web site). In testing the web client I ran into
problems trying to obtain the xml information across domain
boundaries; IE allowed enough access to make the web client feasible,
but Firefox gave an access denied in all attempts. In testing the
smart client approach I found little that I couldn't implement, but I
noticed limitations and ambiguities in the protocol (my bad).

The web client worked perfectly with Internet Explorer. In fact I see
no problem in writing a script that would load and parse the xml from
each service and writing the content of the htmlbucket element to the
page and using old JavaScript method as a backup. Firefox would always
give an access denied when trying to fetch the xml, but of course
using JavaScript as a back up will be able to cover that. However,
not all applications that can handle magnet links will bind a web
server to the 45100-45199 range. Shareaza attempts to handle magnet
links directly, setting it's DDE name as a verb for the "magnet" URI
scheme in the registry. DDE can not be accessed by a web page.

I have been very successful in writing the smart client. The smart
client would first check the /magnet10/canhandle.img resource to get
three of the necessary pieces of information: is there a web server
bound to this port, can this server handle this link, and what is this
servers icon. For each service that did return an icon the smart
client then attempted to read the xml information. The display
information was then compiled listing the service's icon and name and
each of the entities' identifiers and the options for each entity if
xml information was available. The information was then displayed in a
window.

Example:
Azureus' icon was shown and named as `Unnamed' since no xml
information is available.
The test service's icon was shown on the next line followed by it's
name. The next lines contained a list of information about the topics
requested which included the exact topic hash or display name and each
option that the user could choose.

Shareaza could not be found using this same method since it attempts
to handle magnet links directly, but that doesn't mean it can't be
added to the list. I had the idea of having the search application
read additional options from a file. The file would have described
regular expressions to match against arguments of the magnet link,
display information for the option and a simple action or command to
execute. The only problem was that Shareaza would not take the magnet
link from command line but only from DDE. I do not know how to trigger
DDE with out the help of explorer in the form of a URI, which is no
help since it would be the search application that directly handles
the magnet links, not Shareaza.

The options that provided simple actions alone proved to provide a
great deal of interactivity since any form of URI was allowed. A
service could return several more magnet links, web links, or even
link to an IRC chat room amongst many more things.
I did not actually test the xml callback action but I am sure that it
should work since I tested the option search using both the query
string and by use of a message body.

Now before I write up draft specification two I would like to ask for
comments on a few key areas.

Search locations:
I would like more information on searching for applications that can
handle magnet links other than by searching ports 45100-45199 or by
reading a settings file. Anything like information that the
application would add to the registry or application files to check for.

Requesting xml information:
I can conceive three methods of request. The first one is by sending a
single string. This string is simply either the query string of the
magnet link or the entire URI depending on how it's being passed. The
second would be a true xml RPC. The RPC would have to be able to send
a request body, containing a SOAP message who's body should be xml.
The third would be a simple non SOAP request body.

Draft one simply declared that where both a query sting and a request
body could be sent that the string should always be sent as a backup
and the request body was optional. Additionally, when the request body
was sent it was simply a subset of the xml that would be returned in
the response.
I would like to change the request body into either simply a MAGMA
entity or a fully formed SOAP message. The use of a MAGMA entity would
greatly simplify the act of parsing the request body for the service.
The alternative, sending a SOAP message, would require that the body
remain xml formatted but would give the advantage of far greater
extensibility than what was allowed by draft one.
I would also like to note that preserving xml as being the format for
the request body would require several changes from draft one. Draft
one declared that xt should be mapped to the exact topic element, kt
should be mapped to the keyword topic element, mt should be mapped to
the manifest topic element, and dn should be mapped to the display
name element. This was a very limited list and provided no method of
adding application specific arguments. Draft two will include a way to
list arguments of any name either by sending the request body as MAGMA
or by declaring a more generic element with an attribute to define
what the argument name is.

Returning an xml response:
Draft one had a poor definition on how to describe each option
returned. No real formatting methods were officially declared, and the
descriptions for use in web clients was separated from the
descriptions for use in smart clients. I want to restructure the
response body using XHTML modules on top of an xml magnet structure
module. That is to say the response body will resemble an XHTML 1.1
document. The search client would parse out the xml magnet structure
and compile the documents into a single document. Then, the smart
client would render the resulting document like a normal XHTML 1.1
document but also giving any attention to inline elements that may be
declared by xml magnet or by external xml namespaces that the client
just so happens to be compliant with. I would like comments on what
XHTML modules should be implemented, on the base structure of the xml
magnet module, and on any inline elements that could be used in an xml
magnet + XHTML document.

XHTML modules that may be implemented:
Basic forms
Basic tables
Bi-directional text
Hypertext
Image
List
Style attribute
Text

This is not a definite list. I'm asking for comments on this list.

Some consideration on how to implement CSS will be necessary. The
style attribute can be placed in any visual element and it's effect is
limited to that element, but the style element must be placed in an
html head element and effects the entire document. Perhaps the html
style element could simply be mirrored as a style element in a non
visual part of the base magnet structure. The method of applying the
style sheet information would be application dependant, but the style
sheet of one particular response must only be applied to the visual
elements.

Should the xml callback be obsolete?
If forms were to be implemented it could be possible to use a form to
do most of what the xml callback of draft one was designed to do (I.e.
send a specified query back to a specific magnet handling
application). However, the xml callback was meant to retrieve
additional options. If you were to activate an option that used the
callback method the client could have had the option of simply
replacing the callback option with the options given in the response
to the callback. This exact behavior could be implemented using a
magnet specific element. Example: You could click on a hyperlink or
submit a form and the response information could be automatically
added to an element who's ID matches a magnet specific attribute in
the link or form.