Subject: Re: [Enum] Regarding brandner-compendium discussion in ATL

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 15 Nov 2002 00:09:00 +0000

Hi Folks,
   Our esteemed co-chair asks about the the compendium draft = [Rich sez:]
Herewith my responses. [LWC  sez:]

(Comprised Services)
Rich sez: why cant you just call dap ldap?
LWC  sez: because we WERE trying to use different names for the enumservice
and protocol symbols as per earlier list discussions.
Strictly, we shouldn't use sip and h232, as these are also protocol symbols.
However, as the sip draft always mentions 'sip' as an enumservice, and
the h323 draft always talks about 'h323' as an anumservice, we try to oblige.
[IMHO, this is nasty, as it forces positional sub-field processing, but...]

Rich sez: E2U+ldap:srs
LWC  sez: I think that this has swapped the enumservice sub-field and the
protocol sub-field. "ldap:" is the the URI scheme we copy into the protocol
sub-field, and srs is the enumservice. You may have done this elsewhere...

It would break our client, as we've just thrown away the separate "protocol"
and "enumservice" symbol list scanning code (to allow for sip and h323 to
appear in both lists) - now it expects to find the enumservice sub-field
as the first one of each block (as in rfc2916bis-01).
I suspect it would break the Infonova client, and the AOSA client. I'm
sure there are others who get rained on by this change.
I guess that this wasn't intended just to pi** off the coders (amusing as
this can be with Trial deadlines stressing them all :), so why is this
swap NEEDED?

Rich sez: You are not suggesting E2U+sip:srs are you ... or E2U+h323:srs ?
why is this necessary?

LWC  sez: Strictly, we're suggesting E2U+srs or E2U+srs:sip or E2U+srs:h323,
or E2U+sip or E2U+h323.
According to rfc2916bis-01, the first sub-field is the enumservice, so these
examples mean:
enumservice = 'srs', protocol unspecified (evaluate URI to find out)
enumservice = 'srs', protocol = SIP
enumservice = 'srs', protocol = H.323
enumservice = 'sip', protocol unspecified (but you can guess :)
enumservice = 'h323', protocol unspecified (but you may guess :)

Thus, are we suggesting E2U+srs:sip? - yup, you *could* do this.
You *could* also put E2U+all:sip. Either is a little overkill, though.
(All is a catch-all category, so it matches everything or anything).

SRS is a category, so that it's more likely to be specified by the
(client) end user rather than being in a NAPTR service field. If the client
has said they're interested in this kind of communication, then it will
match with a supported enumservice of 'sip' or 'h323' (or 'srs') found
in a retrieved NAPTR.

I (and others) contend that we do not want to FORCE an ENUM registrant
to have only one service provider for all of their SIP protocol uses.
I understand that this is possible, but do not accept that it is a
requirement. I have more than one sip AoR, so it is patently not NEEDED.

In particular, I have one AoR for use with IM, plus two others that I use;
for SIP/PSTN calls. Note what's missing here? - an SRS.
These are specific for 'im' (messages) and for 'voice' (talking).

Thus, 'sip' would appear as the protocol within a number of different
NAPTRs - one for enumservice 'voice', one for enumservice 'im'.

Now we have the 'sip and 'h323' enumservices, you could just use
'E2U+sip' or 'E2U+h323' in a single NAPTR and you're done for ENUM.

I guess that it's valid for someone to have yet another sip AoR
that acts as a general SRS - thus you could have one for you IM
service provider (from Redmond, say), one for voice (from Clinton, say)
and one that is an SRS - from your Universal Messaging Service provider.

I can't see why anyone would have all of these, but I'm not going to
stop them doing this.

In short, if folk want to have separate services, they can.
If folk want only a single E2U+SRS or E2U+sip or E2U+h323 entry, 
that's fine too.
Seems reasonable to me, so I don't see the problem.

----

Rich sez: IMHO the general case is 
E2U+enumservice:enumdescription1:enumdescription2:etc
where enumdescription is purely optional on the part of the ENUM registrant

LWC  sez: Right now, we have E2U+<enumservice>:<protocol>
Of these, the protocol part is optional.

Now...
Rich sez: E2U+voice:sip is not acceptable
           E2U+sip:voice where "voice" is purely optional is.
LWC  sez: Well....that's why I don't like using sip (or h323) as both
a protocol AND as an enumservice.

In the first example, (using I guess the above ordering of sub-fields)
the enumsevice is 'voice' whilst the protocol or enumdescription1 is
sip. Well....sip may well be the protocol, so using rfc2916bis-01 format,
that's fine. However, if it's a description only (using your syntax), then
there's no need for it so I'd agree that doesn't make sense.

In the second example, it is NOT OK if using rfc2916bis-01 syntax, as
there's no protocol called 'voice' (AFAICT).
This is OK using your syntax as voice is a description. However, the
enumservice 'sip' claims to be an SRS. Thus the extra information is
strange - why hide all of your services behind an SRS and then tell
people what kind of communication they can expect?

Rich sez: I still do not understand the difference between "talk" and
"voice" and "ivoice"  - I do not understand the difference between "chat"
and "im".

LWC  sez: OK - that can be improved in compendium-01.
"talk" is a general kind of communication - as in a bidirectional
interchange using continuous media exchange, whilst "voice" is a more
specific kind of this category of communication. "ivoice" is a
variant on voice - it's identical except that, *if the client has a
choice on delivering their call*, this should be to an IP-based
interconnect, whilst "voice" is, if anything, a PSTN end point so
the call should be delivered to a PSTN interconnect, by preference.
It's a very minor point but may allow some ENUM-like systems to avoid
the spectacle of up to 6 transcodes between PSTN and IP worlds.

