Re: [Gen-art] Gen-Art review of draft-ietf-sipcore-rfc3265bis-07.txt

Adam Roach <> Wed, 11 April 2012 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C3D111E80DB; Wed, 11 Apr 2012 15:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.42
X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, MANGLED_SAVELE=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZZg+WKGUIosS; Wed, 11 Apr 2012 15:03:10 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 4459A11E80CC; Wed, 11 Apr 2012 15:03:07 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q3BM34Lj041723 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 17:03:05 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Wed, 11 Apr 2012 17:03:04 -0500
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Alexey Melnikov <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc:, The IESG <>, Paul Kyzivat <>
Subject: Re: [Gen-art] Gen-Art review of draft-ietf-sipcore-rfc3265bis-07.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Apr 2012 22:03:11 -0000

On 4/10/12 5:46 AM, Alexey Melnikov wrote:
> 3.2.1.  Identification of Reported Events, Event Classes, and Current
>         State
>    When present, the body of the NOTIFY request MUST be formatted into
>    one of the body formats specified in the "Accept" header field of the
>    corresponding SUBSCRIBE request.  This body will contain either the
>    state of the subscribed resource or a pointer to such state in the
>    form of a URI (see Section 5.4.13).
> Nit: or the default according to the event package definition, if no 
> Accept
> header field was specified.

I've added text to point this case out.

> Also, it might be good to reference RFC 3986 for URIs here.

Given that SIP uses URIs everywhere, I'm not sure what benefit is 
derived by referencing the URI syntax draft here.

> 4.1.1.  Detecting Support for SIP Events
>    The extension described in this document does not make use of the use
>    of "Require" or "Proxy-Require" header fields; similarly, there is no
> Nit: too many "use of".


> 4.1.3.  Receiving and Processing State Information
>    To prevent spoofing of events, NOTIFY requests SHOULD be
>    authenticated, using any defined SIP authentication mechanism.
> Minor: How can this SHOULD be satisfied? Any reference which might be 
> appropriate here?

Added: "...such as those described in sections 22.2 and 23 of [RFC3261]."

>  Authentication/Authorization of SUBSCRIBE Requests
>    SIP authentication mechanisms are discussed in [RFC3261].  Note that,
>    even if the notifier node typically acts as a proxy, authentication
>    for SUBSCRIBE requests will always be performed via a "401" response,
>    not a "407;" notifiers always act as a user agents when accepting
> Nit: Is the ";" after "407" a typo?

Thanks -- that should have been outside the quotation marks (and 
probably should be a full stop, which I've changed it to).

> 4.4.4.  Allow-Events header field usage
>    The "Allow-Events" header field does not include a list of the etvent
>  typo: event

I don't find "etvent" in the document:

Is it possible you accidentally edited a local copy of the file prior to 
your review?

I also don't find this typo in the source (which would surprise me in 
any case, as I made sure to run the -07 version through a spell checker).
>    template packages supported by an implementation.  If a subscriber
>    wishes to determine which event template packages are supported by a
>    notifier, it can probe for such support by attempting to subscribe to
>    the event template packages it wishes to use.
> Can you clarify how such request would look like? An example would be 
> nice.

I'm not sure what you're asking for here. It would be a SUBSCRIBE 
message, with an "Event" header field set to name the template you want 
to use. Basically it just says "we don't negotiate templates -- just try 
it and see if it fails."

> 5.4.3.  SUBSCRIBE Request Bodies
>    It is expected that most, but not all, event packages will define
>    syntax and semantics for SUBSCRIBE request bodies; these bodies will
>    typically modify, expand, filter, throttle, and/or set thresholds for
>    the class of events being requested.  Designers of event packages are
>    strongly encouraged to re-use existing MIME types for message bodies
>    where practical.
> Nit: MIME types are now called "media types" in more recent IETF RFCs.

Thanks. Fixed in three places.

> I would recommend pointing to the Media Type Registration Procedure 
> document [RFC 4288] here, which points to the IANA registry.


> 5.4.5.  NOTIFY Request Bodies
>    Event packages also MUST define which MIME type is to be assumed if
>    none are specified in the "Accept" header field of the SUBSCRIBE
>    request.
> The same nit as above.


> 7.2.  Reason Codes
>    This document further defines "reason" codes for use in the
>    "Subscription-State" header field (see Section 4.1.3).
>    Following the policies outlined in "Guidelines for Writing an IANA
>    Considerations Section in RFCs" [RFC5226], new reason codes require a
>    Standards Action.
> Minor: This would prevent registration of new Reason Codes in an 
> Experimental RFC (for example). I would like to double check that that 
> is intentional.

It never came up explicitly during working group discussions, to my memory.

>    Registrations with the IANA include the reason code being registered
>    and a reference to a published document which describes the event
>    package.  Insertion of such values takes place as part of the RFC
>    publication process or as the result of inter-SDO liaison activity.
> I don't think Standards Action allows for "inter-SDO liaison 
> activity", unless such documents from other SDOs are published as 
> Standard Track RFCs. So I find your text confusing: either your 
> registration procedure should also allow for direct IESG approvals (to 
> allow registrations from other SDOs with no RFCs), or you should 
> remove "as the result of inter-SDO liaison activity".

You're right. I suspect we really intended to make this registrable by 
external SDOs, meaning we probably really wanted Specification Required. 
I'm leaving this as-is for now, and will need to coordinate with our AD 
to iron out where to go with this.

> 8.4.  Augmented BNF Definitions
>    event-type        =  event-package *( "." event-template )
> Minor: Does this mean that multiple template packages can be applied?
> Is there any ordering for them?
Yes, and yes.
> How would "foo.A.B" differ from "foo.B.A"?

Right now, we have only one template defined -- but imagine that we did 
define a new "list" template event package (we almost did this some 
years ago) which is used to aggregate several resources into a single 

"Event: presence.winfo.list" would subscribe to the aggregation of 
several watcher-info documents into a single list.

"Event: presence.list.winfo" would subscribe to the watcher-info state 
of the indicated list.

> Nit: id-nits complains:
>   -- Duplicate reference: RFC4660, mentioned in 'RFC4660', was also 
> mentioned
>      in 'RFC 4660'.
> "[RFC 4660]" reference is used in section 7.2.

id-nits is wrong. It incorrectly thinks that the paragraph starting with 
[RFC4660] on page 40 is trying to define a reference.