Marcos Sanz/Denic wrote:
> 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.

I agree.  That does not seem right.

> 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?

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


_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp