Subject: Re: [dispatch] terq charter revision

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Mar 2013 15:24:35 +0000

The use cases to date anyway scope TeRQ to information retrieval, not provisioning. We can make this explicit in the charter if that would be helpful. 

I have looked a bit a the relationship between this work and WEIRDS, yes. That too is something we could call out in the charter as another potential point of appropriation or collaboration. 

Jon Peterson
NeuStar, Inc.

Sent with Good (www.good.com)

 -----Original Message-----
From: 	Henning Schulzrinne [mailto:[email-masked]]
Sent:	Sunday, March 10, 2013 10:41 PM Eastern Standard Time
To:	Peterson, Jon
Cc:	[email-masked]
Subject:	Re: [dispatch] terq charter revision

Two questions/comments:

(1) It is not quite clear whether the scope is restricted to retrieval ("GET") or also updates by authorized entities ("PUT"). For HTTP, it seems relatively straightforward to specify both, less so for DIAMETER, but I don't see much of a problem with having several retrieval mechanisms.

(2) There is some relationship to the whois retrieval work, I believe. This should at least be explored.

Henning

On Mar 7, 2013, at 6:27 PM, "Peterson, Jon" <[email-masked]> wrote:

> 
> Based on the comments previously received, this is a slight revision to the TeRQ charter. The fundamentals here though are pretty much unchanged: the plan is to do the framework and information model document and one binding document, rechartering if there is interest in doing any further binding documents.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> ---
> 
> Title: Telephony-Related Queries
> Acronym: terq
> Area: Real-time Applications and Infrastructure
> Area Director: TBD
> Chair(s): TBD
> Mailing address: TBD (currently [email-masked])
> 
> Description of Working Group
> 
> Several IETF efforts have studied the handling of telephone numbers on the Internet. For example, the ENUM working group specified a DNS-based approach to transforming telephone numbers into URIs; the DRINKS working group produced a provisioning system suitable for populating Internet directories of telephone numbers. The overall goal of this work has been to migrate the routing and directory functions of the telephone network onto the Internet, in order to simplify the implementation of Internet telephony and reduce the Internet's reliance on the infrastructure of the public switched telephone network. Ultimately, the requirements for this project diverged significantly from the original architecture and applicability of ENUM. Moreover, in the twelve years since ENUM was first chartered, Internet telephony has changed a great deal. As one example, today web-based applications are becoming more significant to Internet telephony, as are intelligent mobile devices. In these env
> ironments, there exists a capacity for richer queries and responses, as well as more sophisticated application logic to process requests, but also tougher security requirements. As such, this working group reconsiders the migration of routing and directory functions from the telephone network to the Internet by generalizing the base semantics of queries and responses in an abstract framework, and then defining possible transports and encodings for these messages.
> 
> The components of the chartered work include:
> 
> 1. A framework and information model for the construction queries and responses. The information model will provide an abstract description of the semantics of the various elements and attributes that make up TeRQ messages. The framework will further establish the semantics of TeRQ transactions, describe how responses are matched with queries, and give an overview of the operation of the protocol. It will furthermore describe the overall security model of TeRQ, including confidentiality and access control measures necessary to preserve privacy.
> 
> 2. A process for specifying bindings for the information model, which comprise transports and encodings. Transports specify the underlying protocols that will encapsulate TeRQ queries and responses. This working group is not chartered to define new underlying protocols, but will specify how the transaction model of TeRQ maps onto these underlying protocols. Potential underlying protocols include HTTP and DIAMETER. The encoding determines how TeRQ elements and attributes will be rendered in the object format carried by the transport; potential object formats would include JSON and XML and well as lower-layer encodings. Binding specifications must detail their implementation of the security and privacy requirements defined in the framework.
> 
> 3. A set of one or more bindings compliant with the process described in (2), which provide a concrete instantiation of the protocol. This group will be initially chartered to create a single binding, though other may be a potential subject for ongoing work after a rechart. These bindings may accompany profiles that detail particular sets of attributes or elements relevant to a given deployment.
> 
> The TeRQ working group will coordinate with ongoing work in the DRINKS space in order to make sure that the TeRQ information model conforms with the needs of provisioning systems. Whenever possible, TeRQ will reuse existing IETF work. The syntax and semantics of telephone numbers, for example, have been the subject of a great deal of previous IETF work (notably RFC 3966), and the TeRQ working group will rely on this and related prior work. 
> 
> Goals and Deliverables:
> 
> Aug 2013	Submit Framework for Telephony Related Queries as Proposed Standard
> Nov 2013	Submit one TeRQ Binding as Proposed Standard
> Feb 2013	Recharter if additional bindings are required
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Mar 2013 13:13:40 -0400

I would consider the ability to update information (of individual records, not ranges) to be useful, particularly given that this seems less obvious than in the DNS case. Assuming something like HTTP as transport, this doesn't seem all that hard.

Henning