Subject: RE: [Enum] SchemaSet strawman Proposal

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

Patrik wrote:

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]] 
> Sent: Wednesday, May 29, 2002 10:50 AM
> To: Stastny, Richard; 'Richard Shockey'; Stastny, Richard; 
> [email-masked]
> Subject: RE: [Enum] SchemaSet strawman Proposal
>  
> --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 am reading your e-mails always at least twice anway ;-)
> 
> 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.

I fully agree with you, that the enumservice is something different to the
URI used AND also to the services provided with a certain URI. This was also
the reason, why Lawrence used in his proposal for the generic enumservices
'names' different from both, e.g. talk for the enumservices related to the
URIs sip, tel, h323 and the services voice and video, and 'message' for
enumservice related to the URIs mailto: and tel: and the services mail, fax,
sms, etc.

It took me some time to understand this, and if you consider other people
out there not so involved in the details, but interested in ENUM, we should
try to avoid such pitfalls by using clearer definitions and giving some more
explanations.

> 
> 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.

Agreed too, but to avoid duplicate work, the ENUM WG should come up with a
clear generic scheme how to define enumservices. There should be a common
practice and some guidance. 

One example could be my proposal, as already sent in response to Rich:

1. Group the templates around a URI.
2. Use as a memnonic for the enumservice the URI and one service

Note: In this case the memnonoc for the enumservice is in most case
selfexpaining.

So a basic group of enumservices for tel could be:
tel, telvoice, telfax, telsms, telmms, telems, telrn, telcic, teldn, ...
Others may be added later, e.g. telmail (you may leave a message and it is
sent with voicemail (a Shockey feature)

Another enumservice group for mailto could be:
mailto, mailtosms, mailtofax (to keep Rich happy, this means: if you want to
send a fax, mail it), etc.

So for a simple ENUM trial, we may start with:
telvoice, telfax, telsms, sipvoice, h323voice, http, https, mailto

And I can also explain the functions. The only thing is, I want to have the
clients operational in September (2002).

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 14:04:03 +0200

> I am reading your e-mails always at least twice anway ;-)

Sorry about that....my fault for not being able to express myself.

  paf

---

From: Richard Shockey <[email-masked]>
Date: Wed, 29 May 2002 12:49:13 -0400

>try to avoid such pitfalls by using clearer definitions and giving some more

I certainly see this ..there was a lot of confusion caused mixing and 
matching URI schemes and definition of services. I can see now that your 
and Larry's preference was to have a bit more structure to the enumservice 
label construct that would clearly hint at the URI during the first order 
processing when all the NAPTR records are returned .... where as I think 
Patrik and myself were thinking .. well ..so what, the key is properly 
defining and documenting the enumservice label so when the client 
application sees E2U+fooservice it knows exactly what URI and application 
to expect.

>practice and some guidance.

I would not say "clear generic scheme"  ..clear documentation for a 
specific label.

yes ... but the clear difference has been your preference for a "URI hint 
[some character] service" vs my general theory of a simple 'label' that 
contains that information in a documented RFC. The label could therefore be 
anything

  In my way of thinking you could define a enumservice with the name 
"bubblebath" for a form of FTP and document that in a RFC and it would have 
the same meaning as "ftpfoobar" What you want is what you are stating below 
that there should be some general structure to the label in order for it to 
be more clearly read and understood.

>Note: In this case the memnonoc for the enumservice is in most case

YES   this is what I would call a label... creation of a simple mnemonic 
that can be documented to describe a unique and discrete service(s).

>tel, telvoice, telfax, telsms, telmms, telems, telrn, telcic, teldn, ...

You could certainly bunch these into a single RFC  ....

>send a fax, mail it), etc.

yep something like a mailtofax would be the kind of label that would be 
useful and _appropriate_ for T.37/RFC2305

tel (PSTN) and mailto are the key examples where you have to create hints 
for different types of services since there is no 'on the wire' capability 
or service negotiation.

I continue to suggest that is a key test of when and if you have to create 
more granular enumservice labels...

>telvoice, telfax, telsms, sipvoice, h323voice, http, https, mailto

this is a useful list

Broken Record Speaking :  sip only please. I do'nt see the distinction 
between sipvoice, sipvideo, simim, sipgame etc ..all I need to know is sip...

another analogy/example of my concern here might be the Internet Print 
Protocol. IPP negotiates the capability of the endpoints during the 
session, therefore there would be no need to have enumservice mnemonics 
like ippb&w, ippcolorA10, ippstaple, ipp3holepunch etc.  Ok ..maybe this 
example is a stretch ..but do you see what I mean.

Could you map a TN to a printer ... sure.  What is fax if not remote 
printing....

>clients operational in September (2002).

this can be arranged .....  I think we are pretty close to consensus here ..

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
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: Lawrence Conroy <[email-masked]>
Date: Wed, 29 May 2002 20:26:55 +0100

At 12:49 pm -0400 29/5/02, Richard Shockey wrote:
>In response to Richard Stastny's message:

Ok, I can acquiesce in that.
We have now moved completely away from the "high level services" of the
strawman and towards a whole bunch of similar definitions with a common
protocol hint but with different 'telecom service' endings.

Hey, if we can put these into a single RFC, then I guess the extra
cut-and-paste is tedious but not too hard.

I'm not convinced that this is the ideal way of doing things, but if all
other roads are blocked then we'll have to settle for where we can go.

>Broken Record Speaking :  sip only please. I do'nt see the 
>distinction between sipvoice, sipvideo, simim, sipgame etc ..all I 
>need to know is sip...

Hot Needle Responding: sipvoice for my WCOM account; sipim for my 
.NET IM account.
Or, if preferred, rhovoice or rhoim, to avoid confusion with the URI-scheme.

I have already said that I'll believe that peace breaks out between IM and
voice providers when the U.K. elects a Martian (no, I mean a real one) as
its President.

>
>another analogy/example of my concern here might be the Internet 
>Print Protocol. IPP negotiates the capability of the endpoints 
>during the session, therefore there would be no need to have 
>enumservice mnemonics like ippb&w, ippcolorA10, ippstaple, 
>ipp3holepunch etc.  Ok ..maybe this example is a stretch ..but do 
>you see what I mean.
>

I believe that the svc tag on a tel: URI will be, for example, fax.
I don't think the intent is anything more complex (G2, G3, ...).

The difference between mms and sms or ems MAY be too picky and so may 
not be needed.
IMHO, If it can be negotiated then there's no need for discrete tel 
URI svc tag.
Similarly, in this situation there is no need for a separate enumservice.

Also, if it is reasonable to expect a client that has a driver for 
one kind of message
service to have a client for the other kind, then again, no separate 
enumservice.

>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.
Hey, I guess that's only semantics and in the end, the trials will clarify
what works and what doesn't.

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Richard Shockey <[email-masked]>
Date: Wed, 29 May 2002 16:40:20 -0400

>protocol hint but with different 'telecom service' endings.

I simply see this as what do you want to put in a enumservice label.  Any 
reasonable alpha-numeric string will do so long as it is documented ... as 
you say this whole discussion has been about semantics .

>cut-and-paste is tedious but not too hard.

The key is the way the RFC is written and the need to conform to the 
requirements and tests that 2916bis will insist on.

>Hot Needle Responding: sipvoice for my WCOM account; sipim for my .NET IM 
>account.

well we'll just have to wait for Yokohama and the Sumo fest we're going to 
have over this one. :-)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 30 May 2002 13:38:50 +0100

Lawrence Conroy said:
>> this can be arranged .....  I think we are pretty close to consensus here 

I have to agree - I don't see consensus. I don't even see a solid
understandable proposal that consensus might happen around.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change