Subject: [Enum] Compendium on enumservices registration

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Nov 2002 17:06:31 +0100

Hi folks,
at the ENUM WG in ATL it was decided not to have the
draft-brandner-enumservices-compendium-00.txt
yet? as an Work Group Item, but continue it as individual.
 
What I have not completely understood (I am aso not a native speaker;-)
was the rationale behind this,
and I request help and advice from the list to move our work forward.
Since there were only very few comments on the list before,
it is difficult for me to get the point
 
I heard serveral different opionions, first the ones to be fixed easily:
Some said, the draft was too complicated and contained too many
enumservices in one draft. This could be fixed in splitting the
document in parts. One for each category or one for each enumservice?
 
Also the categories are not well understood. This will be fixed by
removing them e.g. talk will be removed, leaving only voice and video.
msg will be removed, leaving email, fax, sms, etc.
 
The rationale behind ivoice was not well understood. This will be fixed by
removing it, because it was mainly intended for infrastructure ENUM
purposes and could be solved there in another way also.
 
The srs enumservice caused problems. This will be fixed by removing
srs:sip and srs:h323 and reducing it to plain sip and h323, allowing
just to reference the other two drafts
 
Some others said that it was not clear wich URI-scheme to use
by "looking to the right". This will be fixed that every enumservice
will get a subtype in the format decided at the meeting, e.g email:mailto
or voice:sip, showing the URI scheme.
 
Now to the more serious issues. Many delegates raised concern about the
privacy issues and I got the impression that there is a movement within
IETF to allow only anonymous pointers in ENUM e.g.
sip:[email-masked] or sip:[email-masked]
Especially e-mail pointers where considered harmful because of spam
 
Since ENUM is an opt-in service, as defined in all policy frameworks
I currently know of, I considered this problem dealt with.
 
Also in the privacy draft from Rich the alternative views of ENUM are
stated, so I considered this problem solved.
I definitely agree that both called and calling party control is useful,
and I also agree, coming originally from the UPT and UCI side, that the called
party control is favorable if ALL communication to an person, entity or role can
be done via one identifier. But as long as this is not possible, we have to provide the
calling party control in addition, to allow the customer to add other information and also
to be open for additional, currently only envisaged or even unknown services.
 
I also consider ENUM as very useful for enterprise use, and companies do not
have a privacy problem at all.
 
There is another problem: we modelled our proposal according to
RFC2916bis and especially after the examples given there, and so did the rest
of the standardisation community in ITU and ETSI, dealing with administrative and
provisioning issues, and so did the various trial platforms.
 
Citation from RFC2916bis:
 
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). 
---
   Specifically, a registered Enumservice MUST specify the URI scheme(s)
   that may be used for the Enumservice, and, when needed, other
   information which will have to be transfered into the URI resolution
   process itself (LDAP DNs, transferring of the AUS into the resulting
   URI, etc).
 -----

$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
     IN NAPTR  10 10 "u" "E2U+talk:sip+message:sip" "!^.*$!sip:[email-masked]!"    .
     IN NAPTR 102 10 "u" "E2U+message:mailto"       "!^.*$!mailto:[email-masked]!" .
     IN NAPTR 102 10 "u" "E2U+talk:tel"             "!^(.*$)$!tel:\1!"          
 
end of citation
 
If the above view that 
IETF tends to allow only anonymous pointers in ENUM e.g.
sip:[email-masked] or sip:[email-masked]
AND
especially that e-mail pointer are considered harmful.
is true than RFC2916bis is broken, because the above
view has to be stated clearly and the examples are
seriously and dangerously misleading.
 
BTW, I will not have any problem putting my name, e-mail address and
even may street address in ENUM, because the same information is
in listed in the phone directory (public on the Internet). And this information
can be retrieved also by number.
 
But there is no hint to my occuppation and my buying preference or income.
But where I may have concerns in future is giving my e-mail to standard bodies
in drafts and mail archives, because since I am working e.g. on IETF issues, my spam
e-mails have increased dramatically;-)
 
best regards
awaiting your comments
Richard Stastny
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 20 Nov 2002 12:40:49 -0500

Richard,

> in listed in the phone directory (public on the Internet).
> And this information can be retrieved also by number.

Could you do me a favor and explain what this means to you?

Opinion 5/2000 on The Use of Public Directories for Reverse or
Multi-criteria Searching Services (Reverse Directories) 

The url (auf deutsch) is 
http://europa.eu.int/comm/internal_market/en/dataprot/wpdocs/wp33de.pdf

Eric