[regrep] Question regarding section 8.4

[Duane Nickull <duane@xmlglobal.com>]

Hello all:

In reviewing the latest Registry specification,  I noticed that section
8.4 is a little sparse.  I read the lines between 3560 - 3568 in version
2.0 and have a question.

My intepretation of this means that a Registry client can issue a
<GetContentRequest> to an ebXML regsitry.  The Query Manger interface
would take my request and find the metadata for the objects from the
RIM.  To return the content ( in this case the actual Registry
Object(s)),  the query manager (the interface responsible for resolving
the <GetCOntentRequest> message) must resolve the link to the object,
then  retrieve it and package it in an outgoing message and send that
message back to the address specified in the original message (which in
itself could be spoofed).

I question this methodology for a number of reasons:

1.  IMHO - it creates a bottleneck in the system.  A better architecture
might be to have the QueryManager interface do nothing other than return
a traversable link to the actual content, then have the Registry Client
issue the necessary request directly to that link, whether it be
intrinsic or extrinsic. One good reason for this is a person might get
an unexpectedly very large response back from the current
<GetContentRequest> request.  This is the  model that Search engines use
for consumer actors today.  It let's the user then issue the trigger to
perform the final object retrieval (clicking on a hyperlink).  This
example is meant to be illustrative and I am not likening the ebXML
Regsitry to a commercial HTTP Search Engine.

2.  This also creates a potential way for hackers to make "denial of
service" attacks.  Any unauthenticated guest can send in a message with
a bogus <reply-to> address and request 1,000 + Registry Objects be
returned as part of a large <GetContentRequest> message.   That will bog
down the Regsitry.

I hope I have intepretted this section in error.  If not,  may I have
some comments from the team addressing my concerns.

Respectfully

Duane Nickull

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/