Subject: RE: [Enum] SchemaSet strawman Proposal

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 30 May 2002 15:29:53 +0200

Clive said:
> Lawrence Conroy said:
> >> this can be arranged .....  I think we are pretty close to 
> consensus 
> >> here
> > Actually, I have yet to see a rationale for this decision 
> so I'm not 
> > sure that this dazed feeling of being clubbed into submission is 
> > consensus.
> 
> I have to agree - I don't see consensus. I don't even see a 
> solid understandable proposal that consensus might happen around.
> 

Maybe one reason that there is no proposals around yet is, that nobody wants
to put an effort into this, before he sees the main direction to go.

There have been at least two (three) proposals on the list, but most
responses where not constructive like: in priciple yes, but have you
considered that also, or yes, but this a want different, etc.

Most responses where destructive: No, I do not like this, this does not
work, etc.

Lets try again:

Currently three variants of enumservices definitions are under discussion:

Variant 1: Same name as URI e.g.:
sip, mailto, tel, as in the examples in RFC2916bis.
Note: causes problems with URIs with multiple use (e.g. tel:)

Variant 2: Generic grouping (strawman) e.g.: 

talk (former tel)	or rtc (real-time communications), all voice and
video
msg			Message, all mail, fax, sms, etc
info			or file (all http, ftp and document retrieval)
srs (former sip)	Service Resolution Service (srs)
streaming		for broadcast of audio and video
pres			presence, location (GPS coordinates of company)
key			for public keys (just created this one)
Chat			or included in rtc
any			for complete forwarding of ENUM domain

This solution requires peek-ahead into the URI and svc, but as already
stated by Rudi and Clive, this should be a problem and reduces the number of
NAPTR, which may be more advantage. The related URIs have already be listed
by Lawrence

Variant 3: Combination of URI and Service e.g.:

mailto, telvoice, telfax, telsms, sipvoice, h323voice, http, https, enum,
etc.

The advantage of this proposal is, that the functionality is nearly
selfexplaining. This is BTW the initial list of URIs and services used for
our trial. I consider variant 2 more elegant, but could live (at least for
the trial) also with this variant.

Some additional comments:

The enumservice enum may be used to forward all services of a given E.164
number to another E.164 number (instead of using CNAME, which may case
problems in general and also within the DDDS algorithm).

This service requires a new URI "enum:" to be defined. It should be noted,
that this new URI may also be convenient for usage to trigger an ENUM query
from a link in a web-page or document (e.g. in an e-mail signature).

The new URI has the format enum:+431... and shall trigger the launch of an
ENUM application able to query the DNS and giving back all information
stored under this number.

First, are there other proposals?
If yes, show the at least in principle
If not, could we agree that the final solution is one of the three variant
and maybe vote, which one is preferred. 

If one or two variants are left over to be considered seriously, I could
imagine, that one or two drafts still can be created for Yokohama,
containing "solid understandable proposals".

Best regards
Richard

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