RE: [Sipping] SIP Device Configuration and RESCAP

["Blatherwick, Peter" <[e-mail]>]

Without focusing on the solution space, I think Richard's point is really we can look in other areas (outside SIP / SIPPING) for examples of problems similar in *organizational* form to the ones we need to crack regarding SIP device requirements and auto-config.  In particular, see point 4 of the RESCAP charter, which reads in part: 

  (4) Existing protocols will be profiled for use as part of this service 
  whenever possible rather than developing new protocols. ... 

The similarity is SIP device requirements and auto-config work will necessarily involve not just SIP/SIPPING (i.e. not contained cleanly within a particular WG), and will likely require us to say, in effect, of the gazillion ways to do X (implement a SIP interaction, configure a device element, whatever), do at least this one.  Most of the technologies we need already exist and are well understood, they just need to be written down in a very concise form.   

RESCAP may or may not fly (not familiar with it myself), but we should be aware that such classes of problems do exist in the real world, and are in fact critically important to solve.  If IETF has organisational issues to solve to make this possible, then we need to solve those.  In the case of SIP device requirements and auto-config, work is required to enable large scale deployment of SIP-based end user devices.   The problem is very real, and IETF is the best place to solve it.  

My 0.02, flame-proof suit on, 

Peter Blatherwick

-----Original Message-----
From: Henning Schulzrinne [mailto:[e-mail]]
Sent: March 26, 2002 08:54
To: Richard Shockey
Cc: [e-mail]
Subject: Re: [Sipping] SIP Device Configuration and RESCAP


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

_______________________________________________
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