Subject: [Enum] Regarding brandner-compendium discussion in ATL

From: "Stastny Richard" <[email-masked]>
Date: Fri, 8 Nov 2002 13:17:29 +0100

Hi all,

Now that the SIP and H323 enumservice drafts are published
<http://www.ietf.org/internet-drafts/draft-peterson-enum-sip-00.txt>
<http://www.ietf.org/internet-drafts/ draft-levin-enum-h323-00.txt>
we need to update the "compendium" draft.

Since both are describing enum services equivalent to the srs 
categorical enumservice, I propose to align the three IDs by changing 
the following sections of the 
<http://www.ietf.org/internet-drafts/draft-brandner-enumservices-compend
ium-00.txt>
as follows:

-begin-
19.  srs categorical enumservice
19.1. Description
This category is used where the Registrant wants to use a specialised 
"Service Resolution Service" above and beyond ENUM. It can be used 
where the services available depend on factors that cannot be covered 
in the global ENUM system; for example, the services "advertised" may 
depend on the person asking, and so requires authentication to be 
performed before any detailed information is returned.

19.2. Comprised Services 
This category comprises THREE main services; dap, H323 and 
sip. Of these, the 'sip' service AND H323 has a rich feature sets and 
will be described in a separate documents.

19.3. Expected Client Behaviour
If the end user has selected this as an "enumservice of interest" then
the client should filter out all NAPTRs but those containing either the
'srs', 'sip', 'H323' or 'dap' tags, together with any NAPTRs showing the
'all'
category and where the processed URIs indicate either "sip:", "H323" 
or "ldap:".

If the Registrant has chosen to include only a NAPTR with either the
'srs'
tag or that of one if its constituent enumservices, then the client can
either initiate the "next stage" of service resolution directly, or
report
that this is required and await the end user's response.
In either case, this is the end of ENUM processing; further evaluation
continues using the features of the constructed URI.

19.4. Associated URIs
At present, there are expected to be THREE URIs that can be associated
with
this category; "sip:", *H323" and "ldap:".
-end-

If there is any additional commments please let me know asap.

In addition, I would like to mention, that the enumservices according 
the the draft-brandner-enumservices-compendium-00.txt
have been implemented sucessfully in the Austrian ENUM Trial and the 
clients provided to the users. The trial is in operation since one 
month.

Interested parties are invited to contact me for a demo in Atlanta and 
also may be provided with links download different available clients.

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

---

From: Richard Shockey <[email-masked]>
Date: Thu, 14 Nov 2002 13:17:10 -0500

A.

>will be described in a separate documents.

why cant you just call dap  ldap? and I object to this concept _at this 
time_  since we have no formal protocol definition or schema or how LDAP 
might be used as a service resolution service.

We have H.323 and SIP ... that seems fine for now.

I'm not saying LDAP might not be useful if there was a formal definition, 
but I would then suggest an appropriate the enumservice tag would be

E2U+ldap:srs

>If the Registrant has chosen to include only a NAPTR with either the

You are not suggesting

E2U+sip:srs     are you ...

or E2U+h323:srs   ? why is this necessary? IMHO its self explanatory and 
redundant...its is the called parties proxy that will determine what and if 
any response is necessary.

>continues using the features of the constructed URI.

ok

>this category; "sip:", *H323" and "ldap:".

again since the LDAP concept is not defined it is not appropriate to put a 
place holder here.

>If there is any additional commments please let me know asap.

I wish we could sepererate the issues here into services and descriptions 
of services.

What we will have is

E2U+sip
E2U+h323

what we will have shortly are probably

E2U+fax  and

E2U+vpim

The enumservice names in the compendium are 'talk', 'voice', 'ivoice', 
'video', 'msg',
'fax', 'sms', 'ems', 'mms', 'email', 'chat', 'tp', 'im', 'info', 'web',
'ft', 'srs', and 'all'

IMHO

the general case is

E2U+enumservice:enumdescription1:enumdescription2:etc  where 
enumdescription is purely optional on the part of the ENUM registrant

E2U+voice:sip            is not acceptable

E2U+sip:voice             where "voice" is purely optional is.

or

E2U+sip:voice:home        where "voice" and "home" are purely optional to 
the registrant if they are a real estate sales person ..

E2U+sip:video                 may ..may make sense is certain cases..

I still do not understand the difference between "talk" and "voice" and 
"ivoice"

I do not understand the difference between "chat" and "im"

