[Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt

Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> Wed, 21 March 2012 16:45 UTC

Return-Path: <laurentwalter.goix@telecomitalia.it>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18121E8087 for <enum@ietfa.amsl.com>; Wed, 21 Mar 2012 09:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.776
X-Spam-Level:
X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLx6AaHL4h+B for <enum@ietfa.amsl.com>; Wed, 21 Mar 2012 09:45:03 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id C019B21E805D for <enum@ietf.org>; Wed, 21 Mar 2012 09:45:02 -0700 (PDT)
Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Mar 2012 17:44:59 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 21 Mar 2012 17:44:59 +0100
From: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
To: Lawrence Conroy <lconroy@insensate.co.uk>
Date: Wed, 21 Mar 2012 17:44:57 +0100
Thread-Topic: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt
Thread-Index: Acz5PZKOmAsKt8qTRaKW9euiLoSs9AOP7MmQ
Message-ID: <A09A9E0A4B9C654E8672D1DC003633AE52EDAFA343@GRFMBX704BA020.griffon.local>
References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk>
In-Reply-To: <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk>
Accept-Language: en-US, it-IT
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, it-IT
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF ENUM list <enum@ietf.org>, "likepeng@huawei.com" <likepeng@huawei.com>
Subject: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/enum>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2012 16:45:04 -0000

Hello lawrence, all,

I'd like to resume the discussion on the draft in this list, as at this stage it seems more appropriate.

I could see that a couple of points (mostly in section 4) have triggered some concerns that I'd like to clarify and seek for your guidance:

-       the first paragraph of section 4, despite its poor wording, wants to point out that this service may be *also* used in enum "infrastructures" other than "e164.arpa", for example in cases where such infrastructure is restricted to CSPs (e.g. "e164.gprs" or others). My feeling is that rfc6116 does mentions this possibility somehow (e.g. see section 3.6) but I can't find a clear section where to refer to more formally (I agree that the reference to section 2 was a bad choice for it). Is there any other reference that could be used for this?

-       regarding loop mitigation it was my intention to address it in paragraph 2 of section 4, but the wording was not appropriate neither (and I realized there is no clear mention on when the process should stop). The intention here would be to clarify that if no "acct" record is found, subsequent enum queries could apply recursively to any e164 number found in records containing tel URIs independently from the specific service, still aiming at identifying an "acct" uri. I could further imagine that the idea to mitigate loops would be based on rfc4759 principles so that when the same number is found, or another one containing a dip indicator the recursion should be stopped and the process considered completed with no acct uri found. Do you have any recommendation based on your experience of similar enum services?

Thank you
Walter


-----Messaggio originale-----
Da: Lawrence Conroy [mailto:lconroy@insensate.co.uk]
Inviato: sabato 3 marzo 2012 14.00
A: Goix Laurent Walter
Cc: Richard Shockey; IETF ENUM list
Oggetto: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt

Hi Laurent-Walter, Richard, folks,
 As one of the authors of RFC6116, I'm intrigued with section 4 of this draft.

AFAICT, section 4 of this draft specifically states that E2U+acct can be used in an entirely different namespace from ENUM. That's an interpretation of 6116 section 2 that I don't recognise.

The second paragraph of Section 5 is ambivalent on this, but section 4 spells out that a separate apex may be used.
That directly contradicts its example, and in any case the Enumservice template is incorrect for such private use (in that case, it would need to be "limited", not "common" -- see RFC6117 section 5.2.7 **).
=> Was that intended -- does that first paragraph of section 4 of this draft help?

As I understand the second paragraph of section 4, the intention is that an implementation will chase pstn:tel records looking for a domain with an appropriate E2U+acct record. That looks like it's stretching the pstn:tel use given in RFC4769 section 3.1, but ...

The last bullet of section 5.5 of RFC6117 states that the registration doc needs to cover loop mitigation.
It may be unfair, but RFC4769 was not covered by the current rules, so they dodged the bullet of that requirement.
This draft can't, so you will have to spell out the rules for loop mitigation.
Merely referring to RFC4694 is not enough; see the last sentence of section 5 of RFC4694.

Finally, section 5 mentions an "activity wall". I wonder if anyone will know what that means in 10 years time.
It is not mentioned directly in the webfinger draft, so if it's spelt out in the referenced OMA service document, from where can one get that spec?

all the best,
  Lawrence
** [E2U+pstn:tel was registered under the "old" rules; this one is covered by 6117]


On 2 Mar 2012, at 21:08, Richard Shockey wrote:
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of internet-drafts@ietf.org
> Sent: Friday, March 02, 2012 10:49 AM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>       Title           : ENUM Service Registration for Social Networking
> (SN) Services
>       Author(s)       : Laurent-Walter Goix
>                          Kepeng Li
>       Filename        : draft-goix-appsawg-enum-sn-service-00.txt
>       Pages           : 7
>       Date            : 2012-03-02
>
>   This document registers a Telephone Number Mapping (ENUM) service for
>   Social Networking (SN).  Specifically, this document focuses on
>   provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.tx
> t
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.txt


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.