[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Enum] 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:Brian.Rosen at neustar.biz]
Gesendet: Di 11.04.2006 17:53
An: Stastny Richard; Henning Schulzrinne; enum at ietf.org
Cc: ecrit at ietf.org
Betreff: RE: URNs in ENUM (Laywer)
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:Richard.Stastny at oefeg.at]
Sent: Tuesday, April 11, 2006 9:50 AM
To: Rosen, Brian; Henning Schulzrinne; enum at ietf.org
Cc: ecrit at ietf.org
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:Brian.Rosen at neustar.biz]
Gesendet: Mo 10.04.2006 20:24
An: Henning Schulzrinne
Cc: ecrit at ietf.org
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:hgs at cs.columbia.edu]
Sent: Sunday, April 09, 2006 9:23 PM
To: Rosen, Brian
Cc: ecrit at ietf.org
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
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum