Subject: [Enum] draft-livingood-enum-videomsg-00

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 4 Sep 2007 11:33:46 -0400

Given that the WG is winding down, and that the co-authors of this new I-D wish to make substantive progress before IETF 70, we are requesting approval of the WG chairs to make this an official WG draft.

http://www.ietf.org/internet-drafts/draft-livingood-enum-videomsg-00.txt

Regards
Jason Livingood

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

---

From: [email-masked]
Date: Tue, 4 Sep 2007 14:55:21 -0400

From: "Livingood, Jason" <[email-masked]>

   Given that the WG is winding down, and that the co-authors of this
   new I-D wish to make substantive progress before IETF 70, we are
   requesting approval of the WG chairs to make this an official WG
   draft.

What's the difference between videomsg and voicemsg?  Do we really
need a separate ENUM resolution for both of them, or could we use
media negotiation (like is done elsewhere in SIP)?

Dale

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 13 Sep 2007 16:16:56 -0400

This is a great question, and one the authors stuggled with mightily.  I
believe you could make such an arguement, essentially since SIP can
obviously negotiate endpoint capabilities and determine if it is a video
or voice session.  (call it mmsg for media message if you like)

However, one of the concerns we surfaced is that it is possible that the
server infrastructure in SP networks supporting these messaging services
is separate, which may make it useful to be able to determine if it
should go to a video or voice messaging server, rather than use some
intervening network element to further proxy the communication and
determine where to direct the session. 

But good point.  Any other thoughts on this??

Jason

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, September 04, 2007 2:55 PM
> To: [email-masked]
> Subject: Re: [Enum] draft-livingood-enum-videomsg-00
> 
> What's the difference between videomsg and voicemsg?  Do we 
> really need a separate ENUM resolution for both of them, or 
> could we use media negotiation (like is done elsewhere in SIP)?
> 
> Dale
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Sep 2007 16:48:59 -0400

> But good point.  Any other thoughts on this??

Who is making the decision about which type to choose from enum? If its 
not the UAC then how does it know which it wants? And does your answer 
differ if the INVITE doesn't contain an offer?

While you're at it, don't forget there is other media than voice and 
video. At least there is MSRP and real time text. The advocates for real 
time text will be on you if you don't support that.

	Paul

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 13 Sep 2007 15:39:04 -0600

> >> could we use media negotiation (like is done elsewhere in SIP)?
Providing the granularity could be beneficial for some use cases.
One example is providing end-user control of what type of message to
leave before call attempt when both the caller and caller's UA can
support voice+video:
	- Alice and Bob both have a mobile terminal with video
capability.
	- Alice calls Bob's mobile using an e164 and Bob's UA returns
busy
	- Alice's terminal pops up a dialog box asking her if she
prefers to leave a voice or video mail...
	- and there are days or even time of days when Alice might
prefer leaving a voicemail.
Sure you can implement this example by letting the UAs start
offer/answer to figure out what the capabilities of the UAs and then
prompt the end-user.
Another example is one where Alice wants to leave a video msg to Bob and
Bob's mobile does not support video but he has configured his user
profile to accept video messages on his PVR at home. In this case, media
negotiations would only result in voice and not allow the caller
preference for video (or it might if ...).

> time text will be on you if you don't support that.
I won't speak for the MSRP case but for real-time, *conversational*
text, I am not sure I understand the use case though. Wouldn't the
caller use an IM/sms uri to leave a text message? 
May be some folks do want to see what people write character by
character when writing a text message, including the characters they
delete and words they rewrite before confirming the message to be sent.

Jean-Francois.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, September 13, 2007 2:49 PM
> To: Livingood, Jason
> Cc: [email-masked]; [email-masked]
> > This is a great question, and one the authors stuggled with
mightily.
> I

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Sep 2007 18:49:57 -0400

> offer/answer to figure out what the capabilities of the UAs and then

Alice's *preference* for what to use shouldn't be impacted by what is in 
the e164 registry. What is thought to be possible might be. That is 
actually an issue here. If an attempt was made to call Bob's mobile, the 
fact that it only had voice should also not impact Alice's preferences 
when failing over to another device.

If Bob actually had *separate* VMs, one for audio, and a different one 
for audio+video, then if Alice prefers to have video the choice is 
obvious. But *why* would Bob have separate ones when audio is a subset 
of audio+video? That makes no sense.

Its more significant if the enum db was being used like a registrar - 
with multiple devices having differing capabilities all registered. Then 
Alice may want to select which one to use based on her capabilities.

But these selections by Alice only work for *user* enum. And if that is 
what we are talking about then this is starting to sound very much like 
callerprefs and callee capabilities revisited, but only for phone 
numbers. We could easily make a case that callerprefs and callee 
capabilities *ought* to be revisited, but not just for phone numbers. 
And I can warn you - it is a swamp.

> preference for video (or it might if ...).

Much like above. But the preferences are really tricky to decide:

- would alice rather talk live to bob, or leave a message with video?

I can't even imagine how to provision a phone with a policy for that 
kind of decision that would work better than a random choice. I think it 
needs to be offered up to the caller to choose. It then starts to look 
like presence.

> delete and words they rewrite before confirming the message to be sent.

I got flamed enough to know this is a very sensitive issue to some 
people. It would seem logical that character by character text or 
message by message text is irrelevant when leaving a message. But it 
does matter if the caller's device only supports one of them, or if the 
device of the callee when retrieving the message only supports one.

I would think that the internal storage format could be the same for 
both if there is support for "transcoding" to either protocol.

But either way, hopefully text will be just another medium, so it ought 
to fit in here with the others.

	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Sep 2007 21:24:29 -0400

Again ..the discussion over these issues once again highlights that this is
a relevant document to discuss as a WG document. 

Any objections?

>  Sent: Thursday, September 13, 2007 6:50 PM
>  To: Jean-Francois Mule
>  Cc: [email-masked]; [email-masked]; Livingood, Jason
>  >>> However, one of the concerns we surfaced is that it is possible
>  that
>  >> the

---

From: lconroy <[email-masked]>
Date: Fri, 14 Sep 2007 03:32:34 +0100

Hi esteemed co-chair, folks,
  I think that it is eminently suitable as a WG draft.
It seems a perfectly reasonable idea (and draft) to me.
How soon can this be turned around?

[BTW, the guideline document already gives a lot of guidance on how  
Enumservices should be categorised.
  I would be uncomfortable if that document added much on censoring  
an Enumservice proposal because it
  didn't fit the one true way of doing things. We wouldn't have SIP  
if that had been the case in the past
  - whether H.323 was all we needed was a very hard question for the  
IETF in '96-'97]

all the best,
   Lawrence

On 14 Sep 2007, at 02:24, Richard Shockey wrote:
>>  Alice's *preference* for what to use shouldn't be impacted by  
>> what is
>>  in
>>  kind of decision that would work better than a random choice. I  
>> think
>>  it

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 14 Sep 2007 03:36:19 -0600

Hi Paul,

You wrote:
> the e164 registry. 
But in some cases, I do see a negative if the "e164 registry" were
provide information that might help meet Alice's preference without even
having to call Bob.

> of audio+video? That makes no sense.
Why constraint Bob's choice? There are real life scenarios today for why
many of us have to deal with various multimedia mailboxes and why some
are audio-only, while others are audio+video. It may make no sense to
you but why not allow mechanisms for Bob to deal with it?

> It would seem logical that character by character text or
> message by message text is irrelevant when leaving a message. 
This was the point I meant.

> But it
Now, you are diverging: we should separate message deposit from message
retrieval and how the latter is linked with device capabilities should
not necessarily impact how the former is made possible. 

Jean-Francois.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 14 Sep 2007 03:38:24 -0600

> But in some cases, I do see a negative if the "e164 registry" were
                         ^ not 

> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Friday, September 14, 2007 3:36 AM
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]; Livingood,Jason
> Subject: RE: [Enum] draft-livingood-enum-videomsg-00
> 
> Hi Paul,
> 
> You wrote:
> > Alice's *preference* for what to use shouldn't be impacted by what
> is
> > in
> > the e164 registry.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Sep 2007 09:52:20 -0400

> not necessarily impact how the former is made possible.
I think you have a problem here anyway.

If I'm a deaf caller and I send an INVITE with a real-time text codec, and
the call gets diverted to a text-mail system, then are you expecting the
offer to be refused, and the answer to only supply message-at-a-time
options?

What if I have different clients for IM then real-time text?

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2007 16:18:30 -0400

> What if I have different clients for IM then real-time text?

Yeah, this is what I was getting at.

 From a practical perspective it probably does make sense for the RTT 
devices to also support IM, because there will be lots of cases where an 
IM call is the only alternative to no call, even if the RTT is 
preferred. Such devices would preferably always offer both in order to 
maximize the chances of call success. Also, it seems like it would be 
quite straightforward for a UI that supports RTT to also support IM.

But that doesn't mean that is what will get deployed. If any RTT devices 
without IM support get out there, then I imagine there would strong 
pushes for answering systems to support them.

Even if every device that supports RTT also supports IM, that would at 
least drive a demand that answering systems that support voice support 
either RTT or IM or both.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Sep 2007 16:44:32 -0400

Yeah, and we need another enum service or two if we're differentiating voice
from video.

Which, I think, is pretty ridiculous, but if we're going down that path,
then we need one for every possible kind of media.

What do you do if you offer video+audio+real time text+im?  In particular,
is it the origination network that decides what mailbox service you get or
the termination side?  If it's done with enum, then it's the origination
side, which makes the enum dip to route the call, that decides.

That means the recipient, who has all of these services, doesn't decide how
they are used, other than possibly controlling what services are advertised
in the enum zone.

> Sent: Friday, September 14, 2007 4:19 PM
> To: Brian Rosen
> Cc: 'Jean-Francois Mule'; [email-masked]; [email-masked];
> 'Livingood, Jason'

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2007 18:41:09 -0400

Brian,

You and I are on the same page here!

Who chooses depends on whether this is user enum or infrastructure enum 
I guess. If its infrastructure enum used at the terminating side then 
the policies are recipient policies. But because the data is coming from 
enum, it seems likely that it will have to be the same policy for all of 
the provider's subscribers.

If its user enum, then it is the caller that is choosing. I guess that 
is ok, if the user decided to put all that stuff in there for the caller 
to choose from.

As you note, the problem with this scheme is that it doesn't seem to 
provide a way to indicate a target for combinations. I guess you can 
enter the same URL several times, for: audio, video, im, rtt, etc. And 
then the caller can gather all of those and cluster them by URL to 
figure out what combinations are supported. Ugh!

When applied at the infrastructure side this is a lot like callee 
capabilities. It would be a lot simpler if you could simply enter a sip 
URL *with* the capabilities as a single enum entry. But I think that is 
not possible, because the output of enum is just a URL, but the sip 
capabilities are represented as *header* parameters and so not part of 
the URL.

When applied at the user enum side, this is a lot like presence.

My biggest problem is that I see phone numbers and sip urls not as 
layers but simply as alternative forms of addressing the same pool of 
potential callees. So I think there should be a common mechanism for any 
problem that comes down to choosing among alternative targets for a 
given address. Whether I call sip:[email-masked] or tel:+19785551881 
I still need to potential to fail over to voicemail if there is no 
answer. A different mechanism based on address type is a liability.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 15 Sep 2007 10:23:16 -0400

Yah

A nit though.  With infrastructure enum, conventionally, the origination
carrier uses infrastructure enum to discover a route to the destination
carrier.  The destination carrier gets to decide what URIs to put in the
zone, but it would be the origination side which decided which of these URIs
to follow if there was more than one.  Since the query doesn't have the
media "offer", there isn't any cleverness possible in what is returned from
the query.

Brian

> Sent: Friday, September 14, 2007 6:41 PM
> To: Brian Rosen

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 15 Sep 2007 10:52:06 -0400

So whats your point ?  What you are doing is reducing the aggregate number
of invites to the destination carrier since you may have narrowed your
service search parameters to those advertised.

>  From: Brian Rosen [mailto:[email-masked]]
>  Sent: Saturday, September 15, 2007 10:23 AM
>  To: 'Paul Kyzivat'
>  Cc: [email-masked]; 'Livingood, Jason'; [email-masked]
>  > > Yeah, and we need another enum service or two if we're
>  differentiating
>  > voice
>  > > from video.
>  > >
>  > > is it the origination network that decides what mailbox service
>  you get
>  > or
>  > > That means the recipient, who has all of these services, doesn't
>  decide
>  > how
>  > >>>>> does matter if the caller's device only supports one of them,
>  or if
>  > >>>>> the
>  > >>> If I'm a deaf caller and I send an INVITE with a real-time text
>  codec,
>  > >> and
>  > >>> the call gets diverted to a text-mail system, then are you
>  expecting
>  > the
>  > >> devices to also support IM, because there will be lots of cases
>  where
>  > an

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 15 Sep 2007 10:58:40 -0400

Paul this discussion is excellent but you have not answered my practical
question of what are, if any, the policies  the IETF should have regarding
what strings should or should not be Enumservice registrations. Should we
have a separate ones for user vs infrastructure or just let 10,000 flowers
bloom ..

You are dancing around the issue without confronting it. 

>  differentiating voice
>  decide how
>  >>>>> does matter if the caller's device only supports one of them, or
>  if
>  >>>>> the
>  expecting the
>  where an

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 15 Sep 2007 13:36:05 -0400

> capabilities are represented as *header* parameters and so not part of

I'm not sure that having multiple as separate entries is such a bad thing.
But if I understand it correctly, can't one have multiple enumservice types
in one record?  So for instance: "E2U+voicemsg+videomsg:sip".

> answer. A different mechanism based on address type is a liability.

I think I share your view in general, but I don't see how that is
contradictory to these drafts registering these enum services.  The draft is
not suggesting that you can't fail over to voicemail for a generic sip url.
This is the enum wg, and by definition enum is for phone numbers.  The
registration database for generic sip user urls is controlled by the target
user's domain's registrar, and there is no protocol defined for accessing
that DB directly (well, other than diameter by some other standards groups).
The method by which a proxy or registrar retrieves the end-user's
capabilities or preferences from the DB is not defined, except for phone
numbers through enum.

Obviously having this type of info in enum allows a call flow to happen that
can't for generic sip urls; for example, I can have my voicemail be hosted
by a completely different domain than my mobile, and someone wanting to
leave me a voicemail only, could send it directly to the other domain
without sending a sip request to my mobile one to be redirected.  But I
don't see how that type of difference matters - by the very existence of
enum, there is a different "mechanism" for phone numbers than generic sip
urls.

-hadriel

---

From: lconroy <[email-masked]>
Date: Sat, 15 Sep 2007 18:51:52 +0100

Hi Howard, folks,
  You beat me to it.
One sure can (but not quite with your syntax).
For example, cell phones could WELL have a service field of
  "e2u+voice:tel+sms:tel".
Thus in your case it would be e2u+voicemsg:sip+videomsg:sip"
It works for me.
For the rest of this thread, I roll my eyes.

all the best,
   Lawrence

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 15 Sep 2007 14:00:48 -0400

Yup, I was just about to correct myself. (after actually looking at 3761
abnf)
:)
-hadriel

> From: lconroy [mailto:[email-masked]]
> Sent: Saturday, September 15, 2007 1:52 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; 'Paul Kyzivat'; 'Livingood,Jason';
> [email-masked]

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 15 Sep 2007 20:03:45 +0200

