Subject: RE: [Enum] SchemaSet strawman Proposal

From: "Stastny, Richard" <[email-masked]>
Date: Wed, 29 May 2002 09:41:09 +0200

Rich wrote:

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Tuesday, May 28, 2002 5:22 PM
> To: Stastny, Richard; [email-masked]
> Subject: RE: [Enum] SchemaSet strawman
>  
> I still do not see the operational difference between the construct 
> 'E2U-smtp+faxs' and 'E2U+smtpfaxs.  Why is one easier for 
> devices or user 
> agents to process than the other? Both can define exactly the 
> same thing if 
> they are properly defined and documented.
> 
> Richard ..I really am trying to understand this ...

To which I reply:

Rich, I think we are at the point now. I also agree, that there is no
operational difference, if we use either 'E2U-smtp+faxs' and 'E2U+smtpfaxs
;-)

But can we agree, that we both want a combination of URI and "service". I
could live with your proposal, if we use only combinations of ONE URI (of
course) and ONE "service". That means, that combinations of 'telvoicefaxsms'
or 'telvoicefax' or 'telvoicesms' are not used.

So my proposed NAPTR for a tel: URI
NAPTR blabla "E2U-tel+voice+fax+sms" blabla tel:+4317978032

would now look, according to your proposal:
NAPTR blabla "E2U+telvoice+telfax+telsms" blabla tel:+431797832

or (according to Patrik?) be three NAPTRs:
NAPTR blabla "E2U+telvoice" blabla tel:+4317978032
NAPTR blabla "E2U+telfax" blabla tel:+4317978032
NAPTR blabla "E2U+telsms" blabla tel:+4317978032

I also propose again, to do the templates per group of services related to
one URI, so all valid (and at the time known) combinations of telxxx,
sipxxx, h323xxx, mailtoxxx will be defined in a template each.

There is still some problems to be discussed:
1. What to do with plain URI enumservices, like sip, mailto, etc. where I do
not need an additional service listed. Since (according to Patrik) the same
characters should not be used, we are stuck here. Or the other way round,
what is the default? Is it sip, sip* or sipany

2. The second problem is concerning your "creative" services, as you stated
in your reply to Clive:
>What is the conflict with this  .. this is actually a really good example 
>of a very creative service !!  The only way I prefer you to reach my mobile

>SMS end point is to use a SMTP gateway where I could a apply a spam filter 
>...I like this one !!  I'll buy this!!!
I agree, that we may come up here with some nice services, but you should
consider here, that if the user wants to send an sms, he has his sms
application launched and is entering a phone number +431... in the To:
field. 

So the application is first looking for something like 'foosms' and normally
will find something like 'telsms'. If there is an entry 'mailtosms' or
'smtpsms', this would mean, that an e-mail client is needed also. If you now
consider all potential new services, we again have a lot of templates to
define.

Although this well be a nice exercise, I would prefer (keeping the trials in
mind), that we first do the basics.

Best regards
Richard

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 29 May 2002 10:49:33 +0200

--On 2002-05-29 09.41 +0200 "Stastny, Richard" <[email-masked]>
wrote:

> Since (according to Patrik) the same
> characters should not be used, we are stuck here.

Please read my mail again.

I said people should in this discussion use different characters, because
the name of the enumservice have _nothing_ to do with the characters in the
URI scheme.

What URI scheme(s) a specific NAPTR is tied to is specified by the
specification of the enumservice. Not by what characters are in the
enumservice itself.

   paf

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 29 May 2002 10:54:14 +0100

>specification of the enumservice. Not by what characters are in the

Dear Patrik,
  I have read your emails. I have looked back through these threads,
and don't see any clear pattern.
  I'm happy putting 'pis' instead of 'sip', or 'tjq', if it's the tag for
an enumservice; I would prefer 'srs', but that's in the strawman already.

Way back, I (and others) proposed having a set of "enumservices" that
would NOT be tied to individual URI-schemes. This is the "high level
functions" of the strawman.
Each defining draft would include a list of the URIs that could be used
with that enumservice, and how these URIs could be used.

I understood your position was that this was not acceptable, as the client
would not be able to select exactly what they had to do (and the program
they had to run) without rexexp-processing to get the URI.

I took this to mean that you wanted also to include the URI-scheme
(note - completely distinct from the enumservice list) in the NAPTR
service field, AS WELL AS the enumservice list, as the service field
is all the client has to help select between NAPTRs (at least for
non-terminals).

Now it appears that we are NOT to put the URI-scheme into the NAPTR
service field. Fine.

Are we now back to the strawman list, or if not, ->why<- not?

all the best
   Lawrence

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