Subject: [Enum] Experienced?

From: lconroy <[email-masked]>
Date: Thu, 21 Apr 2005 21:32:51 -0400

Hi folks,
  My esteemed and eagle-eyed co-author Fujiwara-san has detected some 
typos that need to be fixed.
These will be corrected in the up-issue coming out Real Soon Now.

However, as we prepare for the ENUM plugtest over here (to which all 
are invited**), we will be including a couple of torture tests that *I* 
think could be added as minor issues to the Experiences draft.

** (2-6th May:RIPE-50 in Stockholm, 11-22nd May:Cannes Film 
Festival/Monaco Grand Prix, 23-26th May:VON Europe in Stockholm, 
30.May-3.June:ENUM Plugtest back in the Cote D'Azur. Hey ho - it's a 
hard life)

----
New/Final Topic: Compound NAPTR processing
Note that a NAPTR MAY have more than one ENUMservice in its service 
field, as long as all such ENUMservices are defined to use the same 
URL. For example:

IN NAPTR 10 100 'u' 'E2U+<enumserviceA:mailto>+<enumserviceB:mailto>' 
'\!^.*$\!mailto:joe at example.com\!' .

where enumserviceA:mailto and enumserviceB:mailto are defined 
ENUMservices,
both of which specify mailto as an acceptable URL scheme.

We haven't said explicitly what, if a client doesn't understand or 
support one of these ENUMservices, it should do. Should it continue 
with the next ENUMservice to see if that is supported, or discard the 
whole compound NAPTR as unusable? i.e. (in the above example), if 
enumserviceA is not supported but enumserviceB is supported, SHOULD the 
NAPTR be considered as a valid result?

IMHO, it is logical for the Client to continue after rejecting the 
first ENUMservice, and the resulting NAPTR is valid if any ENUMservice 
is supported. I propose that this should be the recommended behaviour.

As an aside, note that it is valid to mix "experimental" ENUMservices 
(those that start with the 'X-' facet) with others. Thus, it is 
perfectly valid to have a single NAPTR that provides/generates a 
contact URL that may be used by both a "well known" ENUMservice and 
also some private/unregistered/experimental one. For clients that are 
not involved in the experiment, the NAPTR can still be used with the 
"well known" ENUMservice, so:
(i) you may well see such compound NAPTRs "in the wild", and (ii) your 
client should not give up if it sees an unrecognised 'X-' ENUMservice, 
as there may also be one it does understand "later" in the services 
field.
----

I propose to add this topic to the Experiences draft, but would 
appreciate comments from the list.
Please holler, as the current version expires shortly, and so I will 
have to up-issue it soon.

BTW,
all the best,
  Lawrence
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum