Subject: [Enum] high and low level function mixing

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 26 Jun 2002 23:37:52 +0100

Hi again folks,
   Note that one issue is "what is the 'level' of the matrix 'function' axis"?
This is covered extensively in the enumservice-analysis draft, but there seem
to be two discrete possibilities.

We have "high level functions"  - also known as categories - and/or we have
"low level" functions like voice, video, fax, sms, (basically the ones listed
in the tel-svc draft <draft-brandner-tel-svc-00.txt> plus possibly one or two
more, like mailto).

Now...in the analysis draft, there's the possibility of mixing these;
thus +talk+voice, or msg+sms. This raises an interesting detail that's
covered only briefly in the "category" draft and I'd like to flag here.

If the querying user is interested in a high level category like "talk",
and the registrant has specified a low level function like "voice", a
simple string match is not going to work.

In the category draft we've tried to cover the low level functions that
are contained in each of the categories, so if the querying end user
(or the User Interface with which they're interacting) specifies "talk"
then this can be converted into a list with the strings "talk" plus all
of the more specific services that comprise this category ("voice", "video").
All of the strings in this list can be matched against the incoming NAPTR,
and it works fine.

However....
What if the querying user specifies a low level service like "video", but
the registrant has specified only a category like "talk"?

There seem to be two choices here - either the D3S client application
engine doesn't match the string (in which case we may have a false negative)
or the "containing" category string is added, in which case we MAY have a
false positive. The querying user may have no way to know whether or not
this *is* a false positive without trying the URI (certainly if it's a tel:).

Personally, I think that the D3S client application engine should return
the URI in this situation. The registrant may have their own (privacy ?)
reasons for not being more specific, and for "normal" protocols like SIP
there will be a second negotiation phase outside ENUM anyway.

However, I'd appreciate any comments on this, please.

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