'chat' is a distinct kind of message exchange, in which the messages
are exchanged in a session-oriented fashion. 'im' is similar, but each
message is sent outside a session - as a "one-off".
For example, text phones are a session oriented system, as they require
a connection to be nailed up for the terminals to exchange data. SMS,
on the other hand, is a pure message based system - no session is made
between the correspondents.

Rich sez:  E2U+tel:fax makes sense, a PSTN fax call ..
E2U+tel:textphone seems very useful.

LWC  sez: except that we do not have a 'tel' enumservice. Now, I seem to
recall that folk did not like this at all when we proposed it originally.

'tel' is a pseudo-protocol, it's not an enumservice as they are defined
right now. The compendium lists the kind of enumservices that one would
expect to see in a NAPTR alongside a "tel:" URI.

One of these is 'fax' - it's a kind of 'msg' service. When I send a fax,
that's the teleservice/feature I'm using, not just the phone line.
So, from a caller's perspective, knowing that this contact is for fax is
pretty important. Thus (in rfc2916bis-01 format) "E2U+fax:tel" is fine -
fax is the enumservice, whilst this is executed using the "tel:" URI.

Rich sez: E2U+tel:mobile:sms makes sense ..
LWC  sez: Well, put this as E2U+sms:tel:mobile and I might agree.
The mobile (or home, or office, or any of the other VCARD-style qualifiers)
is sure something to consider - I'm still not convinced that we need a
"protocol" sub-field as the client can "look to the right" in the NAPTR,
as Richard puts it. Thus we could lose the ":tel" bit in the middle, IMHO.
Having these kind of "real" qualifiers seems like a good (but optional)
use of bytes - at least it's not duplicating stuff.

This is going to need some spec to ensure that the Client and 
publisher/Registrant
both use a common set of values.

Do you think that the VCARD definitions are a start, or do folks prefer
some different spec for these kind of qualifiers?

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Thu, 14 Nov 2002 22:45:14 -0500

>[IMHO, this is nasty, as it forces positional sub-field processing, but...]

huh? do not grok last sentence..

>sub-field, and srs is the enumservice. You may have done this elsewhere..

In my humble view ldap is the service and srs is the description of the 
service..that was my point.

>this can be with Trial deadlines stressing them all :), so why is this

the behavior of your client is of no concern to the WG

this needs to be worked out Monday .. I'm personally not in favor of this 
approach and will argue this position vigorously.

>enumservice = 'h323', protocol unspecified (but you may guess :)

I will oppose this. SIP is the service... IMHO it needs no additional 
embellishment. a description possibly..

>Thus, are we suggesting E2U+srs:sip? - yup, you *could* do this.

NO ..

>(All is a catch-all category, so it matches everything or anything).

ABSOLUTELY NO WAY  I believe the SIP community would strongly oppose such 
an approach.

>match with a supported enumservice of 'sip' or 'h323' (or 'srs') found

you are not accommodating the requirements of the called party here.. I 
want to make it abundantly clear my position... it is the called party that 
is in control here of the entire process..what the calling party wants is 
frankly irrlevant. It is the called party that must register their 
preferences in the global DNS and how they choose to expose data is IMHO 
the primary consideration.

If registrants do not participate in the global ENUM system and trust it to 
protect their privacy when required this is a futile excersise.

>requirement. I have more than one sip AoR, so it is patently not NEEDED.

How does the construct prohibit more than one SIP service provider that is 
what order and preference fields are for.

>These are specific for 'im' (messages) and for 'voice' (talking).

fine contact the sip proxy of the called party identified and they will 
tell you what where and how to complete the session

>NAPTRs - one for enumservice 'voice', one for enumservice 'im'.

so what the problem ..

>'E2U+sip' or 'E2U+h323' in a single NAPTR and you're done for ENUM.

my point

>Seems reasonable to me, so I don't see the problem.

good ... but a totally separate SRS outside the scope of sip and h323 , 
which has not been defined _at this time_ is out side the scope of your draft.

>Of these, the protocol part is optional.

well the service may represent a protocol but I'm willing to admit hints to 
the capability of the end points to permit calling parties a choice of 
endpoints. You continue to avoid my points here.

>a protocol AND as an enumservice.

we have differing opinions of this.

>there's no need for it so I'd agree that doesn't make sense.

This is the issue .. in the draft the relationship between service needed 
and enumservice aka protocol is not clear. I hppe to see clarification and 
direction of where Patrik and Michael are going at this point.

>people what kind of communication they can expect?

some SIP endpoints may not be capable of IM for instance I may have one 
provider for SIP IM and another for SIP voice..

>the spectacle of up to 6 transcodes between PSTN and IP worlds.

again this is really really messy IMHO

>recall that folk did not like this at all when we proposed it originally.

point well taken .. I was thinking that if someone wanted to send me a fax 
and the only methodology I permitted was PSTN G3 then the construct made 
sense in the context of called party control...but realistically this could 
be done through SIP as well

>LWC  sez: Well, put this as E2U+sms:tel:mobile and I might agree.

agggg..

tel is the service sms is the  capability or application of the endpoint.

>both use a common set of values.

exactly

>some different spec for these kind of qualifiers?

pointer to white page like info ..sure .. but its a option to the 
registrant only some folks may want that there others ..probably most do 
not but then you can get white page like data from Google if you have to... 
the issue is called party (aka registrant) control of what goes into the DNS.

I've actually thought of geospatial data enumservice might be useful for 
mapping etc.

E2U+http:map  to a http site with GML object...  local restaurants might 
find it helpful.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<