Hi all,
 
following this discussion, I have a serious problem that we are ever be able 
to create a document for ENUM service registrations and to close this WG
I just remember "unused" (and others), which is still in linbo.
 
An ENUM service shall describe the mapping of a E.164 number to 
a URI. period
 
Is there any shortage in alphanumeric strings that we have to consider?
 
IMHO everybody should be able to describe such a mapping - the usefulness
will be shown in practice.
 
A client need not to understand all enumservices defined, only yhe one it
may be able to use
 
There is alo ne need to define if an enumservice is to be used in user ENUM
or infrastructure ENUM, this will also shown in practice
 
So we should step on or two steps back and simply allow ENUM services
to be defined, they should be checked only if the are correctly defined.
The usefulness will be shown in practice
 
regards
Richard

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Sa 15.09.2007 16:58
An: 'Paul Kyzivat'; 'Brian Rosen'
Cc: [email-masked]; [email-masked]; 'Livingood,Jason'
Betreff: RE: [Enum] draft-livingood-enum-videomsg-00

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2007 10:34:22 -0400

> have a separate ones for user vs infrastructure or just let 10,000 flowers

Well, with some misgivings, I guess I must go with letting some 10s of 
flowers bloom. (We are in big trouble if there O(10k) of these things. I 
don't think DNS can deal with that.)

I think the problems I have here are not with *defining* these usages. 
The problem is with proper use (and non-use) of them. I don't see any 
way to deal with that here.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2007 10:39:55 -0400

> Thus in your case it would be e2u+voicemsg:sip+videomsg:sip"

Interesting. That makes this a lot more like callee capabilities, though 
it is limited to binary feature tags.

I'll just warn you that having started down that path, you may find it 
to be the same slippery slope that callerprefs became. The initial draft 
of callerprefs was very simple - naively so. It became the mess that it 
ended up by trying to remove ambiguity and cover the cases that were 
thought to be within its scope.

	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 17 Sep 2007 15:56:19 -0400

Well as for the slippery slope ..I guess we will all need a toboggan.  

There is sufficient evidence here to have these documents ruled in scope.
Barring any further strong objections, it is the view of the chairs that
there is rough consensus that these should be ENUM WG documents. I'd suggest
that the two be combined into one document since the are sufficiently
related.

---

From: Peter Koch <[email-masked]>
Date: Mon, 17 Sep 2007 22:06:28 +0200

> Is there any shortage in alphanumeric strings that we have to consider?

no, but that's also true for, say, email header fields or media types.
Still, interoperability is key here and having multiple competing service
types for similar or identical uses does not provide for enough guidance
for implementors and operators/users.  Even more so as long as all these
services finally end up as Proposed Standards.

-Peter

---

From: [email-masked]
Date: Mon, 17 Sep 2007 17:18:11 -0400

From: "Jean-Francois Mule" <[email-masked]>

Why would media negotiations only result in voice messaging?  If the
original INVITE (specifying both voice and video) is forked to the
messaging service, the messaging service would know that video was
desired.

IMHO, the whole concept of listing messaging services separately in
Enum is ill-advised.  SIP has done a great deal of work to allow
distributed selection among a dynamic, prioritized set of recipients
with varying capabilities.  Trying to force that choice onto the
originating UA at the *start* of the call is just going to make it
work worse.

Listing voice and video messaging *separately* in Enum (and so
requiring that any other type of messaging must further be listed
separately) just amplifies these failure modes.

Dale

---

From: lconroy <[email-masked]>
Date: Mon, 17 Sep 2007 23:06:23 +0100

Hi Dale, folks,
  Frankly, I have been waiting for this thread to wither so we can deal
with the few typos in the documents and get some clarification.
Just when you thought it was safe to go out on the streets...

I understand the concerns over slopes, but this is the ENUM WG, not SIP.
Nor is it SIPPING (we have SPEERMINT for that).

I like these drafts.
I concur that these are dead on appropriate for ENUM.

If you want full blown IMS with all of the service features that  
entails,
then the SIP Enumservice is fine. You get what the IMS provider offers.

In this case, however...
The use cases in the docs are more detailed than I think is needed, but
being able to indicate that this contact will get you to a server that
will allow you to leave a message (or to retrieve messages left for you)
is precisely what ENUM publication is about. It is a specific kind of
human interaction.

Do I think this is a worthy service, likely to be of widespread use and
widely understood? Absolutely. I don't think this is a waste of a string
and IANA's time in making a registration.

I for one would dearly like this service to be available - I know how  
to use
it to fire up any of my minimal dumb SIP clients to do what I want to  
do.
If the registrant publishes the information, it's my choice whether  
to use it
or another or give up and use none of them.
Oh, and I can do that right now, with pretty much any 3261 compliant  
UAC.
Heck, an old 2543-compliant UAC will do.

To suggest that SIP can do everything may be true. To suggest that this
means that there is no need for any indication that this particular URI
will get you to this kind of B2BUA that is providing this kind of  
service
is horse feathers.

The real question for the ENUM WG is:

   Can I, as an implementer, understand what will happen if I follow  
this URI?
   From these drafts, do I know what kind of teleservice I will get  
if I use a
   NAPTR with these service fields?

I think, for voicemsg, the answer is undoubtedly yes. The use cases  
indicate
that this is going to get you to a B2BUA that provides a very  
specific service.

For videomsg, I think so (at least for videomsg:sip).
I'm not completely sure for videomsg:tel. You may notice that we left  
out
video:tel from the voice:tel RFC (it was there in the earlier vovi  
drafts)
- that was to avoid having to specify exactly WHAT kind of interface  
would
be used.

However, that discussion will have to wait for the next round of the
draft(s) as a WG item. For now, we return you to your normal station.

all the best,
   Lawrence

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2007 18:47:29 -0400

lconroy wrote:
> If you want full blown IMS with all of the service features that entails,
> I for one would dearly like this service to be available - I know how to 
> use
> it to fire up any of my minimal dumb SIP clients to do what I want to do.
> If the registrant publishes the information, it's my choice whether to 
> use it
> Oh, and I can do that right now, with pretty much any 3261 compliant UAC.

I appreciate your point of view. But I'm not sure I understand your 
usage model.

It sounds like you have UAs that are enum clients and give the user an 
interface to user enum - offering the choices. Is that right? It doesn't 
seem like something that your average UA provides.

	Paul

> will get you to this kind of B2BUA that is providing this kind of service
> is horse feathers.
> 
>   Can I, as an implementer, understand what will happen if I follow this 
> URI?
>   From these drafts, do I know what kind of teleservice I will get if I 
> use a
> that this is going to get you to a B2BUA that provides a very specific 
> service.
> 
> I'm not completely sure for videomsg:tel. You may notice that we left out
> video:tel from the voice:tel RFC (it was there in the earlier vovi drafts)
> - that was to avoid having to specify exactly WHAT kind of interface would
> be used.
>

---

From: lconroy <[email-masked]>
Date: Tue, 18 Sep 2007 01:19:32 +0100

Hi Paul, folks,
  First, an admission: I hate being bounced to a voicemail service
without warning. Most of my phone minutes are spent two seconds
at a time clearing when I get to VM.
Conversely, there are times where I WANT to leave a VM and NOT
to disturb the destination/callee in a meeting or in the middle
of the night.

  Yup - having an ENUM client that displays the choices, and that
fires up comms programs as needed when a choice is selected by
the user, is certainly one way to go. We have an ENUM client
program on PCs, Macs, and mobile phones that does just this.
In that case, the SIP UAS is just a program, as is Skype, as is ...

There are other options -
I would love a comms program that uses just this Enumservice to
know my usual dislike of unintended VM, and never try another
option if the main SIP (or voice:tel) one failed, or, as the
mood takes me, go straight to leaving a VM (especially when
the person I'm trying to call is asleep at 3AM their time).

As a customer, I'd like an ENUM-aware comms service that did
this for me (they don't, but they could). That's another option.

Oh, and my head hurts trying to work out the caller/callee prefs
*provisioning* and use on both sides for VM - ENUM is way easier
and covers my simple needs.

Beyond that, how or if this NAPTR is used is a local choice,
and so out of scope for ENUM. As long as it's clear how to
advertise the feature, and it's clear what is expected to
happen if you select the URI, we're done.

all the best,
   Lawrence

On 17 Sep 2007, at 23:47, Paul Kyzivat wrote:
> lconroy wrote:
>> I for one would dearly like this service to be available - I know  
>> how to use
>> If the registrant publishes the information, it's my choice  
>> whether to use it
> It sounds like you have UAs that are enum clients and give the user  
> an interface to user enum - offering the choices. Is that right? It  
> doesn't seem like something that your average UA provides.
>
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2007 23:20:23 -0400

Lawrence,

I also hate being bounced to VM, and conversely would sometimes like to 
go direct to VM. You will note that there are use cases for these in the 
callerprefs usecases RFC.

We haven't got much dialing by SIP URI yet, at least for any signficant 
percentage of voice calls. But I certainly expect that to change 
eventually. I hope sooner rather than later. We are rapidly getting 
devices that are alphanumeric capable, and that generally dial from 
stored addresses rather than entered addresses. Mnemonic names seem far 
preferable in the long term.

That is why I would like to see the same mechanism for alternatives 
regardless of whether the address is E.164 or not.

More inline.

> the person I'm trying to call is asleep at 3AM their time).

This of course depends on user enum. At least you seem to have that. It 
seems the SPs here in +1 that will never be. (I expect SPs don't want it.)

> and covers my simple needs.

It is true that callerprefs is too hard for simple use. It certainly 
makes no sense for human callers to explicitly specify their preferences 
anything like callerprefs specifies it.

In reality, the enum stuff is much more like presence, in that it is 
published by/for the UAS, and made available to the caller before he 
initiates a call. Presence *can* expose multiple contacts and the 
attributes of each. But all the details are different.

I guess I can see how a UAC could hide the differences under the covers 
- using presence for non-e.164 addresses and for e.164 addresses that 
have it, and enum for e.164 addresses without presence.

For this to work well it will require some notion of public presence, 
rather than just presence for buddies.

As I have said - I recognize the problems with callerprefs, and so don't 
see it as a major part of a solution here. But I do think having a 
consistent approach for both kinds of addresses is important. It would 
be good to have a discussion about the role of presence here - if others 
see that as a solution.

	Thanks,
	Paul

>> interface to user enum - offering the choices. Is that right? It

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:48:05 -0400

Thanks, these I-Ds will now be combined and we'll integrate some of the
other feedback here as well.  We should have a draft for review within a
week or so - the co-authors just need to interate the combined document
a bit.

Jason 

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 3:56 PM
> To: 'Paul Kyzivat'; 'lconroy'
> Cc: [email-masked]; [email-masked]; Livingood, Jason; 
> 'Hadriel Kaplan'
> Subject: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg
> 
> 
> Barring any further strong objections, it is the view of the 
> chairs that there is rough consensus that these should be 
> ENUM WG documents. I'd suggest that the two be combined into 
> one document since the are sufficientlFrom [email-masked] Tue Sep 18 08:52:47 2007
Content-class: urn:content-classes:message
Date: Tue, 18 Sep 2007 08:48:05 -0400
From: "Livingood, Jason" <[email-masked]>
To: "Richard Shockey" <[email-masked]>,
	"Paul Kyzivat" <[email-masked]>, "lconroy" <[email-masked]>
Cc: [email-masked], [email-masked],
	Hadriel Kaplan <[email-masked]>
Subject: [Enum] RE: In scope for ENUM -
	draft-livingood-enum-videomsg-voicemsg

Thanks, these I-Ds will now be combined and we'll integrate some of the
other feedback here as well.  We should have a draft for review within a
week or so - the co-authors just need to interate the combined document
a bit.

Jason 

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 3:56 PM
> To: 'Paul Kyzivat'; 'lconroy'
> Cc: [email-masked]; [email-masked]; Livingood, Jason; 
> 'Hadriel Kaplan'
> Subject: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg
> 
> 
> Barring any further strong objections, it is the view of the 
> chairs that there is rough consensus that these should be 
> ENUM WG documents. I'd suggest that the two be combined into 
> one document since the are sufficiently related.
> 
> >  
> >  I'll just warn you that having started down that path, you 
> may find 
> > it  to be the same slippery slope that callerprefs became. 
> The initial  
> > draft  of callerprefs was very simple - naively so. It 
> became the mess 
> > that  it  ended up by trying to remove ambiguity and cover 
> the cases 
> > that were  thought to be within its scope.
> >  
> >  	Paul
> >

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:48:05 -0400

> So we should step on or two steps back and simply allow ENUM 
> services to be defined, they should be checked only if the 
> are correctly defined.

Here-here, strongly agreed!  :-)

Jason

y related.

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:48:05 -0400

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:47:52 -0400

> My biggest problem is that I see phone numbers and sip urls 
> not as layers but simply as alternative forms of addressing 
> the same pool of potential callees. So I think there should 
> be a common mechanism for any problem that comes down to 
> choosing among alternative targets for a given address. 
> Whether I call sip:[email-masked] or tel:+19785551881 I 
> still need to potential to fail over to voicemail if there is 
> no answer. A different mechanism based on address type is a liability.

It may also be the unavoidable reality of what is happening today (for
lots of potentially good reasons), and we can choose to ignore this or
not.  :-)

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:47:52 -0400

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:48:04 -0400

> Which, I think, is pretty ridiculous, but if we're going down 
> that path, then we need one for every possible kind of media.
> 
> What do you do if you offer video+audio+real time text+im?  

Maybe.  But I think your arguement assumes that ENUM records, or the
size of the data set in the servers is somehow constrained or is
otherwise a scarce resource.  In a small 1U server in my network today I
can handle far, far, far more ENUM records than anyone has dreamed up.
And by the time someone does come up with that many, software and
hardware will be ahead of the problem, or creative developers and
engineers will adapt and innovate.  

I say, the more in ENUM/DNS, the better.  It is an open query/response
method and the servers are generally pretty open as well.  The
alternative has and continues to be proprietary, less open / closed, and
generally more expensive (IMHO).

Jason

 ([24.40.8.146])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVK-00069S-2z
	for [email-masked]; Tue, 18 Sep 2007 08:48:44 -0400
Content-class: urn:content-classes:message
Subject: RE: [Enum] draft-livingood-enum-videomsg-00
Date: Tue, 18 Sep 2007 08:48:04 -0400
From: "Livingood, Jason" <[email-masked]>
To: "Brian Rosen" <[email-masked]>,
	"Paul Kyzivat" <[email-masked]>
Cc: [email-masked], [email-masked]

> Which, I think, is pretty ridiculous, but if we're going down 
> that path, then we need one for every possible kind of media.
> 
> What do you do if you offer video+audio+real time text+im?  

Maybe.  But I think your arguement assumes that ENUM records, or the
size of the data set in the servers is somehow constrained or is
otherwise a scarce resource.  In a small 1U server in my network today I
can handle far, far, far more ENUM records than anyone has dreamed up.
And by the time someone does come up with that many, software and
hardware will be ahead of the problem, or creative developers and
engineers will adapt and innovate.  

I say, the more in ENUM/DNS, the better.  It is an open query/response
method and the servers are generally pretty open as well.  The
alternative has and continues to be proprietary, less open / closed, and
generally more expensive (IMHO).

Jason