Subject: [Enum] "Enumservices" and RFC 3953

From: "Fullbrook Kim (UK)" <[email-masked]>
Date: Wed, 26 Jan 2005 06:50:12 -0500

This note is partly about the new RFC 3953 and mainly about "enumservices" in general. Various RFCs seem to treat the subject in slightly different ways and I'd like to ask some experts if I've interpreted the RFC's correctly. This has implications for DNS data and ensuring compatibility of services, and an example is included which I believe breaks in the current system. If I've misinterpreted the RFCs and the RFC proposals are fine, I'll be happy to be corrected.

RFC 3953 describes use of ENUM with Presence services. Firstly, I'm not sure why we need a new RFC dealing specifically with Presence when the major existing services (or those under development) which would use E.164-based addressing actually utilise SIP and would be covered by existing RFCs. I'm thinking particularly of IMS here which is showing signs of global adoption by mobile and fixed operators. Anyway, that's not the main point and I'd prefer not to get side-tracked too far and would rather discuss the perceived flaw. From this point on I'm assuming that we do need to distinguish the Presence service as described by RFC 3953.

A bit of background - what is an "enumservice" ?   There seems to be a conflict between RFCs.
- RFC 3761 section 2.4.2 says "In other words, a non-optional "E2U" .... followed by 1 or more or more Enumservices which indicate what class of functionality a given end point offers.  Each Enumservice is indicated by an initial '+' character."  

So in an NAPTR record with field "E2U+pres", the 'pres' bit is the enumservice and we could potentially have "E2U+servicea+serviceb".  

- However, RFC3953 describes in Section 4 the "E2U+pres" Enumservice. So in this case the enumservice is "E2U+pres". 
Is the enumservice the combination "E2U+pres" or the singular "pres" ?

I'll move on to the point of functionality that I'm concerned about, with an example to illustrate my question/concern. 

There are two users A and B.
A is a customer of a new "Presence" service as described in RFC3953, which utilises the SIP protocol. ENUM data is in place with an NAPTR field of "E2U+pres". 

B is a customer of an existing RFC3824-compliant SIP-based system which has implemented presence. ENUM data is already in place with an NAPTR field of "E2U+SIP".

Let us suppose that the new Presence service has a compatibility mode so that it can work with the existing SIP based presence service.

Customer A calls B via their E.164 number. B's number is looked up in the ENUM DNS and all the NAPTR records for that number are returned. The NAPTR field i
s "E2U+SIP".  A's service knows that it can work with SIP so a match of records is found, it also understands the sip: URI scheme, and the call goes through.

Now Customer B calls A via their E.164 number. A's number is looked up in the ENUM DNS and all the NAPTR records for that number are returned. The NAPTR field is "E2U+pres".  B's service only knows that it can work with "SIP" service so there is no match of records - it does not know about "pres" - and the call fails. RFC 3953 specifies that the URI scheme has "pres:" URI scheme rather than "sip:" so potentially it could have failed here too because B does not understand "pres:" protocol.

This is where my understanding fails regarding what is intended by the RFC authors. What the RFCs say does not implement what we need because in the example the call has failed. How do we solve the situation that I've described ?

I'd suggest that one way it could be solved would be for the new Presence service to implement its ENUM data using an NAPTR field of "E2U+pres+SIP" while also using a "sip:" URI scheme (i.e. NAPTR record includes sip:+123456789 at networka.com).

Then when B looks up A's ENUM data it can find a match with the "SIP" service. However, this can only work if the enumservice is based on the component parts (i.e. "pres" or "SIP") rather than the combination "E2U+pres", and the sip: URI scheme is used.  

Another way it could work would be for the ENUM data for A to have two NAPTR records, one "E2U+pres" using the "pres:" URI and the other "E2U+SIP" using the "sip:" URI. This option seems to me to be a wasteful solution (twice as much data stored) which ignores the value of the "enumservice" field as described in RFC3761.

I'll come back to the question posed above "what is an enumservice" ? If it is the component part i.e. "pres" or "SIP" then the design can work but some RFCs have misleading wording and have all the resolvers been implemented correctly to support what is needed ?

Is there a problem here ? What do others think ?

========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby telephone or email (to the numbers or address above) immediately.========================================================
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Klaus Darilion" <[email-masked]>
Date: Wed, 26 Jan 2005 09:06:15 -0500

