Subject: [Sipping] Requested Expert Review of OMA-POC drafts -- need volunteers from SIPPING

From: Dean Willis <[email-masked]>
Date: Mon, 07 Feb 2005 20:44:46 -0600

We've been asked to provide expert review for two drafts coming in from 
OMA under the terms of RFC3427/BCP0067. "Change Process for the Session 
Initiation Protocol" and RFC3975, "OMA-IETF Standardization Collaboration"

The drafts to review are:

	draft-allen-sipping-poc-p-headers-01
	draft-garcia-sipping-poc-isb-am-01

The first draft defines some P-headers, and the second defines an event 
package.

I'd like to request volunteers to do a thorough review and writeup of 
each draft, said writeup to be published back to this list. I'll be 
doing a writeup for each myself, having commented on previous versions. 
I'd also specifically like to request Adam Roach (copied here) take a 
look at the event package draft, as he authored/edited RFC 3265 which 
defines the requirements for publishing an event package.

 From the volunteer reviewers, we'll select a "designated expert" as per 
RFC 2434 to write up the P-header draft for the Transport Area directors 
consideration.

I'd like to point out that the processes for P-headers in RFC3427 
specifically includes the following elements:

-----------
1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
        proposal for applicability to SIP and conformance to these
        guidelines.  The Expert Reviewer will send email to the Transport
        Area Directors on this determination.  The expert reviewer can
        cite one or more of the guidelines that haven't been followed in
        his/her opinion.

    2.  The proposed extension MUST NOT define SIP option tags, response
        codes, or methods.

    3.  The function of the proposed header MUST NOT overlap with current
        or planned chartered extensions.

    4.  The proposed header MUST be of a purely informational nature, and
        MUST NOT significantly change the behavior of SIP entities which
        support it.  Headers which merely provide additional information
        pertinent to a request or a response are acceptable.  If the
        headers redefine or contradict normative behavior defined in
        standards track SIP specifications, that is what is meant by
        significantly different behavior.

    5.  The proposed header MUST NOT undermine SIP security in any sense.
        The Internet Draft proposing the new header MUST address security
        issues in detail as if it were a Standards Track document.  Note
        that, if the intended application scenario makes certain
        assumptions regarding security, the security considerations only
        need to meet the intended application scenario rather than the
        general Internet case.  In any case, security issues need to be
        discussed for arbitrary usage scenarios (including the general
        Internet case).

    6.  The proposed header MUST be clearly documented in an (Individual
        or Working Group) Informational RFC, and registered with IANA.

    7.  An applicability statement in the Informational RFC MUST clearly
        document the useful scope of the proposal, and explain its
        limitations and why it is not suitable for the general use of SIP
        in the Internet.

    Any implementation of a "P-" header (meaning "not specified by a
    standards-track RFC issued through the SIP Working Group") MUST
    include a "P-" prefix on the header, as in "P-Headername".  Note that
    "P-" extensions are not IETF standards of any kind, and MUST NOT be
    required by any production deployment considered compliant to IETF
    specifications.  Specifically, implementations are only SIP compliant
    if a) they fall back to baseline behavior when they ignore all P-
    headers, and b) when using P- headers they do not contradict any
    normative behavior.

--------------

I personally have some concerns about one of the proposed P-headers 
conflicting with the Caller Preferences work, which could raise issues 
under clause 3 above, and I'd like to get a sense of community belief 
about this aspect.

Note that this message has also been bcced to the ietf-liaisons list for 
consideration.

--
Dean

_______________________________________________
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