Subject: RE: [Enum] SchemaSet strawman

From: "Stastny, Richard" <[email-masked]>
Date: Tue, 28 May 2002 09:45:59 +0200

Rich wrote, to which I reply:

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Monday, May 27, 2002 7:10 PM
> To: Patrik Fältström; Stastny, Richard; Stastny, Richard; 
> Lawrence Conroy; [email-masked]
> Subject: RE: [Enum] SchemaSet strawman
> >
> >The '+' sign is to separate enumservices alltogether. If we 
> are going 
> >down the path of "subservices" then we need to use a different 
> >separator, like '-'. I would like to NOT go down that path if not 
> >really really needed. And I really mean needed from a technical 
> >standpoint and not only "because the design looks nice".
> 
> On reflection, I stand corrected Patrik ..I think you are 
> right ... the '+' 
> should separate distinct services.
> 
> So to follow your example in the case of SMTP you would 
> suggest  "E2U+smtpfaxs" for possibly designating Simple Mode 
> Fax [RFC2503] 
> and "E2U+smptfaxf" for Full Mode or something like that. A single 
> enumservice designator.
> 

I do not like to go down this path, because the number of combinations is
endless, and to register all smptfaxs, telfaxs, sipfaxs, telvoice, sipvoice,
h323voice, and sipvideo etc. is a nightmare.

If it is really necessary to mention the URI used in the enumservice filed,
I would like to go down the path of combinatorics. The service definition is
complicated enough (nobody was ever able to explain to me what a service is
anyway)

So what I propose is either to define the field enumservice as:

[ E2U "-" URIused 1*("+" service)]

Where service is voice, fax, sms, mms, video etc

The templates have to be created not per service, but per URI, it may even
contained in the URI definitions, which services can be used (in the svc
parameter).

Or the enumservices are grouped as proposed by Lawrence and we peek ahead in
the URI and svc parameter.

Best regards
Richard

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

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 May 2002 11:21:34 -0400

>h323voice, and sipvideo etc. is a nightmare.

Well the combinations you propose are N (squared) .. :-)

Well  I still submit that SIP is SIP and since negotiation on these 
protocols occurs on the wire granularizing the service is unnecessary. I 
feel pretty strong about this and I believe the feeling is shared among the 
SIP community.

>Where service is voice, fax, sms, mms, video etc

and this construct 'E2U-smtp+faxs' is not a nightmare? So the registration 
procedure would be for  SMTP and all service variants of that?

>contained in the URI definitions, which services can be used (in the svc

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

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: Tue, 28 May 2002 17:18:22 +0100

At 11:21 am -0400 28/5/02, Richard Shockey wrote:

>>In response to Richard Stastny's comment:

<g> - yes, but I don't have to write RFCs for smtp: or http: or sip:.
We stand on the shoulders of giants. Thus, I could write an RFC to
show what a poor client can expect if it sees this tag (including
some idea of the list of URI schemes that can be used with it, and
how it should be treated if a particular URI scheme is decoded).

>protocols occurs on the wire granularizing the service is 
>unnecessary. I feel pretty strong about this and I believe the 
>feeling is shared among the SIP community.

Yes, I understand that the "SIP community" believe this. They're 
right, as well. And yet...
As already stated in an earlier post, this is not a technical issue, 
it's a reality issue.
(Not, of course, that I'm suggesting that some of the "SIP community" 
have lost touch with reality :).

I don't even want to think about explaining to Joe XP@home user how 
to tie their WCOM siptest
account behind their .NET account (the one they use to text with 
their buddies).
Technically that's easy, but...

>and this construct 'E2U-smtp+faxs' is not a nightmare?

Um...I don't need to do one registration for ('talk' when using a 
tel: URI) and another for ('talk' when using a SIP URI) and another 
for ('talk' using putative h323: URI), and ...
I do one registration for 'talk', in which it describes any handling 
for any URI-schemes that it can use, and that's
it folks.

One draft versus three is good in my book.
It also (IMHO) makes it easier for an end user to select a category 
of communication that they want to have, and
then pattern match against any NAPTRs regardless of whether they 
indicate tel: or SIP: or whatever:. Your mileage may vary, of course.

>So the registration procedure would be for  SMTP and all service 
>variants of that?
>
>

Here's a radical proposal.
Instead of having each of these higher level functions (like 'talk') 
describe how to handle particular URIs to provide the expected 
function, we have a draft that shows the higher level functions that 
can be carried out with the URI scheme (I assume that with sip:, the 
description will include all/any to show that it does SRS as well as 
more specific services).

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

see above for 'nightmare' response.

>Richard ..I really am trying to understand this ...

(Et moi aussi :)
It is a lot closer to the existing 'tel' and 'sip-e164' drafts, I think?

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