Subject: [Sipping] SIP Device Configuration and RESCAP

From: Richard Shockey <[email-masked]>
Date: Mon, 25 Mar 2002 17:23:05 -0500

I know this was a rather contentious issue at the 2nd SIPPING meeting but 
I'd like this group to at least be aware of some similar work that we have 
tried for years to move on in the IETF and I like to take this opportunity 
to add the pointers to the current RESCAP work.

http://www.ietf.org/html.charters/rescap-charter.html

A cursory overview of the RESCAP charter should identify similarities 
between the Petrie SIP Device Configuration draft and the general problem 
statement. RESCAP originally looked at the problem of identifying the 
capabilities of a POP3 or IMAP end points by an SMTP client. Unified 
Messaging and other technologies essentially have to "send and pray" that 
the end point recipient user agent was capable of processing the 
attachments. The desire was to avoid circumstances where one would send PPT 
files to a hand held cellphone etc...hense the need for a combination of 
technologies that could, discover a configuration file or capabilities 
"object" of the terminating email endpoint. Upon discovery of the end point 
capabilities, the message object could be re configured or rejected by the 
originating client as appropriate.

Its rather easy to see how  RESCAP concepts or a similar class of 
technologies could be applied to the originating endpoint, in this case a 
SIP Device. The data object (configuration file) could use a different form 
of semantic than capabilities ..but the two could share many attributes 
such as discovery and transport.

I'm not suggesting this is the exact methodology SIPPING needs to look at, 
however the general problem statement is one that is well known in the IETF 
community.

############
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Capabilities Discovery Working 
Group of the IETF.

         Title           : RESCAP Scenarios
         Author(s)       : G. Klyne
         Filename        : draft-ietf-rescap-scenarios-01.txt
         Pages           : 18
         Date            : 11-Jan-02

This memo explores some scenarios for the resource capabaility
discovery protocol (RESCAP).  It is intended to provide some
grounding in specific use-cases for decisions about RESCAP goals
and design.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rescap-scenarios-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Capabilities Discovery Working 
Group of the IETF.

         Title           : The Binary Low-Overhead Block Presentation Protocol
         Author(s)       : K. Moore
         Filename        : draft-ietf-rescap-blob-01.txt
         Pages           : 22
         Date            : 05-Mar-02

This memo describes the Binary Low-Overhead Block (BLOB) protocol for
on-the-wire presentation of data in the context of higher-level
protocols.  BLOB is designed to encode and decode data with low overhead
on most CPUs, to be reasonably space-efficient, and for its
representation to be sufficiently precise that it is suitable as a
canonical format for digital signatures

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rescap-blob-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Capabilities Discovery Working 
Group of the IETF.

         Title           : The Resource Catalog
         Author(s)       : K. Moore
         Filename        : draft-ietf-rescap-rc-01.txt
         Pages           : 34
         Date            : 05-Mar-02

This memo describes version 3 of the Resource Catalog.  The Resource
Catalog (RC) is a service for storing and obtaining metadata that
describes network-accessible resources.  This service is primarily
intended for use by clients prior to accessing, or attempting to access,
a particular resource.  The RC service may thus be used (for example) to
inform a client as to which of a variety of features are supported by
the resource, or which methods may be used to access the resource, or
which of a small set of locations may be used to access the resource.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rescap-rc-01.txt

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Mar 2002 08:53:43 -0500

I don't think this applies. RESCAP (assuming it will ever reach take-off
velocity) allows random strangers to discover the capabilities of a
device; device configuration allows one device to find its own
configuration information. The security model is exactly the opposite.
RESCAP fits the model to the extent that any RPC-like mechanism would.
Yes, RESCAP is yet another IETF attempt to create a specialized version
of RPC (defined here as retrieval of structured data from a known
location).

If you take the RPC viewpoint, the protocol solution to the problem is
rather easy, reduced to defining a set of data structures in whatever
RPC environment one would like to play in. Fortunately or unfortunately,
SNMP is also an RPC-like protocol, albeit typically going in the wrong
direction (from management station to the device, rather than the other
way around).