[Openvas-devel] Updated OMP Specification

[Michael Wiegand]

* Matthew Mundell [ 3. Feb 2009]:
> > Main changes include:
> > - The unique ID is now assigned by the client; this should help the
> >   client to better differntiate between response for multiple new_task
> >   requests.
> 
> I think this is too complicated for the client, as it requires the client
> to keep track of all tasks.  It is also possible that someone could use two
> clients to control the same task.  How would the second client know which
> tasks the first had created?

Right now, this information is available throught the "status" command.
But I think especially for the scenario that you are describing we will
need a way to retrieve the complete information (NVT selection,
preferences etc.) for a particular task. Before editing a task, a client
should use this command to make sure it is working with the most recent
version of this task.

> I think also that the client is always going to know exactly which response
> corresponds to which request.  With direct OMP the client sends a command
> and waits for the response, which always applies to the previous command.
> Even with OMP over HTTP the client gets the response immediately from the
> HTTP server.

I am a little confused as you yourself brought up this issue in your
response from January 17. I am also pretty optimistic that the client
won't issue so many commands that it would get confused by the
responses, so this ID attribute would act as an additional safeguard.
I'm not 100% certain we really need, so if you could explain what made
you change your mind this would probably be helpful.

> > - IDs are included in most responses to improve error handling.
> 
> Again, the client is in the process of requesting this command so it should
> know exactly which ID is involved.

See above.

> > - A lot of information has been moved from elements to attributes to
> >   improve the OMP structure and to simplify parsing.
> 
> This increases the amount of parsing work, as the manager and client now
> also need to do attribute parsing, whereas before it was only elements.

Well, I think attributes do make more sense in certain places. Thanks to
glib, they are easily parsed, so I think the increase is negligible and
outweighed by the improved readability of both protocol and parsing
code.

>  - Nearly all the commands are named with verbs: start_task, modify_task,
>    delete_report, get_nvt_details, etc.  Three are named with nouns:
>    new_task, status and omp_version.  The naming could be made consistent.
>    Perhaps the three could be renamed to make_task, get_status and
>    get_version.

Agreed.

>  - The parameters to new_task are entities, while the parameters to
>    modify_task are attributes.

Yes; this should be consistent, I will look into that.

>  - I think abort_task would match start_task better if abort_task were
>    named stop_task.

Agreed.

>  - There are many response entities.  Could they be merged into one entity?
>    So for example the first new_task_response in CR 28 becomes
> 
> 	   <response status="201" />
> 
>    and the first get_nvt_details_response becomes
> 
> 	   <response status="200">
> 		 <nvt_details>
> 		   <nvt>...</nvt>
> 		 </nvt_details>
> 	   </response>
> 
>    or even
> 
> 	   <response status="200">
> 		 <nvt>...</nvt>
> 	   </response>

I've been thinking of this a well and am not opposed to it. As you have
mentioned previously, we just have to make sure that the client is able
to match the responses it recieves to the requests it sent out.

Regards,

Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090203/3a62aa1e/attachment.pgp