E2U+tel:fax                       makes sense, a PSTN fax call ..

E2U+tel:mobile:sms           makes sense ..

E2U+tel:textphone             seems very useful.

etc

I know you are not going to like this but I'm suggesting this is a 
direction we need to consider for this draft.

>also may be provided with links download different available clients.

Folks on the list ...this is a very useful and interesting client that 
Telecom Austria and Infonova have produced .. I suggest it is worth 
investigating.  It help clarifies some of the rationale embodied within the 
compendium draft by seeing how enumservice description can be used ..I've 
been playing with it myself.

do mail Richard if you are interested.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
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: "Stastny Richard" <[email-masked]>
Date: Fri, 15 Nov 2002 12:19:03 +0100

He, he, Rich
I think this discussion is a bit getting out of hand:

service, enumservice, protocol, URI, ...
Now I am totally confused.

>E2U+sip:voice             where "voice" is purely optional is.

So you do not accept the current version of 2916bis-01
which says:

-begin-

2.4.2 Services Parameters

   Service Parameters for this Application take the following form and
   are found in the Service field of the NAPTR record.

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

   In other words, a non-optional "E2U" (used to denote ENUM only
   Rewrite Rules in order to mitigate record collisions) followed by 1
   or more or more Enumservices which indicate what class of
   functionality a given end point offers.  Each Enumservice is
   indicated by an initial '+' character.

   The empty string is also valid.  This will typically be seen at the
   beginning of a series of Rules, when it is impossible to know what
   services and protocols will be offered at the end of a particular
   delegation path.

2.4.2.1 ENUM Services

   An enumservice MUST be registered with the IANA via a description in
   an RFC.  Enumservices specifications contain the functional
   specification (i.e.  what it can be used for), the valid protocols,
   and the URI schemes that may be returned.  Note that there is no
   implicit mapping between the textual string "protocol" and "service"
   in the grammar for the Enumserver and URI schemes.  The mapping have
   to be made explicit in the specification for the Enumservice itself.
   It is allowed to specify the service and protocol in two different
   documents, to make the description coherent and easy to understand.
   For example, the Enumservice "presence" (note, no protocol
   specification) would define the various URI schemes ("im:",
   "mailto:") can be used and what the service can be used for ("Where
   is the owner of this E.164 number?").  Another example might be
   "talk:sip" which can specify that the URI must use the 'sip:' URI
   scheme and use the SIP protocol to make a voice call (as opposed to a
   voice mail call or fax call).  What final protocol to use for the
   actual transport of voice is negotiated in the SIP protocol
   negotiation.
-end-

so talk:sip IS ACCEPTABLE - period (and so is voice:sip, which is nearly
the same)

We have made for our trial four basic decisions:

1. it is based on RFC2916bis
2. we go for the calling party controls approach (see your own draft
on privacy) including the called party approach automatically
3. We used the brandner-compendium for enumservices (selection), because
it is the only one available
4. We do not use at the moment the optional ":protocol" field, because
we look at the "right"

To this some comments:
on 2: We see both calling and called party control approach to be
requested
by the user, it is their decision. The called party control is a subset
and
included automatically, but currently there is NO full srs:sip or
srs:h323 
available to offer to trial users (we are still struggling to offer them
voice:sip and voice:h323, but we do;-). Additionally, there will always
be new enumservices
possible in addition to sip, so we see for a long time a combination of
the two approaches e.g. srs:sip and key:ldap or location:foo
And finally, as I have told you already, we want to find out what the
ENUM users and ENUM subscribers really prefer, so we offer both options.

on 3: as I have stated in a previous mail, we have no problem to
incorporate
the two drafts on sip and h323.

on 4. Currently we are using e.g. "E2U+voice" or "E2U+sms" or "E2U+srs"
and it works
but we can easily also use "E2U+voice:sip", "E2U+sms:tel",
"E2U+srs:sip", if required.
Or lets say, it does not hurt, because it is optional;-)
We also may easily understand "E2U+sip", which is equivalent to
"E2U+srs" with sip: URI

BTW, where did you get

>E2U+tel:mobile:sms           makes sense ..

from?

We use E2U+sms with a tel: URI which may be fixed or mobile.

The idea in an earlier draft with home, mobile etc was, that if
a user wants to point to different voice options to give hints
to the caller (in the calling party controls scenario). But we
do not use this at the moment.

Rich says:
>you are not accommodating the requirements of the called party here.. I

