Subject: RE: [Enum] a suggestion re: using flags to distinguish post-ENUMs ignaling f lows

From: "Stafford, Matthew" <[email-masked]>
Date: Tue, 7 Feb 2006 17:16:26 -0600

Richard- 

Regarding
==> I thought E2U+sip:pstn
==> is pointing to a gw service already

I consulted draft-ietf-enum-pstn-03. As best I can tell from a brief
reading, the E2U+pstn records are helping you to find a media gateway for
PSTN interconnect. I'm looking specifically at 7.1(d) and 7.2(f) in the call
processing scenarios.

Maybe "g" for gateway was a bad choice in my original message. Since "s" and
"p" are already defined in non-ENUM contexts in the DDDS RFCs, I was looking
for another term (other than server or proxy). Unless I read the PSTN draft
incorrectly (or I'm looking at the wrong document altogether), I believe
that it does *not* address the following question: I've done an ENUM query
and extracted the URI from the ENUM NAPTR; how should I interpret the domain
portion of the URI? 

Also, I'm curious to see the reactions to

==> E2U+mms:mailto:mx ?
==> or mailto:[email-masked];mx=yes/no ?

==> E2U+sip:srv 
==> or sip:[email-masked];srv=yes/no

Appending ";mx=yes/no" (or ";srv=yes/no" in the SIP case) gives information
that can just as easily live outside the ENUM context. Not true of the
Enumservice approach (or, for that matter, the ENUM NAPTR flag)- both of
those are tied directly to the ENUM record.

A random thought: If one wanted to go with mailto:[email-masked];mx=yes/no,
where would the change to the mailto: URI scheme be documented? 

Best,
Matt

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 12:54 PM
To: Richard Shockey; Stafford, Matthew
Cc: [email-masked]; [email-masked]; lconroy
Subject: Re: [Enum] a suggestion re: using flags to distinguish
post-ENUMsignaling f lows

>Something like E2U+sip:pstngw
 
I thought E2U+sip:pstn
is pointing to a gw service already
 
>URI extentions or Enumservice definitions are the way to go

E2U+mms:mailto:mx ?
or mailto:[email-masked];mx=yes/no ?

E2U+sip:srv 
or sip:[email-masked];srv=yes/no
 
Richard

________________________________

Von: [email-masked] im Auftrag von Richard Shockey
Gesendet: Di 07.02.2006 19:36
An: Stafford, Matthew
Cc: [email-masked]; [email-masked]; lconroy
Betreff: Re: [Enum] a suggestion re: using flags to distinguish
post-ENUMsignaling f lows

> ==> I take your point regarding the headaches w/changes to clients.
> ==> However, I'm not sure I agree that this is limited to carrier/infra-
> ==> ENUM, at least if we think of that in terms of traditional telcos/
> ==> cellcos. For example, does this discussion really bear no relevance
> ==> to enterprise applications (e.g., I want to call into my company's
> ==> IP PBX while I'm on the road?)
>
> It appears that the proposed 'g' flag is appropriate only for SIP use
> within Carrier ENUM, so one could WELL argue that this is an issue for the
> SIP URI - I don't see how it can be used for other Enumservices (like
> email:mailto, for example). Perhaps adding a SIP parameter (akin to
;user=phone)
> would be more appropriate, or adding a new Enumservice to run alongside
the
> existing SIP one (i.e. to develop a new Enumservice definition RFC to
specify
> a SIP Gateway service)?

That would be my strong recommendation.

Something like E2U+sip:pstngw

>
> ==> That would have a similar effect to the flag proposal, in the sense
> ==> that the contents of the ENUM NAPTR offer guidance on what to do next
> ==> (which is really what I'm after)
>
> ==> For the sake of discussion, here's a similar example using the
> recently-==> standardized Enumservice mms:mailto... an 'm' flag
> indicating that the ==> NAPTR recipient should now look for an MX
> Resource Record.

Lets not even start a discussion over using the flag field ..I do't
think that will go very far. IMHO a non starter.

URI extentions or Enumservice definitions are the way to go

> all the best,
>    Lawrence
--

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
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: Klaus Darilion <[email-masked]>
Date: Thu, 09 Feb 2006 10:53:32 +0100

> ==> or sip:[email-masked];srv=yes/no

I can't follow your discussion: Why do we need a mx=yes/no parameter?

AFAIK standard SMTP applications try MX first with fallback to A. Thus, 
mx=no can be achieved just by not having an MX record for the domain.

regards
klaus