Subject: [Ecrit] RE: URNs in ENUM (Laywer)

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Apr 2006 11:53:18 -0400

Richard

Read what I wrote.

The enum dip would return urn:service.lawyer
You would use LoST (not SIP) to resolve it
That would resolve to a sip uri

I think that's a LoST enumservice, right?

Brian

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 9:50 AM
To: Rosen, Brian; Henning Schulzrinne; [email-masked]
Cc: [email-masked]
Subject: URNs in ENUM (Laywer)

>Re: 1-800-LAWYER.  The number you gave (1-800-Lawyer) is an e.164
>telephone number.  To make this work using service urns, you would have
>to have the result of an enum dip for this number result in a urn that
>is not currently a valid enum service.  However, if you did make a new
>service, it would work:

Thank you for bringing this forward, I will crosspost this question to
the ENUM WG
 
I am not really sure if you need an new Enumservice at all
 
It depends if a service URN is a valid entry in a SIP URI

If it is you do not even need a a new Enumservice to make this work,
the "sip" Enumservice would be sufficient
 
The real problem here is again to locate the LoST service database
 
any comments here frem ENUM WG?
 
Richard

________________________________

Von: Rosen, Brian [mailto:[email-masked]]
Gesendet: Mo 10.04.2006 20:24
An: Henning Schulzrinne
Cc: [email-masked]
Betreff: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02

Re: 1-800-LAWYER.  The number you gave (1-800-Lawyer) is an e.164
telephone number.  To make this work using service urns, you would have
to have the result of an enum dip for this number result in a urn that
is not currently a valid enum service.  However, if you did make a new
service, it would work:

e.164 is looked up in enum
result is service urn
urn is mapped with LoST
call is sent where indicated, based on location of caller.

Now, the caller would have to voluntarily put location on the call for
this to work.

I read:
   Apart from attempting resolution of a URN, a URN namespace may
       provide mechanisms for "validating" a URN -- i.e., determining
       whether a given string is currently a validly-assigned URN.  

quite literally.  urn:service.sos is a validly-assigned URN because
there is an RFC that says it is (which is the same as saying it's in the
IANA registry of services).  "Validly-assigned" does not mean "currently
active in a domain" to me.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, April 09, 2006 9:23 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: Review of draft-ietf-ecrit-service-urn-02

More responses:

On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote:

> I have reviewed service-urn-02 and have the following comments:
>
> A little concerned about 1-800-LAWYER as an example.  The problem here
> is that there is no obvious mechanism to translate the e.164
> 1-800-LAWYER to the service urn.  I suppose someone could propose an
> enumservice for this purpose, but until they do, we might consider
> removing this particular example

Removing lawyers is always a good idea. (The similarity is that 
dialing this number will get you a lawyer anywhere in the US, with 
the law office depending on where you're calling from.) I don't quite 
understand your concern about needing an enum service.

>
> You need a statement that points out the obvious: since the service 
> urn
> is a protocol labeling mechanism, it has no i18n implications.

I'll add an I18N section.

>
> My biggest problem is the DDDS stuff (section 3).  There is no
> discussion of what domain you query the DNS for.  This is an area well
> worked over by other emergency stuff, and 'fragile' because what you
> normally want is your "local" (as in access network) domain, and it's

I don't think that's really true in general. Why should my access 
network have better information about these services, particularly if 
it has no interest in VoIP or emergency calls? I suspect that, 
initially, the service lookup will be offered by the VSP. They have 
an interest and obligation to provide the service and can't wait 
until every last ISP has decided to provide a mapping service.

> not all that easy to determine what that is.  Read the HELD and LCP
> documents, and the discussion about this point.  I think this document
> needs to handle this.  I think whatever it says is likely to have 
> to be
>

I didn't see any description of this in draft-winterbottom-geopriv-
held-sighting-00. LCP seems to define, besides the usual suspects of 
manual configuration and DHCP, a broadcast request, not specified 
further. (This would be essentially a one-off version of SLP.)

I think there are at least two plausible approaches to find an ISP-
operated domain name, besides DHCP:

(1) SLP or Bonjour; the practical problem is that SLP is seeing 
limited new deployments and Bonjour seems to be under the cloud of 
being non-IETF-developed (but comparatively widely deployed), with 
the IETF competitor having been sent back to the WG for a do-over 
(somebody might know more about this).

(2) Inverse DNS: Get public IP address (via STUN, say); obtain domain 
name (via the usual reverse DNS lookup); use SRV or NAPTR record for 
that domain. This relies on the user's public IP address having a DNS 
entry. As far as I can tell, this seems to be almost universally true 
for residential broadband. (For enterprise users, I suspect that the 
DHCP solution is easiest.)

I had suggested a version of (2).

> the same as any other similar mechanism in the milieu (for example, 
> how
> you find your LoST server).  We need to decide what this text is, and
> copy it into all the relevant documents.

Actually, you find your LoST server via this mechanism, since it 
performs the translation.

>
> I am confused by the "Validation Mechanism" in Section 2.  First of 
> all
> the word "resource" is used here for the first time.  I am assuming it
> has the meaning of 3406 resource.  The real problem is that the 
> section
> in 3406 that talks about validity defines it as "is there a valid
> service" rather than "is the service available".  Using the DDDS
> mechanism would only tell you if a service was available (in the sense
> of configured, rather than in the sense of functioning) within a 
> domain.
> While I think you could keep most of this text if you qualify it, I
> think the actual answer is that the validation mechanism is IANA
> assignment.

I agree that this doesn't quite fit; I reread 3406 and 3406 defines 
validation thusly:

   Apart from attempting resolution of a URN, a URN namespace may
       provide mechanisms for "validating" a URN -- i.e., determining
       whether a given string is currently a validly-assigned URN.  
[...]

This seems to imply that this mechanism would allow to determine 
whether urn:service:timezone, say, exists or not. This would 
presumably be done by the lookup mechanism.

I'll reword the paragraph to hopefully make the distinction clearer.

(more to follow)

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Apr 2006 10:39:04 +0200

Thanx Tony for this extensive explanations
 
So IMHO this is not so much an ENUM problem, but a problem
of the definition of the service URNs
 
Before we define service URNs, we need to define what a service is ;-)
 
