Subject: [Crisp] Clarification for error situations needed

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 26 May 2006 14:06:15 +0200

Dear all,

We are trying to get some corner cases of our DCHK implementation right. 
This one tracks back to IRIS core itself and is about sending an 
inexistent/not supported registryType or entityClass in a query to a 
server, for instance:

  <searchSet>
    <lookupEntity registryType="inexistent_type_here" 
entityName="denic.de" entityClass="inexistent_class_here"/>
  </searchSet>

I am unsure about what the correct answer from the server would be.

VeriSign's IRIS server quits with a BEEP error 501, but this doesn't seem 
right to me: RFC 3080 defines 501 as "syntax error in parameters (e.g., 
non-valid XML)" and illustrates with two examples, in which *BEEP's own 
XML* contains wrong parameters, not the XML of the application being 
transported. This latter approach being sound for me: we shouldn't start 
mixing up errors of different layers.

To be able to solve this at the IRIS layer itself, we have the codeTypes 
<invalidName> and <invalidSearch> in RFC 3981:

  o  <invalidName> -- A name given in a query is not syntactically 
correct.
  o  <invalidSearch> -- Parameters of the corresponding query are not 
semantically meaningful.

But I am not sure which one should apply here: A "name" was rather meant 
to be an "entity name", I don't think this to be the correct error code. 
OTOH, values of query attributes are somehow "parameters" of the "query" 
(it's actually not a query, but a lookup, however that should not be 
relevant here). 

Alternatively a more neutral

   o  <nameNotFound> -- The name given in a query does not match a known 
entity.

could be returned, since at the end of the day, the lack of a match is 
true. But then the futility of further queries for that registryType or 
entityClass is not communicated to the client.

You see: two RFC authors, two different implementations. What do you 
think? And what are doing other implementations out there?

Best regards,
Marcos

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 May 2006 10:57:40 -0400

> mixing up errors of different layers.

I agree.  That does not seem right.

> think? And what are doing other implementations out there?

Let me throw one more at you.  Flowerbed returns <queryNotSupported> 
with a description "registry type of xxxxxx is not supported by this 
server."

In my opinion, <invalidName> and <nameNotFound> are errors reserved for 
when the registry type is correct but the entity name is not found or 
the entity name is screwed up for the entity class given (e.g. an IPv6 
address in a entity class of IPv4 addresses).

And <invalidSearch> is cohort of <invalidName> for searches (i.e. not 
lookups).

No matter what, there should be no hard and fast rule here.  Clients 
MUST be able to handle all of these errors, and which one a server 
returns depends on how much the server operator wishes to obfuscate the 
identifiers of their data.  For instance, an operator may decided to 
return <nameNotFound> so that the user thinks that registry type does 
exist but they just got the name wrong.

I hope that helps.

-andy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Mon, 29 May 2006 09:45:58 +0200

Andy,

> exist but they just got the name wrong.

This is a very wise statement. Maybe the futility I was talking about is a 
feature, not a bug.

For consistency reasons, we'll go for <queryNotSupported>.

Regards,
Marcos