Subject: RE: [Enum] FW: Last Call or New Draft? - Portability

From: [email-masked]
Date: Thu, 6 Jul 2000 11:56:13 +0300

Hi Michael,

> Sure. Very similar actually:
>  
> $ORIGIN     9.0.3.5.7.6.8.2.9.7.1.e164.arpa.
> IN NAPTR 10 10 "u" "sip+N2R"      "!^.*$!sip:[email-masked]!" .
> IN NAPTR 10 10 "u" "smtp+N2R"     "!^.*$!mailto:[email-masked]" .
> IN NAPTR 10 10 "u" "http+N2R"     "!^.*$!http://jenny.ispa.net" .
> IN NAPTR 10 10 "u" "tel+N2R"      "!^.*$!tel:+1-792-867-5309" .
> 
> Patrik has some other examples but I'll let him forward them when
> he's done...

That clears a few things up in my mind, but could you help me out
a little bit more?  For the SIP example, is there any way to 
differentiate between different transport protocols (UDP, TCP, SCTP) 
in the records?

Or even more generally, if I wanted some service, let's call
it 'GOO' which had a couple of different protocol options, how
can we capture that?

Would it be something like:

IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!tcp:[email-masked]!" .
IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!sctp:[email-masked]!" .
IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:[email-masked]!" .

Thanks,
John Loughney

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 6 Jul 2000 12:37:02 -0700

>IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:[email-masked]!" .

 From my point of view, that should be part of the SIP protocol 
routing/resolution process to take care of, and in your example, that 
should be resolved in the GOO protocol suite.

That said, Greg mentioned to me (I don't remember if it was privately 
or on this mailing list) that in the case of VPIM, mailto-URI's are 
used, but it can be fax, voicemail or whatever content that is sent 
in the email.

My proposal would be to write a specific I-D about how to handle each 
one of these cases.

For example, one document can be:

    "Use of mailto URIs when doing ENUM resolution"

The solution could I guess (Michael, you know the NAPTR better than 
me) to define new flags for the NAPTR stuff as you suggest above for 
GOO, but maybe not syntactically exactly that way. More like this:

IN NAPTR 10 10 "u" "goo._tcp+N2R"   "!^.*$!goo:[email-masked]!" .
IN NAPTR 10 10 "u" "goo._sctp+N2R"  "!^.*$!goo:[email-masked]!" .
IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!goo:[email-masked]!" .

    paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 6 Jul 2000 15:36:44 -0400

> differentiate between different transport protocols (UDP, TCP, SCTP) 

By using that field in the SIP URL format (Section 2 of RFC2543):
sip:j.doe:[email-masked];transport=tcp
sip:j.doe:[email-masked];transport=udp
sip:j.doe:[email-masked];transport=sctp

> IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!udp:[email-masked]!" .

I would create a new Service as in I2GOO following the format's 
specified in RFC2483. This would read as:

NAPTR 10 10 "u" "gsmtp+I2GOO" "!^.*$!mailto:[email-masked]!" .
NAPTR 10 10 "u" "gsip+I2GOO"  "!^.*$!sip:[email-masked];transport=tcp!" .
NAPTR 10 10 "u" "girc+I2GOO"  "!^.*$!irc:[email-masked];someircbla!" .

(Note how I use gsmtp instead of just smtp since the Goo service probably
can't use SMTP by itself, it would have to specify some profile of
SMTP that specifies how its use with the Goo service. In the
URN stuff we used THTTP since its a profile of how to do URI resolution
using HTTP. If we had simply said the protocol was HTTP that wouldn't
have given anyone enough of a guideline for how to actually use HTTP
for that purpose. And since it wasn't meant to be fully HTTP we 
called it something else in order to disambiguate between them.)

That's just my opinion though. You'd have to check with Patrik on 
whether the use of Services outside of N2R fits the intent...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Thu, 06 Jul 2000 14:54:40 -0500

>
>My proposal would be to write a specific I-D about how to handle each one 
>of these cases.
>

Or ... "The use of ENUM services in SIP"

Or  " The use of ENUM services by H.323 gateways"

et.al

>The solution could I guess (Michael, you know the NAPTR better than me) to 
>define new flags for the NAPTR stuff as you suggest above for GOO, but 
>maybe not syntactically exactly that way. More like this:
>

Mike ...correct me if I'm wrong here ..but were you thinking about a IANA 
registration procedure here for NAPTR service types?

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Michael Mealling <[email-masked]>
Date: Thu, 6 Jul 2000 15:43:20 -0400

> My proposal would be to write a specific I-D about how to handle each 

Yep....

> IN NAPTR 10 10 "u" "goo._udp+N2R"   "!^.*$!goo:[email-masked]!" .

I would prefer that we create new Service types instead of new 
protocols. I.e. is the Goo Service actually returning the resource
or is it returning some Goo service specific bit of information? If
its just returning the resource then I2R is appropriate but I dobut
that's what we're doign here.

I.e. create (and hopefully publish) the Goo service and create new
Service parameters such as I2GR (Identifier to Goo Resource) or
E2GM (E164 Number to Goo Metadata). I.e. once you're in the Goo
system you get (and should) define new Services to appropriately
refleect what actual functions you're after...

Also, after thinking about this some. I do think that the Service
you're using in ENUM should be something new. I2R (N2R was deprecated)
means "URI to Resource". ENUM is doing "E164 Number to URI" so it
should be something new tag here (E2I?)

-MM

---

From: Michael Mealling <[email-masked]>
Date: Thu, 6 Jul 2000 15:51:04 -0400

> registration procedure here for NAPTR service types?

Yep. RFC 2483 doesn't specify one but it does suggest that one should
be created if needed. It provides a template and some loose policies.
Setting up an IANA registry for these would be very easy....

-MM