Subject: [Enum] Rules, Order, Preference, Priority

From: "Stastny Richard" <[email-masked]>
Date: Tue, 26 Nov 2002 10:18:48 +0100

On Monday, November 25, 2002 3:58 PM Michael Mealling wrote
>
> On Mon, 2002-11-25 at 09:19, Stastny Richard wrote:
> > As I understand RFC3403, there is an Order and a Preference 
> field, but 
> > no Priority field. Since the order field applies IMHO only if 
> > not-terminal NAPTRs (no U Flag) are used, here the preference field 
> > should be mentioned and the word order should be avoided eg: ...for 
> > the preference of the usage of ...
> > 
> > This also implies, that the example in 4.1 should be
> > modified accordingly.
> 
> Incorrect. The term 'Priority' is from the DDDS algorithm. It 
> is equivalent to the Preference field in the NAPTR 
> (Preference is used in deference to DNS experts language 
> preferences). Also, DNS returns records in what ever order 
> the nameserver likes with no gaurantees to the querier that 
> the order will make any sense. I would strongly object to any 
> wording being in the document that suggests any 
> implementation should ignore the Order field or that the 
> ordering step be optional. As an example shows below, records 
> of different order accomlishes one thing while records of the 
> same Order and different Priority/Preference does something 
> completely different.

Hi MM, I really appreciate your subtle way to tell me to RTFM.
I apologize, but I am proud also that at least I found out by
myself that priority=preference;-)

Nevertheless, I am still a bit confused with use of the order and
preference (priority) fields.

Lets take the two examples:

> > > 
> > > 4.1 Example
> > > 
> > >     $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
> > >       IN NAPTR 100 10 "u" "E2U+sip"            
> > > "!^.*$!sip:[email-masked]!"     .
> > >       IN NAPTR 101 10 "u" "E2U+h323:voice"     
> > > "!^.*$!h323:[email-masked]!"    .
> > >       IN NAPTR 102 10 "u" "E2U+message:mailto"
> > > "!^.*$!mailto:[email-masked]!"  .
> >  
> > 
> > >     $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
> > >       IN NAPTR 100 10 "u" "E2U+sip"            
> > > "!^.*$!sip:[email-masked]!"     .
> > >       IN NAPTR 100 20 "u" "E2U+voice:h323"     
> > > "!^.*$!h323:[email-masked]!"    .
> > >       IN NAPTR 100 30 "u" "E2U+message:mailto"
> > > "!^.*$!mailto:[email-masked]!"  .
> 
> > See also the same order and different preference as mentioned above.
> 
> Can you elaborate on that statement? The two examples above 
> are actually doing very different things. The example in the 
> document is saying that you have to match explicitly on each 
> group's service field and you can only use the one that 
> matches first. The second is saying that each service is 
> 'equivalent' and the client gets to pick. That's two very 
> different things.
> 
>

Since we are trying to define the minimum requirements
on ENUM clients for interoperability, a correct understanding
of the use of order and preference is important.

Order is defined in RFC3403:

ORDER
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed in order to accurately represent the
      ordered list of Rules.  The ordering is from lowest to highest.
      If two records have the same order value then they are considered
      to be the same rule and should be selected based on the
      combination of the Preference values and Services offered.

In RFC2916bis it is stated:

2.4.1 Flags

    This Database contains a field that contains flags that signal when
    the DDDS algorithm has finished.  At this time only one flag, "U", is
    defined.  This means that this Rule is the last one and that the
    output of the Rule is a URI [3].

    If a client encounters a record with an unknown flag, it MUST ignore
    it and move to the next Rule.  This test takes precedence over any
    ordering since flags can control the interpretation placed on fields.
    A novel flag might change the interpretation of the regexp and/or
    replacement fields such that it is impossible to determine if a
    record matched a given target.

Maybe I get something wrong here, my original idea of ordering was that
if I have a set of rules, I MUST order them first according
to the order field and process them one after the other until an
"U" flag is encountered. Then I may look at the enumservice field
and eventually retrieve the URI.

What you are saying is the following (I am trying to write an
developers guide here):

Order the NAPTRs according to the order field (and if the same order
value by preference) and then start matching the enumservice(s) supported
by your client with the lowest order. If a match is found, take it and 
ignore the rest of the NAPTRs, exept if you have a NAPTR with the
same order. Then you may take the one with the lowest number in the
preference field, but you may also take one with higher preference.

The above is valid in our case for what we call application specific
ENUM clients, e.g. an SIP-Phone.

Other clients we have are displaying all NAPTRs available. We call this
generic ENUM clients. In this case the NAPTRs are displayed just by order
and preference and it up to the user to make sense out of it.

I can live with this, but I still have some doubt. If I take the definition
of preference in RFC3404:

PREFERENCE
      Although it is called "preference" in deference to DNS
      terminology, this field is equivalent to the Priority value in the
      DDDS Algorithm.  It is a 16-bit unsigned integer that specifies
      the order in which NAPTR records with equal Order values SHOULD be
      processed, low numbers being processed before high numbers.  This
      is similar to the preference field in an MX record, and is used so
      domain administrators can direct clients towards more capable
      hosts or lighter weight protocols.  A client MAY look at records
      with higher preference values if it has a good reason to do so
      such as not supporting some protocol or service very well.

It seems to me that in common words the order field in the NAPTRs
according to your explanation may give the "preference" of the
called party by type of communication he prefers to be contacted,
e.g. the called user prefers sip above h323, if both are there.

The preference field gives the "preference" for equivalent types
of communication, e.g. if two sip NAPTR are there, you may point to two
different proxies, but prefers the first one. If order and preference
is the same, you may use this for loadsharing at random.

There may also be another interpretation: I as a called user do
not care in principle, the calling user may chose in the first 
place, but if the calling user is in doubt, may "preferences" are
by the numbers in the preference field.

Since I have heard all types of explanations about order and
preference, I want to have settled this issue finally.

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