Re: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows

["Stastny Richard" <[e-mail]>]

>Also, I'm curious to see the reactions to 

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

>==> E2U+sip:srv 
>==> or sip:[e-mail];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.

Exactly,

Peering with SIP URIs must work with or without ENUM, especially in User ENUM. The reason
is that the ENUM query may be done by the client and a SIP proxy may have no idea if
the SIP URI has been entered by the user direct or by derived from ENUM.

OTOH, since users now do not enter mailto:[e-mail];mx=yes and it works, why should
they enter SIP:[e-mail];srv=yes

The SRV s mandatory anyway

regards

Richard


________________________________

Von: Stafford, Matthew [mailto:[e-mail]]
Gesendet: Mi 08.02.2006 00:16
An: Stastny Richard
Cc: [e-mail]; [e-mail]
Betreff: RE: [Enum] a suggestion re: using flags to distinguish post-ENUMsignaling f lows



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:[e-mail];mx=yes/no ? 

==> E2U+sip:srv 
==> or sip:[e-mail];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:[e-mail];mx=yes/no, where would the change to the mailto: URI scheme be documented? 

Best, 
Matt 

-----Original Message----- 
From: Stastny Richard [mailto:[e-mail]] 
Sent: Tuesday, February 07, 2006 12:54 PM 
To: Richard Shockey; Stafford, Matthew 
Cc: [e-mail]; [e-mail]; 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:[e-mail];mx=yes/no ? 

E2U+sip:srv 
or sip:[e-mail];srv=yes/no 
  
Richard 


________________________________ 

Von: [e-mail] im Auftrag von Richard Shockey 
Gesendet: Di 07.02.2006 19:36 
An: Stafford, Matthew 
Cc: [e-mail]; [e-mail]; 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 [phone] 
PSTN Office +1 571.434.5651 PSTN Mobile [phone] 
Fax: [phone] 
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz> 
<http://www.neustar.biz> ; <http://www.enum.org> 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

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


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