Subject: [Enum] enumservices in new version of 2916bis

From: "Robert H. Walter" <[email-masked]>
Date: Fri, 28 Jun 2002 12:57:32 -0400

R. Stastny and R. Shocky,

I think we are very close to concensus... BTW, I like the spirit of
the draft-brandner-tel-svc-00.txt I-D and also believe that a tight
correlation between the TEL URI svc parameters and the ENUM service
specification is a good thing.

I reiterate that the purpose of the service field is to allow an
application to rapidly select NAPTR records that are meaningful
to its purpose and/or function.  Consider the following examples:

An application wants to send a voice message to a voice messaging
system that supports an SMTP interface and it only knows a telephone
number.  This can be handled with EITHER of the following NAPTRs:

   NAPTR 0 0 "U" "E2U+vmail" "!^.*$!mailto:user@domain!" .
   NAPTR 0 0 "U" "E2U+vmail:mailto" "!^.*$!mailto:user@domain!"

A SIP UAC wants to initiate a voice session with another SIP UAC
and it only knows a telephone number.  Since SIP supports some
degree of service negotiation this can be handled with EITHER of
the following NAPTRs:

   NAPTR 0 0 "U" "E2U+srs" "!^.*$!sip:domain!" .
   NAPTR 0 0 "U" "E2U+srs:sip" "!^.*$!sip:domain!"

In each example above, I assert that both NAPTR records are
equivalent and placing the URI Scheme in the service field is merely
a performance optimization.  If we decide that the performance
optimization is so important that it becomes a MUST, then so
be it, otherwise I recommend it SHOULD be used, however specified
as optional.

The core issue I am addressing is that service discovery, applicability
and location are different but related things...  Applications need to
discover if a particular communication service is available, i.e. Real-
time voice, Voice Messaging, etc.  The service or "svc" parameter
addresses the discovery issue.  The URI scheme or service protocol
addresses the applicability issue or what protocol to use to communicate
with the service.  Once the application determines that a service exists
and that it can communicate with, it leverages the URI to locate it.

Based on the requirements R. Stastny defined I suggest the following:

Using R. Stastny's short-hand schema:  "E2U+service:uri-scheme".  The
complete ABNF is as follows:

    enum-service = "E2U" 1*( "+" service [ ":" uri-scheme ] )

    service      = "voice" / "video" / "email" / "vmail" /
                   "mms" / "sms" / "tdd" / "srs" / "fax" / extension

    uri-scheme   = "mailto" | "sip" | "h323" | other

    extension    = ALPHA *( ALPHA / DIGIT )

    DIGIT        = %x30-39             ; 0-9

    ALPHA        = %x41-5A / %x61-7A   ; A-Z / a-z

The addinfo is addressed through the extension production on the
service and uri-scheme productions.

R. Shockey, J. Peterson:  I'm cool with "srs" as a service, thus
SIP can do its negotiation thing without impedding AOR...

Finally, the definition of the service and uri-schemes in the ABNF
above are illustrative and should follow Patrik's recommendation
from yesterday.

Thanks To All,

Bob
======================================================================
Robert H. Walter - CTO, VP Engineering                tel:+19788482831 
NetNumber, Inc.                                       fax:+19784545044
650 Suffolk Street                        mailto:[email-masked]
Lowell, MA  01854

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

---

From: Richard Shockey <[email-masked]>
Date: Fri, 28 Jun 2002 13:36:03 -0400

>to its purpose and/or function.  Consider the following examples:

Which is also why some of us argue the URI/protocol is first

>    NAPTR 0 0 "U" "E2U+vmail:mailto" "!^.*$!mailto:user@domain!"

I'd like these reversed ...

This in my view this construct is not good since vmail is not a 
URI/protocol ..that needs to always be there.

Therefore the proper expression proper would be

                     NAPTR 0 0 "U" "E2U+mailto:vmail" 
"!^.*$!mailto:user@domain!"

or simply

                      NAPTR 0 0 "U" "E2U+mailto" 
"!^.*$!mailto:user@domain!" . The transaction result is the same ..but it 
has the advantage of not exposing that this is really a vmail box.... but 
again as I noted in previous messages I'd like to see the input from the 
VPIM group first on these issues.

>    NAPTR 0 0 "U" "E2U+srs:sip" "!^.*$!sip:domain!"

reverse again ...

