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

From: "Robert H. Walter" <[email-masked]>
Date: Mon, 1 Jul 2002 09:49:32 -0400

Rudolf,

The [] around the enumservice production are unnecessary since *()
already specifies that there are to be zero or more.  Using formal
ABNF, I'm assuming that you actually mean the following:

servicefield = "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo]

Can you provide the complete ABNF defining the uri-scheme, enumservice
and addinfo productions?  In particular what is addinfo and how is it
to be used?

Thank you,

Bob Walter
NetNumber, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brandner Rudolf
> Sent: Friday, June 28, 2002 10:19 PM
> To: 'Michael Mealling'; CONROY LAWRENCE
> Cc: [email-masked]; [email-masked]
> Subject: AW: [Enum] enumservices in new version of 2916bis
>
>
> Hi all,
>
> I'd like to come back to the very pressing issue: enumservice field
> structure. I'm with Richard Stastny on this: we really need to sort this
> out. Thus I'd like to ask whether we do have a (rough) consensus on
>      servicefield = "E2U" ("-" <uri-scheme>) [*("+"
> <enumservice/category>)] ["*" <addinfo>]
> or not.
>
> [note: I think I've got the addinfo right now. If not, please let me know.]
>
> And yes, I agree that we will have to be very clear about addinfo being optional.
>
> Now on to the thread of protocols and APIs:
>
> > -----Ursprüngliche Nachricht-----
> > Von: Michael Mealling [mailto:[email-masked]]
> > Gesendet: Freitag, 28. Juni 2002 23:01
> > An: Lawrence Conroy
> > Cc: [email-masked]; Michael Mealling; [email-masked]
> > Betreff: Re: [Enum] enumservices in new version of 2916bis
> >
> >
> > On Fri, Jun 28, 2002 at 09:21:47PM +0100, Lawrence Conroy wrote:
> > > At 3:05 pm -0400 28/6/02, Robert H. Walter wrote:
> > > > > 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....
> > > >
> > > >Agreed, the uri-scheme and protocol are different things
> > and should not
> > > >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.
> >
> > Can you describe that something?
> >
>
> Hmmm, I'm not sure, whether this discussion is helpful on our main issue:
> enumservice field structure.
>
>
> > > 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.
> >
> > Correct. It just specifies what that resource is. We still need a way
> > to specify what method is used to talk to it.
> >
>
> Sorry, but I think no, we don't as far as protocols are concerned.
>
> Today, I can send an SMS to an e-mail address. My mobile phone might not
> get a very popular e-mail client any time soon, but it might get
> ENUM-enabled. If my mobile phone gets a mailto: it might fire up the SMS UI
> to enter the message, prepends the e-mail address and sends it to a gateway
> of choice, which forwards it as an e-mail to the reciepient.
>
> If you are going to specify protocols here you are opening a whole new can
> of worms. The only thing I need to know is how the receiving end can be
> reached. How the communication is started with is a complete different
> story. For instance, if you are specifying SMTP as the protocol of choice,
> I won't be able to send a message to an e-mail address from my mobile phone
> any more until it get's STMP or at least an e-mail client.
>
> > > At what point did instructing the querying end user/client exactly
> > > 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.
> >
>
> Define a default behaviour of the client for a default protocol. However,
> the protocol used at the recieving side does not necessarily be the same as
> on the sender side. ENUM is about how a recieving side can be contacted.
>
>
> > > In answer to the "what will it break"? question, my answer is
> > > "nothing, if ignored".
> >
> > Depending on your implementation schedule and feature list that might
> > be sufficient for now. I assume you'll be coming out with updates?
> >
>
> You're not? (sorry, couldn't resist ;^)
>
> > > 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.
> >
>
> As for that very popular OS platform: is it ENUM enabled?
>
> If you are looking for a vmail service and start an application which is
> not capable of dealing with voice.... er... what's wrong here?
>
> Maybe there need to be some application to glue together. In this
> particular case, looking for a vmail it might be of help first start some
> voice recording software and then send it using that very popular mailer
> until that very popular software company gets its very popular mailer ENUM-enabled.
>
> > > 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:".
> >
> > Sure. But do those APIs know what it is you're trying to _do_ with
> > those endpoints?
> >
>
> Maybe I am off some miles here, but I think that the APIs do not need to
> know. An ENUM client software should know about the features ENUM enables
> and start the appropriate pieces of software already being there.
>
>
> > > 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.
> >
> > 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.
> >
>
> Is Microsoft's software ENUM enabled already? If not, maybe they just up
> the ante in changing APIs and their semantics a little bit.......
>
> Sorry for being somehow sarcastic here. I see that there are problems with
> actual APIs. However, I do not see any immediate link to the enumservice
> field. The trials will show how easy or complicated it is to implement
> useful ENUM clients. APIs might change after getting some experice.
>
> > > 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.
> >
> > 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...
> >
>
> I'm with you here.
>
> .... and if not, I suggest that we discuss this in Yokohama over a beer or two.....
>
>
> Rudi
> ------[snipp]-----
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 02 Jul 2002 14:08:58 +0200

> and addinfo productions?  In particular what is addinfo and how is it

This is what I wrote in the new draft which you might have seen by now.

I.e. I am not claiming what I wrote is what we finally should use, but,
this is what I wrote in what we will discuss in Yokohama:

                    service_field = "E2U" 1*(enumservice)
                    enumservice   = service [":" protocol]
                    service       = 1*32(ALPHA / DIGIT)
                    protocol      = 1*32(ALPHA / DIGIT)

     paf

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 2 Jul 2002 13:53:40 +0100

>                     protocol      = 1*32(ALPHA / DIGIT)

Hi Folks,
  obviously we have a meeting of minds.

Two questions::

Is there intended to be a white space or some punctuation between the "E2U"
and the start of the enumservice list?

Is there intended to be white space around the enumservice elements,
or is it intended as a comma-separated list, or do we just run them together?

I repeat my comment that I do not think that a protocol or protocol 
set is needed
to return a URI, nor to select between a group of URLs, each held in 
a separate NAPTR.

For this a service or set of services is needed to show the user 
intent; how that
intent is executed is a combination of the end user system policy and 
the URL field.

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

---

From: Michael Mealling <[email-masked]>
Date: Tue, 2 Jul 2002 10:05:18 -0400

>                     protocol      = 1*32(ALPHA / DIGIT)

Which also includes the fact that both 'service' and 'protocol' are IANA
registered items that point to documentation about what they mean, right?
So the 'protocol' registration can specify a) what transport protocol
you're talking about and b) what URI schemes are valid for it. Thus, 
the 'sip' protocol can say that only 'sip:' URI schems are valid for it.

-MM

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 02 Jul 2002 19:20:04 +0200

--On 2002-07-02 13.53 +0100 Lawrence Conroy <[email-masked]> wrote:

> Is there intended to be a white space or some punctuation between the
> "E2U" and the start of the enumservice list?

Mea culpa. Mea maxima culpa.

There should be a '+' there.

Correct grammar should have been:

                    service_field = "E2U" 1*("+" enumservice)
                    enumservice   = service [":" protocol]
                    service       = 1*32(ALPHA / DIGIT)
                    protocol      = 1*32(ALPHA / DIGIT)

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 03 Jul 2002 11:00:24 +0200

> registered items that point to documentation about what they mean, right?

The _combination_ of service and protocol must be described somewhere.

> the 'sip' protocol can say that only 'sip:' URI schems are valid for it.

I don't care what the 'protocol' specifies. My view (after reading the
discussions on this list) is that what it actually specifies differ between
different usages.

It is a placeholder for a subtype of "service".

   paf