>want to make it abundantly clear my position... it is the called party
that 
>is in control here of the entire process..what the calling party wants
is 
>frankly irrlevant. It is the called party that must register their 
>preferences in the global DNS and how they choose to expose data is
IMHO 
>the primary consideration.

This is only one possibility. Again: read your own draft on privacy;-)

Now we are coming to the serious stuff:

Lawrence:
>This is going to need some spec to ensure that the Client and 
>publisher/Registrant both use a common set of values.

Rich: exactly

Rich again: the behavior of your client is of no concern to the WG

What is the concern of the WG?

I always thought the concern of the IETF and therefor also for the ENUM
WG 
is standardization for interoperability.

The statement from Lawrence comes out from the key point of the current
work going on in ETSI on "Minimum requirements for interoprability
of the European ENUM Trials". And the key point is: If I set up a trial
in UK with ENUM subscribers entering their data in an UK Tier 2 and also

provide ENUM users in UK with clients, this will work, because the
enumservices 
and URI to be used with this enumservices are defined within the trial.
I did the same in Austria. Now a ENUM user in Austria wants to query the

UK tier 2 or vice versa.

Since NOTHING is defined yet by ENUM WG, and we cannot just reference
some RFCs, the chances are high that the
definitions in UK do not match the definitions in Austria, or Sweden, or
Netherland or Switzerland, except they talk to each other beforehand.
This is exactly whats going on in ETSI, and the only reference we
currently
have is the RFC2916bis and the brandner-compendium, and we want to have
a quite stable draft to work on in Dezember and finalize it in January.

Sorry, but EU is not US and we still have diffenent countries (and 
we have trials).

Now I come to the fun stuff:

I have to admit beforehand that although I am around now for years
in this business, I still have no sufficent definition found for
service.

The result in YOK regarding this issue was foo, eventually with bar.

From RFC2916bis again:
Note that there is no
implicit mapping between the textual string "protocol" and "service"
in the grammar for the Enumserver (should read emumservice) and URI
schemes.

But Rich seems to know (This is what I grabbed from your last e-mail):

-begin Rich on services, protocols, etc.-

In my humble view ldap is the service and srs is the description of the 
service..that was my point.

I will oppose this. SIP is the service... IMHO it needs no additional 
embellishment. a description possibly..

well the service may represent a protocol but I'm willing to admit hints
to 
the capability of the end points to permit calling parties a choice of 
endpoints. You continue to avoid my points here.

point well taken .. I was thinking that if someone wanted to send me a
fax 
and the only methodology I permitted was PSTN G3 then the construct made

sense in the context of called party control...but realistically this
could 
be done through SIP as well

tel is the service sms is the  capability or application of the
endpoint.
-end Rich-

The last one is the best, this throws me off completely:
tel is now a service and we have two new terms: capability and
application.

I really waited for this to to come up. We had this fun already in
TIPHON:
If you try to defines service, you finally run into a dead end, turn
tree
times around and emerge with terms like capability, service capability,
application,
application service, service application, application service
capability, category,
service categories, features, supplementary services (hoppla, thats an
old one). 
And this is the end of dicussion, because everybody is totally
confused and does not know what others are taking about.

So we are now talking about enumservices, services, categories,
protocols, URIs,
capabilities and applications. Nice, do we still know what we are
talking about?

Ok Rich, I have to admit that you also finally recognized that there is
a problem:

Rich says:
>This is the issue .. in the draft the relationship between service
needed 
>and enumservice aka protocol is not clear. I hope to see clarification
and 
>direction of where Patrik and Michael are going at this point.

Good luck;-)

May I help:

What we have is RFC2916bis, the brandner-compendium and the sip and h323
drafts.

RFC2916bis uses the terms enumservices and protocol,
but state clearly, that they do not mean anything in itself, but the
meaning needs 
to be defined in a specification, and the "protocol" part is optional.

The brandner-compendium is doing exactly this for a bunch of
enumservices,
it defines what the enumservices are for and which URI (and real
protocols)
may be used. The compendium also groups the enumservices that have
something
in common into groups, giving these groups also a name and a definition
to be used
as enumservice (e.g. msg for all type of non-session related
communication).

The compendium also allows the URI used in the regexp to be mapped to
the "protocol" as an option, although the URI may not be a real
protocol.

To prevent confusion between the enumservices and protocol names, we
tried
to use different names, and since the names to be used in the protocol
part
are predefined by the URIs, we had to chose other names for the
enumservices
(which was not so easy and led to some counterintuitve solutions (like
dap).

This even works for sip and h323 if used as "Service Resolution
Services"
in the form NAPTR "E2U+srs" .. sip:[email-masked], but since we did
not use sip and
h323 as enumservices sofar, we can live with srs as category and sip,
h323 as subcategory
also.

So we may have in parallel:

"E2U+voice" with either sip: h323: or tel: for voice only
(note that tel: may use either a sip or h323 client to establish the
call)
(and also note that "E2U+voice:sip", "E2U+voice:h323" and
"E2U+voice:tel" are
also possible)

and
"E2U+srs" .. with either sip: or h323:
and
"E2U+srs:sip" or "E2U+sip" , which are equivalent.

So IMHO the brandner-compendium is a very generic approach for all types
of usages in ENUM (it will also work for infrstructure ENUM) and also
open for additional services, as has been seen with sip and h323 and 
I am sure this will also work with vpim and fax.

One last word: we should not try to define the enumservices
for what we (personally) think ENUM shall be used for,
but should allow all thinkable usages.

We should only try to enable this usages in a compatible way
and let the implementors of services (aaagrh), subscribers and 
users decide.

One example:
If a ENUM subsciber decides to put a pointer
to his name and address in ENUM, he should be able
to do this (yes, I know, we have to let him fill out
several form where he is declaring that he exactly knows
what he he doing and that there is the possibility that
Bin-Laden may scan the DNS and sent him an airplane ..)

On the other hand, 95% of our phone customes are in the
phone book with their name and address. And companies in
general have no problem to put their names, addresses and 
geolocs and whatever in public (and if, the address is on cayman
island anyway).

If you are trying to prevent this beforehand, you are worse
than some of the regulators and the privacy gurus, who all
think everybody is completely nuts anyway and they are not and therefor
they are the ones who have to do the thinking for the nuts.

BTW, two days ago I saw a demo of an ENUM application, where
the phone number in ENUM was put in a bar code, put on a business card
(or a letter) and was read with a bar code reader connected to a Laptop,
which triggered an ENUM query. 

And also BTW, postal services have already shown
intest in GLOBALLY unique numbers for people or entities, if you know
what I mean.

I think we still cannot imagine all the applications possible
with ENUM and I want to be open on all sides

Best regards
Richard (Stastny)

---

From: Richard Shockey <[email-masked]>
Date: Fri, 15 Nov 2002 14:03:43 -0500

>Now I am totally confused.

You too? :-)

>                     protocol      = 1*32(ALPHA / DIGIT)

Yes ... I understand what you are getting at ..and Yes I think this 
definition needs to be refined so there is no ambiguity in what is 
permissible ... what is a required field and what is a protocol field.

I think it would be terrible to have

E2U+voice:sip and

E2U+sip    and or

E2U+sip:voice

I just think it would be way too difficult for applications to parse correctly

>so talk:sip IS ACCEPTABLE - period (and so is voice:sip, which is nearly

and confusing under the current definition but we  have a draft that says

E2U+sip is also acceptable and there are lots of folks who want this and 
nothing else.

>1. it is based on RFC2916bis

a work in progress remember.....

>on privacy) including the called party approach automatically

how do you define this?  could you please elaborate ..

>4. We do not use at the moment the optional ":protocol" field, because

ok ...

>included automatically, but currently there is NO full srs:sip or

ok <sigh>

>ENUM users and ENUM subscribers really prefer, so we offer both options.

of course ...

>the two drafts on sip and h323.

I'm wondering how you plan on harmonizing them...you want to incorporate 
the directly into your draft ..?

You then object to having them move forward individually>

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 15 Nov 2002 22:10:54 +0100

>them directly into your draft ..?
>You then object to having them move forward individually

No , (I am speaking now as co-author without consulting), 

I personally consider the draft partially as framework and

already complicated enough. For srs (sip, h323) we do not

much elaborate and leave the details to the experts. The enumservices srs and h323

just plug in, and they should move forward individually.

So it is definitely not an question of compendium or sip (h323), its both.

Maybe this can be stated in a new version more clearly, when

we just can put in a reference. The same should be the case with section 15. im

(instant messaging). This should be done by the specialists. A lot of work

will also be required with ldap.

Additional enumservices may be added later to this framework, e.g. the

public key and location services (capabilities?) we already discussed., eventually

also in separate documents.

regards

Richard Stastny