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

["Richard Shockey" <[e-mail]>]

What's the big deal here.  Sure they can clean up some text, but the intent
of the process was to make these things simple.  This is another Carrier
ENUM concept probably in association with RCS or some other scheme.  And
there are lot more coming.

I certainly have no objection to this registration moving forward.

FYI I have it on good authority that the meta data issue is coming back.

-----Original Message-----
From: Lawrence Conroy [mailto:[e-mail]] 
Sent: Saturday, March 03, 2012 8:00 AM
To: [e-mail]
Cc: Richard Shockey; IETF ENUM list
Subject: 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: [e-mail] [mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Friday, March 02, 2012 10:49 AM
> To: [e-mail]
> 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