[Enum] Re. 2916bis

Lawrence Conroy <lwc@roke.co.uk> Sat, 16 February 2002 17:34 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14728 for <enum-archive@odin.ietf.org>; Sat, 16 Feb 2002 12:34:53 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12084 for enum-archive@odin.ietf.org; Sat, 16 Feb 2002 12:34:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11276; Sat, 16 Feb 2002 12:22:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11251 for <enum@optimus.ietf.org>; Sat, 16 Feb 2002 12:22:51 -0500 (EST)
Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14402 for <enum@ietf.org>; Sat, 16 Feb 2002 12:22:45 -0500 (EST)
Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062551; Sat, 16 Feb 2002 17:22:48 +0000
Mime-Version: 1.0
X-Sender: lwc@193.118.192.24
Message-Id: <p05100301b894424fc619@[193.118.192.41]>
Date: Sat, 16 Feb 2002 17:22:47 +0000
To: paf@cisco.com
From: Lawrence Conroy <lwc@roke.co.uk>
Cc: enum@ietf.org
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11252
Subject: [Enum] Re. 2916bis
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 8bit

At 8:59 pm +0100 15/2/02, Patrik Fältström wrote:
>I have here compiled a list of things to be changed to RFC 2916 when
>2916bis is created.
<snip>
>(8) Examples must be corrected and made made clear. For example, there
>should be absolutely no confusion about (?that?) full regular 
>expressions are used.
>I.e. any delimiter and any matching mechanism can be used

To which I reply:
    I am having major trouble (apart from just reading the DDDS collection :)
in finding answers to the following questions:
(i)   Is there ever a need to have anything other than a "complete 
replacement" as the rule substitution expression when applying an 
ENUM query to the e164.arpa domain space?

[Point (8) suggests that there is a need for full regular expressions 
- I can't think of a case where this is needed.]

(ii)  Is there ever a need to use a non-terminal NAPTR record when 
dealing with ENUM (e.164.arpa domain space) records?

(iii) RFC2916 states that tel: URIs should be re-submitted to the 
ENUM system, and that the Client is responsible for loop detection.

Richard has suggested that this is not needed; a tel: URI should NOT 
be re-submitted. On reflection, I agree with him - I can't think of a 
particular reason why such a re-submission is needed either - can 
anyone else think of a case?

[If not, the required tel: flag document is not too hard, and there 
may not *be* a problem with loops - it also solves Jon's concerns 
from the sipping-e164 document, I think :]

best regards,
    Lawrence
-- 
lwc@roke.co.uk: +44 1794 833666::<my opinions>:

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