>be it, otherwise I recommend it SHOULD be used, however specified

IMHO MUST ...

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Robert H. Walter" <[email-masked]>
Date: Fri, 28 Jun 2002 14:33:03 -0400

Hi Richard,

>      NAPTR 0 0 "U" "E2U+mailto:vmail" "!^.*$!mailto:user@domain!"
>
> or simply
>
>      NAPTR 0 0 "U" "E2U+mailto" "!^.*$!mailto:user@domain!"
>
> The transaction result is the same ..but it has the advantage of not
> exposing that this is really a vmail box.... but again as I noted in
> previous messages I'd like to see the input from the VPIM group first
> on these issues.

Respectfully, the transaction result is not the same. Without the service
the application has no idea what type of communication service this NAPTR represents.
The application only knows that it can communicate with it
using SMTP.  IMHO, the NAPTR is at best ambiguous.  Now, if the service
field is defined as

      "E2U+srs:mailto"

The expectation is that the application will somehow negotiate with the
service using SMTP to decide on what the service will be... If both
service and protocol are a MUST, then we have reached concensus
and I have no opinion on the order.  The following ABNF reflects this
thinking:

    enum-service = "E2U" 1*( "+" uri-scheme ":" service )
    service      = "voice" / "video" / "email" / "vmail" /
                   "mms" / "sms" / "tdd" / "srs" / "fax" / extension
    uri-scheme   = "mailto" | "sip" | "h323" | extension
    extension    = ALPHA *( ALPHA / DIGIT )
    DIGIT        = %x30-39             ; 0-9
    ALPHA        = %x41-5A / %x61-7A   ; A-Z / a-z

Regards,

Bob Walter
NetNumber, Inc.

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Friday, June 28, 2002 1:36 PM
> To: [email-masked]; [email-masked]; Stastny Richard;
> Peterson, Jon; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Enum] enumservices in new version of 2916bis
>
>

---

From: Michael Mealling <[email-masked]>
Date: Fri, 28 Jun 2002 14:51:57 -0400

On Fri, Jun 28, 2002 at 02:33:03PM -0400, Robert H. Walter wrote:
> the application has no idea what type of communication service this NAPTR 
> represents.  The application only knows that it can communicate with it
> and I have no opinion on the order.  

Umm.... I'm not sure in what context you're using the string 'mailto'
here but just in case:

mailto is a URI scheme defined in RFC 2368 which only mentioned SMTP _once_
in a caveat about making sure the SMTP 'From' address is set correctly in the
message.  RFC 2368 does not define any transport system to be used. Period.
'mailto:' identifies RFC 822 addresses and messages. How you get to an
address or send a message is not defined.

Everyone: Please be _very_ careful how you use 'mailto:'. It _does NOT_
mean what you think it means simply from your usage on a web page. Please
read RFC 2368 and RFC 2396 if this is confusing....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: "Robert H. Walter" <[email-masked]>
Date: Fri, 28 Jun 2002 15:05:01 -0400

> read RFC 2368 and RFC 2396 if this is confusing....

Agreed, the uri-scheme and protocol are different things and should not
be used interchangeably...

Bob Walter
NetNumber, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 28 Jun 2002 15:42:57 -0400

A
> > using SMTP.  IMHO, the NAPTR is at best ambiguous.  Now, if the service

(Prospective Consumer hat on) " Well tough I really don't care if your 
application has a problem here thats your problem not mine." ...

Believe me I understand your technicial concern but I submit there are 
other issues involved.

What this discussion about now is consumer choice and providing the option 
NOT to reveal underling service attributes if that is the choice of the 
consumer. Which argues for protocol first everything else optional. The 
consumer _has the option_ to reveal only the minimum subset of data 
necessary to complete a connection.

Ambiguity here that is EXACTLY what I want ...the ability to 
choose.  Consumer Protection ... plus it will pass the smell test with the 
privacy community.

I know I harp on this but I really believe in this case Privacy 
Considerations are just as essential to the function and applicability of 
the protocol as Security Considerations.

> > and I have no opinion on the order.

No I have chosen  this is the way I will be communicated with and I have 
made a conscious decision NOT to reveal the underlying service.

The service logic beneath this construct basically states ..."Here..use 
SMTP or dont."  I will not reveal the underlying capabilities of this 
endpoint.

