Subject: [Enum] enumservice role

From: Lawrence Conroy <[email-masked]>
Date: Sat, 25 May 2002 00:11:47 +0100

Hi Rich, Michael, Everyone,
   OK...I think I can see a certain divergence of views here.

The original 2916 view was that we use <URI-scheme> together with 
'E2U' in the NAPTR service field.

The expanded view as expressed in 2916bis has <D3SApplication> 
together with a set of <enumservice> sub-fields.
(plus the process has been formalised in the baroque magnificence of D3S).

The move that a number of folks (myself included) have been taking is 
towards a functional model rather than just a URI-scheme (or 
"protocol") model.

Rich is concerned about leakage of personal preference/capabilities 
information.
A vision of "years more suiting it around in expensive but anodyne 
International Hotels, trying to avoid cirrhosis from the boredom and 
frustration" appears before the eyes....and all to explain privacy 
concerns?

Now, Andrew comes in with what I think is a generalisation of the 
neat negotiation/redirection feature of SIP; SRS.
No folks, it's not an airbag - it's what SIP does and has always 
done. It's a Service Resolution Service.
It's also, potentially, what LPAP (& some glue) does, so the 
generalisation is fine by me.
OK - Michael calls it by the Swahili term "inquire", but it seems to 
be similar to Andrew's 'srs'.
This is a ->function<- that uses URI-schemes sip: or ldap: or ???

Yes, one can suffice with separate tokens 'sip', 'ldap', ???, each of 
which identifies the URI-scheme to be used.
This is exactly what was in 2916.
However, it does not capture the general ->function<- that is 
available at this resource identifier.

More generally, I think it quite likely that a certain Washington 
State company will have a lot of IM users.
I bet that a certain ISP/Telco with a Sun logo will expect to get 
shedloads of Voice users via its SIP service.

I also expect there to be ructions if either one or the other try to 
seal a business relationship that hides one of the identity/contact 
addresses behind the other.
I fully expect people to have at least two 'sip:' addresses, not 
because it makes any sense technically, but because a unified 
non-technical solution is just too hard, and is going to be too hard 
to explain to the generality of users.

Now to the specific...
<rant>
I want to get the schema sets nailed down. I want this done now, and 
as Richard points out, please keep it simple, folks, as there are 
several trials people would rather like to get going.

Trials means that we need something that some poor sods can 
implement. That means something syntactically unambiguous, with a 
defined state machine, and preferably not too processor or memory 
intensive. Oh, I'd also like it maintainable by mere mortals and 
possible to cross check so that the information stored is consistent. 
Here's the kicker - I'd like this to happen Real Soon Now, so the 
collected poor sods get a chance to program it and test it before it 
hits the trials users.

If not, then all that grief within the IETF and then in the ITU was a 
waste of brain power, livers, and handling some contribs from all 
over (including the US :) that has pushed stress into life-shortening 
levels - for what?

All this, just to get some URIs into a domain name space so I can map 
from an assigned E.164 number to a set of URIs.

C'mon guys...either we have schema sets with functions, or we stick with 2916.
I understand if we tag on the URI-scheme as well so that the program 
doesn't have to process the regexp to find out if it's interested in 
the NAPTR result, but the essential question sees to be simple - 
either we include the generalised function within the schema or we 
don't.

Now, if there's a privacy problem with this ->Opt-In<- service, then 
we need to find a way that a registrant can avoid putting in 
over-detailed capabilities information into the (public) DNS. I'm 
happy to have an enumservice called 'ImFeelingLucky' or 'undefined' 
for that.
However, if Joe Registrant decides that they want to tell potential 
callers that the only contact they will get using this 
address-of-record is IM, they should be able to do this, IMHO.
</rant>
Thanks - I feel sooo much better now.

Seriously, folks, let's see if we can get the "function-based" schema 
set strawman out in black and white electrons.
I understand the concerns over the role of enumservices, but let's 
split that off into a separate thread from refining the strawman.

all the best,
   Lawrence

-- 
[email-masked]: +44 1794 833666::<my opinions>:

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 25 May 2002 16:04:45 +0200

--On 2002-05-25 00.11 +0100 Lawrence Conroy <[email-masked]> wrote:

> I want to get the schema sets nailed down. I want this done now, and as
> Richard points out, please keep it simple, folks, as there are several
> trials people would rather like to get going.

As long as people don't write don't examples, there is no reason arguing.

We need examples.

I can not make sense out of the last 5-6 messages on this list, because I
don't understand what people talk about.

If you have E2U+sip+voice, you use two enumservices, sip and voice. That is
fine, but, people which suggest such things needs to describe what is meant
by "sip" and what is defined by "voice". Without that description, there is
no way we can move this discussion forward.

  paf