Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt

From: Brandner Rudolf <[email-masked]>
Date: Thu, 6 Mar 2003 20:08:46 +0100

Hi Juha, folks,

the issue you are trying to get at has been discussed on the list and on IETF meetings. However, the issue has not been solved so far, IMHO.

You point out, that the enumservice registrations in the draft are very bad, at least for SIP. You do not point out, what the bad thing is. 

In your case, where you have just one SIP proxy/registrar, the enumservice 'voice:sip' might not be very useful. Well, AFAIK, we did not say that this enumservice is mandatory, nor that it is useful in your or every case.

Nevertheless, there are other circumstances, where the enumservice 'voice:sip' has its benefits and value. The reason we included a way to hint that this SIP-based Service would be used for Real-Time Communications whilst that would be used for IM is simple; a significant group of folk that I know have two different accounts - one with Redmond for IM, with another with Richardson for voice. If you try the Richardson account, you won't find anyone listening for IM; if you try to voice-call my IM account, you won't get much joy. Now...which entry do I put in my ENUM domain? Our answer is both; yours is just one, as you only have one SIP-based service. Having both entries gives you a hint which one to use if you want to have, as an example, real-time voice communication.

To say that it's (always) a BAD IDEA to give these hints is not, IMHO, proven, just because it is not appropriate for some configurations.

best regards,
Rudi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Donnerstag, 6. März 2003 14:07
> To: [email-masked]
> Subject: [Enum] draft-brandner-enumservice-vovi-00.txt
> 
> 
> someone pointed me to draft-brandner-enumservice-vovi-00.txt, which i
> think is a VERY BAD idea at least for sip.  the enum entry of my phone
> number would simply point to sip:[email-masked] without any service types,
> since those change all the time depending on what kind 
> terminals i have
> registered with the proxy of song.fi.  there are caller 
> preferences and
> so on that tell the capabilities of my current registered terminals.
> 
> is this document really somehow endorsed my the enum working 
> group?  if
> i remember correctly, this issue was discussed at atlanta and many
> people shared the above view.
> 
> -- juha
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: 06 Mar 2003 14:26:29 -0500

> To say that it's (always) a BAD IDEA to give these hints is not, IMHO, proven, just because it is not appropriate for some configurations.

I'd like to voice some support here for Rudi's point. The point of ENUM
Services being speced the way they are is so that multiple services can
exist side by side without interfering with each other. If one services
chooses to be SIP only with no other information specified then that's
fine. Its also fine to do it Rudi's way. Both are two different
enumservices doing two different things. One is free to ignore the
other.

SIP is not the only protocol in the universe....

-MM

---

From: [email-masked]
Date: Thu, 6 Mar 2003 22:04:05 +0200

> SIP is not the only protocol in the universe....

it is ok with me to use different enum entries for sip and other
protocols.  my comment was about the usefulness of having several
entries for sip (voice, video, im, presence, ..) since we one entry
with caller preferences solves the problem in a better way.

-- juha

---

From: Michael Mealling <[email-masked]>
Date: 06 Mar 2003 15:25:10 -0500

> with caller preferences solves the problem in a better way.

But the point (and realities) of others is that it is proving impossible
to actually do that due to policies associated with who controls that
SIP gateway. Its also the case that many  will want to support SIP in a
limited sense for a particular application instead of the entire SIP
standard. One entry with caller preferences assumes SIP is my preferred
method when that is not true in my case or many others. You're assuming
SIP is the primary method when what Rudi and I are assuming is that its
a non-preferred, minimalist gateway function to provide interoperability
with those who only have SIP for some reason.

Rudi wants a way of saying "ok, use SIP if you have to but it only works
for voice and its not the best choice for interacting with this system".
Just telling him to chunk it all use SIP everywhere isn't solving his
problem.

-MM