You want perfect 1:1 matching between Client Applicaiton and Service End 
Point .. I just dont think thats possible here.

>read RFC 2368 and RFC 2396 if this is confusing....

I apologize Ive gotten sucked into the problem myself ...

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 28 Jun 2002 21:21:47 +0100

>be used interchangeably...

To which I reply:
   Amen to that.

(In answer to Michael's question regarding implementing URL handlers 
...me too !)
I guess that the problem is that I'd rather like to have something 
implemented by
the end of the summer that doesn't just have SRS as the service and 
sip: as the URL.

I believe that I and everyone else here understands the difference between the
architecture and the implementation - at least the old fogeys around here
[and I still have hopes for Xanadu].

We seem to be getting to the nub here - how an end user gets to the 
resource with
which they want to communicate is not specified in the URL.

At what point did instructing the querying end user/client exactly 
how to connect
to their intended correspondent become a core part of ENUM?

In answer to the "what will it break"? question, my answer is 
"nothing, if ignored".

Those fine OS manufacturers have provided an easy API to fire up a URL handler
for "mailto:". I also have an easy API to fire up a URL handler for "tel:"
(strictly, this one's via TAPI), and for "http:", and (shortly) for "sip:".
The querying end user (or the defaults of a certain Redmond company)
configure what protocols and programs these URLs trigger.
No great pain, and we'll get something out soon.

If ENUM implementors are expected to find a way to override these 
configurations
and control the programs to run whatever protocol the registrant specifies,
we might have the trials sometime before the end of 2003.

My gripe is that, until this week's wheeze, there was none of this - it's all
new. New and "by September 2002" don't mix.

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Michael Mealling <[email-masked]>
Date: Fri, 28 Jun 2002 17:01:20 -0400

On Fri, Jun 28, 2002 at 09:21:47PM +0100, Lawrence Conroy wrote:
> implemented by the end of the summer that doesn't just have SRS as the 
> service and sip: as the URL.

Can you describe that something?

> I believe that I and everyone else here understands the difference between 
> the architecture and the implementation - at least the old fogeys around here
> resource with which they want to communicate is not specified in the URL.

Correct. It just specifies what that resource is. We still need a way
to specify what method is used to talk to it.

> how to connect to their intended correspondent become a core part of ENUM?

When it became clear that simply identifying the endpoint wasn't sufficient
for knowing how to interact with that resource since the protocol you use
to do has a large amount of impact on what services you can express for
that endpoint.

> In answer to the "what will it break"? question, my answer is 

Depending on your implementation schedule and feature list that might
be sufficient for now. I assume you'll be coming out with updates?

> Those fine OS manufacturers have provided an easy API to fire up a URL 
> handler for "mailto:". 

Sure. But on a very popular OS platform all that does is bring up the
Outlook with a few header fields filled in. You can't really use that as
a voice mail interface. I.e. if the _service_ you want is voice mail
then bringing up Outlook is probably _not_ what you wanted to happen,
regardless of whether or not there's a built in handler for the 'mailto'
scheme on that platform.

> I also have an easy API to fire up a URL handler for "tel:"

Sure. But do those APIs know what it is you're trying to _do_ with
those endpoints? 

> No great pain, and we'll get something out soon.

The Asynchronous Pluggable Protocol (bad terminology!) APIs found in 
urlmon and friends are great. But they're only half of the story. Before 
your call ever goes the actual scheme handler it goes through a 
security and caching policy filter that can determine whether or not
your 'ftp:' URL request actually gets sent to your proxy via the HTTP
protocol. If you're client has this specified then your 'sip:'
url is going to get sent to the the 'http:' handler as a proxy proccess.
So it isn't as clear cut as "Microsoft just gives me nifty APIs and that's
all I need". There are nasy side effects when you use it if you aren't
clear why your using it.

> configurations and control the programs to run whatever protocol the 
> registrant specifies, we might have the trials sometime before the 
> end of 2003.

I'm not so sure. I think we're actually converging very quickly. 
We've only been having this particular discussion for 2 days. A couple
of more and I think we'll have it...

> My gripe is that, until this week's wheeze, there was none of this - it's 
> all new. New and "by September 2002" don't mix.

Well, its a discussion that's been going on in fits and starts since
Minneapolis. IMHO, we'll get there soon. I'll do my best to get this
settled by Yokohama...

-MM