good luck
 
I see e.g. global services and local services

all location based services are local services, as the name implies
maybe we need a distinction in the service  URN definition of a service
is the same everywhere or if it is locally different. This also requires
a definition of the related database e.g. LoST, etc. etc.
 
Richard

Von: Tony Rutkowski [mailto:[email-masked]]
Gesendet: Di 11.04.2006 16:43
An: Stastny Richard; Rosen, Brian; Henning Schulzrinne; [email-masked]
Cc: [email-masked]
Betreff: Re: [Enum] URNs in ENUM (Laywer)

Hi Richard,

>NPRM

Notice of Proposed Rulemaking.  All changes to E.164
requirements and use in the U.S. is subject to the
exclusive jurisdiction of the FCC pursuant to the
Communications Act of 1996 and related judicial
decisions.  The FCC is obligated to proceed to
make changes through a public consultative process
consisting of a NPRM, followed by comments, reply
comments, and implementing Orders.  Some of this
authority at the State level is shared with the
Public Service Commissions through a separate
consultative mechanism.

The 800 number block and the associated services
were the subject of extensive previous proceedings
in conjunction with the rollout of the existing
"ENUM" services based on the Intelligent Network.

>SDO

Standards Development Organization, e.g., ATIS,
ETSI, etc.  Some of these bodies have special
regulatory related roles where E.164 number based
resolvers/directories are concerned.

>INC ?

Industry Numbering Committee - an ATIS forum.
See http://www.atis.org/inc/index.asp  ATIS
was created by the FCC at the time of the ATT
breakup to serve as the industry wide forum
for developing technical and administrative
standards for the telecommunication infrastructure.
Over the years - particularly in matters relating
to signalling systems and practices, ATIS was
regarded as the implementation mechanism for
requirements established by the FCC.  Its
role is similar to both ETSI and and perhaps
ERO/ENF.

best,
tony

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Apr 2006 08:15:24 -0400

No, not all service urns resolve with LoST; only those which are
location based.

There is a defined procedure to resolve a service URN.  I expect the
enumservice is not really a LoST service, it's a service URN service,
for which there is a defined resolution process.  

Brian

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2006 4:49 AM
To: Rosen, Brian; Henning Schulzrinne; [email-masked]
Cc: [email-masked]
Subject: Re: URNs in ENUM (Laywer)

Hmm,
 
This could be done. OTOH, do all URN:service resolve with LoST
 
This seems a bit a chicken-and-egg problem
if a user enters a service URN direct, there must be a way to resolve it
within e.g. SIP
anyway, so why burden ENUM resolvers with service resolving
do it one after the other ENUM - SIP - LoST-SIP
 
especially if the UA is not capable of doing LoST
so the service URN has to be forwarded to the proxy anyway via SIP
 
Richard

Von: Rosen, Brian [mailto:[email-masked]]
Gesendet: Di 11.04.2006 17:53
An: Stastny Richard; Henning Schulzrinne; [email-masked]
Cc: [email-masked]
Betreff: RE: URNs in ENUM (Laywer)

Richard

Read what I wrote.

Brian

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Tuesday, April 11, 2006 9:50 AM
To: Rosen, Brian; Henning Schulzrinne; [email-masked]
Cc: [email-masked]
Subject: URNs in ENUM (Laywer)

Richard

I read:

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, April 09, 2006 9:23 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: Review of draft-ietf-ecrit-service-urn-02

More responses:

(more to follow)

Henning