<FONT face=Arial color=#0000ff 
size=2> 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

  From: enum-bounces at ietf.org 
  [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim 
  (UK)Sent: Wednesday, January 26, 2005 12:49 PMTo: 
  'enum at ietf.org'Subject: [Enum] "Enumservices" and RFC 
  3953
  
  <SPAN 
  class=125154113-26012005> ...
  <SPAN 
  class=125154113-26012005> Now Customer B calls A via their 
  E.164 number. A's number is looked up in the ENUM DNS and all the NAPTR 
  records for that number are returned. The NAPTR field is "E2U+pres".  B's 
  service only knows that it can work with "SIP" service so there is no match of 
  records - it does not know about "pres" - and the call fails. RFC 3953 
  specifies that the URI scheme has "pres:" URI scheme rather than "sip:" so 
  potentially it could have failed here too because B does not understand 
  "pres:" protocol.
<FONT 
color=#0000ff>If the clients of A and B support several services - e.g. voice 
calls and presence - you have to publish them in DNS, e.g. make 2 
NAPTRS E2U+voice:sip    
sip:user at domain<FONT 
size=2><FONT 
color=#0000ff>E2U+pres       pres:user at domain
<FONT 
color=#0000ff>or if the URI is the same, you could use:<FONT 
color=#0000ff>E2U+voice:sip+pres    
sip:user at domain
<FONT 
color=#0000ff>Of course you could use a "generic" NAPTR using E2U+sip, nut this 
doesn't tell you if the client is capable of presence, video ... or 
not.<SPAN 
class=125154113-26012005>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=125154113-26012005> <FONT face=Arial 
  size=2>Another way it could work would be for the ENUM data for A to have two 
  NAPTR records, one "E2U+pres" using the "pres:" URI and the other "E2U+SIP" 
  using the "sip:" URI. This option seems to me to be a wasteful solution (twice 
  as much data stored) which ignores the value of the "enumservice" field as 
  described in RFC3761.
<FONT face=Arial color=#0000ff 
size=2>This is how ENUM works. If you want to publish your contact data, e.g. 
your email contact and your homepage, you also use one NAPTR for each 
service:E2U+web:http    <A 
href="http://domain/sip:user at domain">http://domain/<FONT 
face=Arial><FONT 
color=#0000ff>E2U+email:mailto       <A 
href="mailto:user at domain">mailto:user at domain
<FONT face=Arial color=#0000ff 
size=2><SPAN 
class=125154113-26012005>regards,
<FONT face=Arial color=#0000ff 
size=2><SPAN 
class=125154113-26012005>klaus
<FONT face=Arial color=#0000ff 
size=2><SPAN 
class=125154113-26012005> 
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Fullbrook Kim (UK)" <[email-masked]>
Date: Wed, 26 Jan 2005 09:55:16 -0500

<SPAN 
class=419253614-26012005>Klaus,
<SPAN 
class=419253614-26012005> 
<SPAN 
class=419253614-26012005>Thanks, the suggestions make sense and are consistent 
with RFC 3761. They suggest that there is a series of terminology mistakes in 
RFC 3953:
Where 
it says, for example, in Section 4 
<SPAN 
class=419253614-26012005>"the 'E2U+pres' 
enumservice"
what 
it should have said was 
<SPAN 
class=419253614-26012005>"the 'pres' enumservice"
<SPAN 
class=419253614-26012005> 
<SPAN 
class=419253614-26012005>Kim.

  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Klaus Darilion 
  [mailto:klaus.darilion at nic.at] Sent: 26 January 2005 
  13:52To: Fullbrook Kim (UK); enum at ietf.orgSubject: RE: 
  [Enum] "Enumservices" and RFC 3953
  <FONT face=Arial color=#0000ff 
  size=2> 
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

    <SPAN 
    class=125154113-26012005> ...
    <SPAN 
    class=125154113-26012005> Now Customer B calls A via 
    their E.164 number. A's number is looked up in the ENUM DNS and all the 
    NAPTR records for that number are returned. The NAPTR field is 
    "E2U+pres".  B's service only knows that it can work with "SIP" service 
    so there is no match of records - it does not know about "pres" - and the 
    call fails. RFC 3953 specifies that the URI scheme has "pres:" URI scheme 
    rather than "sip:" so potentially it could have failed here too because B 
    does not understand "pres:" protocol.
  <FONT 
  color=#0000ff>If the clients of A and B support several services - e.g. voice 
  calls and presence - you have to publish them in DNS, e.g. make 2 
  NAPTRS E2U+voice:sip    
  sip:user at domain<FONT 
  size=2><FONT 
  color=#0000ff>E2U+pres       pres:user at domain
  <FONT 
  color=#0000ff>or if the URI is the same, you could use:<FONT 
  color=#0000ff>E2U+voice:sip+pres    
  sip:user at domain
  <FONT 
  color=#0000ff>Of course you could use a "generic" NAPTR using E2U+sip, nut 
  this doesn't tell you if the client is capable of presence, video ... or 
  not.<SPAN 
  class=125154113-26012005>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <SPAN 
    class=125154113-26012005> <FONT face=Arial 
    size=2>Another way it could work would be for the ENUM data for A to have 
    two NAPTR records, one "E2U+pres" using the "pres:" URI and the other 
    "E2U+SIP" using the "sip:" URI. This option seems to me to be a wasteful 
    solution (twice as much data stored) which ignores the value of the 
    "enumservice" field as described in RFC3761.
  <FONT face=Arial color=#0000ff 
  size=2>This is how ENUM works. If you want to publish your contact data, e.g. 
  your email contact and your homepage, you also use one NAPTR for each 
  service:E2U+web:http    <A 
  href="http://domain/sip:user at domain">http://domain/<FONT 
  face=Arial><FONT 
  color=#0000ff>E2U+email:mailto       <A 
  href="mailto:user at domain">mailto:user at domain
  <FONT face=Arial color=#0000ff 
  size=2><SPAN 
  class=125154113-26012005>regards,
  <FONT face=Arial color=#0000ff 
  size=2><SPAN 
  class=125154113-26012005>klaus
  <FONT face=Arial color=#0000ff 
  size=2><SPAN 
  class=125154113-26012005> ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby telephone or email (to the numbers or address above) immediately.========================================================
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum