Re: [Sipping] SIP Device Configuration and RESCAP

[Henning Schulzrinne <[e-mail]>]

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).

Richard Shockey wrote:
> 
> 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
>

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