Subject: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Mon, 4 Mar 2002 11:27:50 -0700

More follow-up comments in line...

>> ENUM-registered endpoints are those in the termination path for an
>> E.164 number whose service capabilities are properly exposed in 
>> service field tags in NAPTR records. Since the PSTN today wouldn't
>> prevent other endpoints in that termination path with capabilities
>> not listed, or substitutions of a "non-registered" endpoint (such as
>> in the call forward case), there is always some potential for
>> mismatch between the termination path for an E.164 number and the
list
>> of services registered. I had perhaps oversimplified things a  bit by
>> referring to the endpoints as registered rather than their services.
>
> To which LwC sez:
> You mean ENUM/DNS registrants, I think.

Right, but what other registrations would there be? SIP?

> Re. the comment on end points - I assume that you mean the combination

> of the (enumservice and its associated URI) within a NAPTR, yes?

That's correct. 

> Also - Dead right, there is a potential for mismatch - that's one
> of the reasons why I'm hostile to E2VIDEO.G.263 and its ilk. It's
> an admin "challenge".

That challenge is still there, but the point is that it belongs in an
SRS because ENUM/DNS isn't engineered for this kind of dynamic.

<snip> 

>> With respect to exposure to hacks via service profiling, the SRS 
>> only solves this problem if the end user chooses a sufficiently 
>> narrow filter that gives little or no information to an unidentified
>> requestor. But it does give the ENUM registrant a great deal more 
>> control, particularly with respect to allowing for "blacklisting"
>> of known malicious requestors or request patterns, which ENUM is not
>>  prepared to do otherwise.
>
> To which LwC sez:
> ENUM isn't really prepared to do this at all.
> What you're suggesting is what happens AFTER we drop out of ENUM.

Exactly. This is a strong counter argument against the use of ENUM for
detailed service capabilities as it implies that the service it points
to is too weak to negotiate on its own or apply sophisticated access
control, etc.

> These are all possible using a suitable authenticated (and maybe
> encrypted) exchange - however, this subsequent exchange is going to 
> take time. I'm not sure that this is always going to be acceptable 
> when fired out from the core network, in the middle of call setup 
> (as per 3GPP). Post-dial delay is going to get long.

This is an excellent point. To avoid the latency gotchas around
real-time authentication, some services may rely on pre-established
relationships (could be among administrative realms, for instance). But
it's clear that this is a difficult problem and one that has to be
solved or we will have only created the world's most effective tool for
reliable spam propagation.

<snip>

>> My hope is to find enough interest to get a standalone presence 
>> service and protocol defined that isn't tied to any one message
>> or media signaling protocol. The main design constraints would be a 
>> clean query structure, a lean protocol, and tight integration with 
>> an identity system that would be usable for real time communications
>> and transactions.
>
> To which LwC groans:
> Whoa! Having endured the extended joy of IMPP, I (and I suspect
Patrik)
> may be a tad unhappy at the thought or reliving that experience.

Can't say I blame you :-)  On the other hand, it would take more than a
few awkward extensions to make another protocol general enough to act as
a pure presence service. Do you know of any system that will operate
between any valid "address" (including E.164 voice, fax, pager numbers,
URLs for tel, sip, h323, mailto, http, etc) and any valid service
endpoint (black phone, PBX phone, PDA, blackberry, IM, softphone, fax,
fax to email, IVR system, messaging system, web system, etc). SIP-based
presence comes close, but it forces at least one endpoint to speak SIP,
which is fine over the long run I suppose, but leaves out 99.99% of the
world's current communication devices. Even if SIP is wildly successful,
these older devices and systems aren't going away overnight.

>> While many proprietary systems exist today, I won't attempt to 
>> suggest an alternative to SIP/SIMPLE at the moment. Actually, my hope
>> is to craft a better general-purpose presence system from scratch.
>> Alternatively, adding some extensions to SIP presence might also work
>> (though there may be some obstacles of religion in that approach, as 
>> it seems unlikely to me that I will ever see an h.323 URI exposed via
>> SIP presence, for instance).
>
> To which LwC blinks and moves on:
> Again, I worry greatly about the "from scratch". Not group 3 again, or
> is this the first stirrings of group 4, of just forbidden planet, or 
> ...?

Fair enough. Especially if making something "from scratch" leads to
another IMPP-like exercise. Still, I would think that an approach based
on HTTP/SOAP queries and responses could be completed rapidly enough and
would have a jump on other protocols that have more complex deployment
issues with firewalls (or, to be fair, the whims and prejudices of
administrators and associated policies).

> I agree with Rudi - until we know what this system is intended to be,
> it's hard to do anything but trade assumptions. I'm being dumb here,
> but I would be most interested your ideas on what exactly is missing
> from SIMPLE or SIP for which you need extensions to cover?

To summarize from my discussion above, this is what's missing:

- Support for non-SIP URIs besides tel: (i.e. h323)
- No need for device to support other non-presence signaling (i.e. the
rest of SIP) to use service without gatewaying
- Pure any-address to any-device abstraction (i.e. media and signaling
agnostic)
- Idiot-proof firewall traversal story (SIP's isn't bad, but still
forces "admin education")

> Also, you use the reserved term "presence", and I'm not quite sure
that
> this is quite correct here - in SIP terms the AoR is static and is
> returned via an ENUM query. The current contact address may be updated
> depending on the connectivity of a destination client's equipments but
> that is a hidden back-end process. I guess that this back-end process
> could be classified as "presence", if you look at it cross-eyed enough
> (Maybe after snowbarding into a tree ?).
> However, from ENUM, it's a static value; plain vanilla SIP is acting
> as the SRS.

The notion of a presence and availability system is a back-end process
but a separable one. Until recently, however, it has almost always been
paired with a specific messaging or communications protocol. From the
ENUM perspective, it's just another static service, yes. But it also
reduces or eliminates from ENUM the burdens of privacy and service
negotiation. SIP is an example of such an SRS, but it's not fully
general. 

It is sometimes helpful to separate presence and availability as well.
Think of the "presence" side as a data-collection service that knows all
it can about the identity it services. It gathers data , analysis, and
intelligence from all available sources. But it doesn't give that
information out. That falls to the "availability" system which gets a
query, places it in context (authentication, caller ID, domain, path,
etc) and maps the presence data from the "presence" side against rules
to determine what to do, how much to expose, whether to lie or fuzz the
data, etc.

> Re. h232: and SIP or SIMPLE, I don't see why not. The new, expanded,
> Typhon may well be interested.

I'm not opposed to this, but I would hope that a general solution
doesn't force presence clients to support full SIP functionality if they
only use SUBSCRIBE/NOTIFY/... to access presence. This is especially
true for gatewaying services, but it's not a showstopper.

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 

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