Re: [Crisp] Clarification for error situations needed

Andrew Newton <> Fri, 26 May 2006 15:03 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FjdqA-0004Bt-5r; Fri, 26 May 2006 11:03:02 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Fjdq8-0004Bn-Dr for; Fri, 26 May 2006 11:03:00 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Fjdq3-0004kr-6X for; Fri, 26 May 2006 11:03:00 -0400
Received: from [] ([::ffff:]) (AUTH: LOGIN anewton) by with esmtp; Fri, 26 May 2006 10:58:18 -0400 id 01588106.4477178A.00007ED5
Message-ID: <>
Date: Fri, 26 May 2006 10:57:40 -0400
From: Andrew Newton <>
User-Agent: Thunderbird (Windows/20060308)
MIME-Version: 1.0
To: Marcos Sanz/Denic <>
Subject: Re: [Crisp] Clarification for error situations needed
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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 

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 

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.


Crisp mailing list