Re: [Crisp] Clarification for error situations needed
Marcos Sanz/Denic <sanz@denic.de> Mon, 29 May 2006 07:46 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkcSA-0002tZ-2l; Mon, 29 May 2006 03:46:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkcS9-0002tU-CS for crisp@ietf.org; Mon, 29 May 2006 03:46:17 -0400
Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkcS8-0004gO-43 for crisp@ietf.org; Mon, 29 May 2006 03:46:17 -0400
Received: from notes.rz.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1FkcS3-0002FD-EN; Mon, 29 May 2006 09:46:11 +0200
In-Reply-To: <44771764.5040100@hxr.us>
To: Andrew Newton <andy@hxr.us>
Subject: Re: [Crisp] Clarification for error situations needed
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
From: Marcos Sanz/Denic <sanz@denic.de>
Message-ID: <OF7108A766.05D88788-ONC125717D.0029EA68-C125717D.002AA92D@notes.denic.de>
Date: Mon, 29 May 2006 09:45:58 +0200
X-MIMETrack: Serialize by Router on notes/Denic at 29.05.2006 09:46:11, Serialize complete at 29.05.2006 09:46:11
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: crisp@ietf.org
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org
Andy, > 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. 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 _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp
- [Crisp] Clarification for error situations needed Marcos Sanz/Denic
- Re: [Crisp] Clarification for error situations ne… Andrew Newton
- Re: [Crisp] Clarification for error situations ne… Marcos Sanz/Denic