Subject: Re: [Enum] RE: The larger issue here.

From: Otmar Lendl <[email-masked]>
Date: Wed, 7 Feb 2007 13:21:16 +0100

On 2007/01/31 21:01, Jim Reid <[email-masked]> wrote:
> On Jan 31, 2007, at 20:06, Richard Shockey wrote:
> 
> >>>I suspect it will be like many of the routine IANA procedures with
> >>>a expert committee appointed
> >>
> >>FWIW, this mirrors a similar concern in the dnsop WG. There the issue
> >>is getting a lightweight procedure for issuing codes for new resource
> >>record types. The WG is debugging a process that involves an expert
> >>(singular) making a determination. I think this model may well be a
> >>good idea for this WG too.
> >
> >Hummm interesting. What does the text look like for the procedure?
> 
> See RFC2929bis. The DNSEXT co-chairs appointed one of your  
> colleagues, Ed Lewis, to be the expert reviewer.

We're test-driving that process with the EBL draft.

Ed has found some issues with the guidelines in the 2929bis draft
(see http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00078.html)
and he has been equally critical regarding the EBL / I-ENUM specs.

There are still kinks to work out in that process (e.g. is the expert
supposed just to weed out obvious non-sense and formally incorrect
proposals, or is he supposed to only let through top-notch proposals?),
so the jury is still out on how that setup works in the real world.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 16 Feb 2007 16:32:15 -0500

First off, do not interpret my comments as saying your I-D may not move
forward.  There are all sorts of enumservices and not everyone needs to
agree with each one.  If you have a valid app, put in an I-D so the
community can really comment and add to your idea.  

My comments simply come from the perspective of an implementer.  I
operate a SIP-based IP voicemail system in my group with a very large
number of mailboxes and was just considering this question of exchanging
voicemail between service providers.  

You are correct in pointing out that many voicemail providers do not
support VPIM.  When I personally looked at how to connect
non-VPIM-compliant systems it seemed a bit of a pain compared to ones
that were VPIM-compliant.  But I will tell you that I don't know of any
big implementations out there using VPIM at scale (if anyone does -
please chime in).  It seems to be one of those things some software
companies decided to support but no one is making much use of now.
Whenever I have seen that, even these early s/w implementations may not
work right in version 1.  I think that will change in the next few years
as providers peer real-time traffic.  It may even be that non-real-time
traffic like voicemail is a way to dip the toe into the water, so to
speak.  

A non-VPIM draft could certainly have value to some folks and who knows,
may even win out in the marketplace of implementers in the end.  I would
actually ENCOURAGE you to submit a draft.  Getting a lot of feedback is
actually GOOD.  You should be more worried when you hear silence.  ;-)

I am happy to help review the doc before or after submission and add
some use cases or other content or whatever to it if you like.

Jason Livingood

> -----Original Message-----
> From: Jackson, James [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 11:56 AM
> To: [email-masked]; Stastny Richard; Paul Kyzivat
> Cc: [email-masked]
> Subject: RE: [Enum] The larger issue here.
> 
> 
> It's fair for the IETF to assume that Unified Messaging 
> platforms supporting voicemail/fax/e-mail should all do VPIM. 
> However, I wouldn't say it's correct to assume that all 
> voicemail systems will be Unified Messaging platforms, or for 
> that matter that voicemail and e-mail would even necessarily 
> be provided by the same entity.
> 
> Would the enumservices fax (for PSTN) and voice (for PSTN) be 
> considered standards ? I suppose we could call T.30 the 
> standard for fax. So then this looks more like the voice 
> service but for non-interactive sessions.
> Perhaps an alpha-pager using the TAP protocol would be fine 
> since there is a more defined application-level standard ?
> 
> Based on the feedback, I don't think I'll be submitting a 
> draft :) I just want to understand the logic for why a 
> particular contribution would or would not be useful. I 
> apologize if this discussion is viewed as disruptive to the 
> group. Anyone can certainly respond to me off-line if they like.
> 
> James
> 
> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2007 9:59 AM
> To: Jackson, James; 'Stastny Richard'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: [Enum] The larger issue here.
> 
> 
> Because the IETF defines the voice mail service for the PSTN 
> as the VPIM
> standard. We generally don't go around creating enum services 
> for things
> that are not defined as a standard.
> 
> Frankly,  from the comments you are seeing I would not be 
> optimistic on
> the
> chances a draft along the lines you propose would make it through the
> WG.
> 
> > -----Original Message-----
> > From: Jackson, James [mailto:[email-masked]]
> > Sent: Tuesday, January 30, 2007 10:58 PM
> > To: [email-masked]; Stastny Richard; Paul Kyzivat
> > Cc: [email-masked]
> > Subject: RE: [Enum] The larger issue here.
> > 
> > 
> > That's fine. RFC4238 works great if the voicemail system implements
> VPIM
> > - most do not. The VPIM service defines e-mail access to voicemail
> much
> > like the ifax service defines e-mail access to fax. 
> However, there is
> > also a fax service for PSTN. If someone could shed some 
> light on why a
> > voicemail service for PSTN is unreasonable that would be 
> appreciated.
> > 
> > Thanks,
> > James
> > 
> > -----Original Message-----
> > From: Richard Shockey [mailto:[email-masked]]
> > Sent: Tuesday, January 30, 2007 9:20 PM
> > To: 'Stastny Richard'; 'Paul Kyzivat'
> > Cc: [email-masked]
> > Subject: [Enum] The larger issue here.
> > 
> > 
> > Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat 
> as well. And
> > with
> > the argument that Jason Livingood makes that this is really 
> covered By
> > RFC
> > 4238.
> > 
> > Chair hat on...
> > 
> > The larger issue is one we will need to deal with in Prague is that
> this
> > work group is winding down. With the Infrastructure ENUM 
> issues now in
> > the
> > hands of "higher authority" we have only one real task which is the
> > advancement of RFC 3761 to Draft.
> > 
> > We do need to declare victory here and start to close up shop unless
> > there
> > is compelling technical reasons not to do so and frankly I have not
> seen
> > one
> > recently.
> > 
> > 
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: Tuesday, January 30, 2007 4:03 PM
> > > To: Paul Kyzivat
> > > Cc: [email-masked]
> > > Subject: Re: [Enum] Proposal for new enumservice 
> "voicemail", using
> > SIP
> > > URI
> > >
> > > I fully support this argument
> > > Richard
> > >
> > > ________________________________
> > >
> > > Von: Paul Kyzivat [mailto:[email-masked]]
> > > Gesendet: Di 30.01.2007 20:33
> > > An: Jackson, James
> > > Cc: [email-masked]; Shawn Pouliotte; Duane
> > > Betreff: Re: [Enum] Proposal for new enumservice 
> "voicemail", using
> > SIP
> > > URI
> > >
> > >
> > >
> > > A fundamental problem I have with using ENUM is that it is
> > fundamentally
> > > tied to cases where the address of the callee is an E.164 number.
> That
> > > is fine in cases where the problem is intrinsically tied 
> to the use
> of
> > a
> > > phone number. But it is an unappealing solution to any 
> problem that
> > also
> > > applies when the callee is identified by a SIP URI. I 
> certainly see
> > that
> > > to be the case here. I just as well may want to get to the VM for
> > > sip:[email-masked] as for tel:+12125551234.
> > >
> > > BTW, that also means that indicating you want VM by prefixing the
> > > address with *99 isn't an ideal interface. I guess it is *an*
> > interface,
> > > that might be suitable for UAs that can only deal with 
> numbers. But
> > > another interface will be needed for alphanumeric calling. I don't
> > think
> > > the concept of adding to the callee's URI is appropriate in this
> case.
> > > Whatever technique does work for alphanumeric URIs would hopefully
> > work
> > > for phone numbers as well. In general a sip UA supports a 
> telephone
> > > dialing interface already needs to recognize and locally process
> some
> > > star codes, so it ought to be able to do so for this one too.
> > >
> > >         Paul
> > >
> > > Jackson, James wrote:
> > > > I have been thinking about the PSTN service in another context,
> but
> > > > perhaps it is more generally applicable here. Specifically,
> consider
> > the
> > > > case where the called number is purely PSTN and you 
> want to reach
> > their
> > > > voicemail. In theory an ENUM query could return the Call
> Forwarding
> > > > Number and the call could be forwarded out a Media Gateway. The
> > mailbox
> > > > would be indicated by the Redirecting Number.
> > > >
> > > > James
> > > >
> > > > -----Original Message-----
> > > > From: Duane [mailto:[email-masked]]
> > > > Sent: Tuesday, January 30, 2007 9:57 AM
> > > > To: Paul Kyzivat
> > > > Cc: Jackson, James; [email-masked]; Shawn Pouliotte
> > > > Subject: Re: [Enum] Proposal for new enumservice "voicemail",
> using
> > SIP
> > > > URI
> > > >
> > > > Paul Kyzivat wrote:
> > > >
> > > >> The above assumes that the VM system is arranged in a suitable
> way.
> > > >> Notably that it has a unique and globally routable URI 
> of its own
> > for
> > > >> each mailbox (possibly by a common URI plus a parameter
> identifying
> > > > the
> > > >> mailbox). Or at least that there is a single globally routable
> URI
> > for
> > > >
> > > >> the VM server and that the caller will be satisfied with having
> to
> > > > enter
> > > >> the target phone number a second time.
> > > >
> > > > While I won't go into the merits of having such an enum service,
> > > > (although couldn't it just be a sub-type of pstn?) it 
> seems pretty
> > > > trivial to me to be just another SIP URI that could easily be
> setup,
> > > > both in DNS and in most/all software driven PBXs.
> > > >
> > > > eg
> > > >
> > > > sip:[email-masked]
> > > > voicemail:[email-masked]
> > > >
> > > > On the PBX you simply look for vm- strip it and send 
> the call into
> > the
> > > > voicemail system.
> > > >
> > > > eg
> > > >
> > > > 100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\[email-masked]!" .
> > > > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\[email-masked]!" .
> > > >
> > >

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 25 Feb 2007 08:51:02 -0800

On Jan 31, 2007, at 1:41 AM, Stastny Richard wrote:

> We need also to have a procedure for x- Enumservices

Keep in mind that even if the WG is closed, one can still have AD  
Sponsored drafts move forward.

---

From: [email-masked]
Date: Wed, 28 Feb 2007 11:18:58 -0500

From: Cullen Jennings <[email-masked]>

Aren't "x-" tokens for things that aren't defined in official
documents?  If you've got a procedure for them, then they should be
using non-"x-" tokens.

Dale