Subject: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 18 Mar 2007 18:58:51 -0400

I read this and the companion enumservice. My comment is similar to 
Cullen - I cannot understand the use case of why we need this. Just 
because something is a parameter today in the PSTN doesn't mean we need 
it in VoIP. I'd like to see the call flows and reasons why someone would 
look at this, what they'd do with it, and how it gets set.

Also, as a general comment, I'm not sure I agree that this is a tel URI 
parameter. There is this increasing trend that says, "if I need 
parameter foo which was previously carried in ISUP, all I need to do is 
make it new foo parameter of the tel URI". In many cases these things 
are wholly inappropriate as tel URI parameters since they aren't 
qualifiers of the resource identified by the URI at all.

One litmus test on this is - does the parameter make sense if the URI 
were a SIP URI like sip:[email-masked]? If it still makes sense in 
that context you know for sure it shouldn't be a tel URI.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Mar 2007 04:58:37 -0400

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, March 18, 2007 6:59 PM
> To: [email-masked]
> Subject: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt
> 

In fact the use case is exactly the opposite. You are right is not about
VoIP but providing alternative query mechanisms for TCAP data ..we are
already there with LNP and CNAM data ..so the use case here is exactly the
same.

This is a simple ENUMservice registration. We have not forced an
applicability test on registrations nor do we see the need for one at this
point.  

> parameter. There is this increasireated, is based on arguments that I personally feel we in the
> IETF are not capable of discussing. Especially as alternative C
> people are present in the discussions. Those discussions are such
> that I think (for example) ITU-T in SG2 should discuss.
>=20
> What you should read of the note (that I stand behind that many of
> you objected to) is that I as co-chair tell IAB and IESG that I do
> not feel capable recommending the IETF to create a branch, or where
> some apex should be, of a specific kind without support from a
> combination of IAB and IESG. Plus a recommendation that many
> discussions that have been held in ENUM should be held outside of the
> IETF.
>=20
>=20

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Mar 2007 04:58:37 -0400

> that context you know for sure it shouldn't be a tel URI.

You can argue that this is not an appropriate use of TEL paramameters just
tell us what parameter should we use .. data: ???

ng trend that says, "if I need
 
> that context you know for sure it shouldn't be a tel URI.

You can argue that this is not an appropriate use of TEL paramameters just
tell us what parameter should we use .. data: ???