|
Internet Drafts - IDs for Jan/2009
Index - Month Index of IDs
All IDs - sorted by date)
30/01/2009
| |
|
| |
| | IEEE 802.21 Mobility Services Framework Design (MSFD) |
| |
| | draft-ietf-mipshop-mstp-solution-12.txt |
| | Date: |
30/01/2009 |
| | Authors: |
Telemaco Melia, Gabor Bajko, Subir Das, Nada Golmie, Juan Zuniga |
| | Working Group: |
Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) |
| | Formats: |
txt |
|
This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for mobility service (MoS) discovery and transport layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the mobility service (MoS). Instead, it is assumed that either lower layer (e.g., link layer) security mechanisms, or overall system-specific proprietary security solutions, are used. |
| | IANA Considerations for RPC Net Identifiers and Universal Address Formats |
| |
|
This Internet-Draft lists IANA Considerations for RPC Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This Internet-Draft updates, but does not replace, RFC1833. |
20/01/2009
| |
|
| |
| | Using SHA2 Algorithms with Cryptographic Message Syntax |
| |
|
This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. |
17/01/2009
| |
|
| |
| | A Protocol for Remotely Managing Sieve Scripts |
| |
|
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. |
16/01/2009
| |
|
| |
| | Updates to Asserted Identity in the Session Initiation Protocol (SIP) |
| |
|
SIP has a mechanism for conveying the asserted identity of the originator of a request by means of the P-Asserted-Identity header field. This header field is specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of this header field by a trusted UAC, does not specify the use of P-Asserted-Identity and P-Preferred- Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations. This work is being discussed on the sipping@ietf.org mailing list. |
15/01/2009
| |
|
| |
| | GSS-API: Delegate if approved by policy |
| |
|
Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers as well as CIFS file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). |
13/01/2009
| |
|
| |
| | Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections |
| |
|
The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. |
06/01/2009
| |
|
| |
| | VoIP Configuration Server Address Option |
| |
|
This memo documents existing usage for the "VoIP Configuration Server Address Option" (previously known as the "TFTP Server IP Address Option"). The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942 [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. |
05/01/2009
| |
|
| |
| | Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments |
| |
| | draft-ietf-sipping-sbc-funcs-08.txt |
| | Date: |
05/01/2009 |
| | Authors: |
Jani Hautakorpi, Gonzalo Camarillo, Bob Penfield, Alan Hawrylyshen, Medhavi Bhatia |
| | Working Group: |
Session Initiation Proposal Investigation (sipping) |
| | Formats: |
txt xml |
|
This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required. |
01/01/2009
| |
|
| |
| | SIP (Session Initiation Protocol) Usage of the Offer/Answer Model |
| |
|
The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. |
|
