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

[Alexey Melnikov <[e-mail]>]

Hi Adam,
Sorry I've missed your reply earlier.

On 11/04/2012 23:03, Adam Roach wrote:
> On 4/10/12 5:46 AM, Alexey Melnikov wrote:
  [...]
>> 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.
Ok.

>>
>> 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:
>
> http://tools.ietf.org/html/draft-ietf-sipcore-rfc3265bis-07#section-4.4.4
>
> Is it possible you accidentally edited a local copy of the file prior 
> to your review?
It is possible. Not a big deal either way.
> 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." 
So my understanding is that it is not possible to just request a 
template event (it needs to be combined with something else)? I think 
some explanation and/or examples of this would be good, I don't think 
this is very clear in the document.
  [...]

>> 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.
>
Ok, I will tell Russ that these 2 issues are still pending resolution.
>> 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 subscription.
>
> "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.
Ok, so the ordering is important. Is this documented anywhere?
>
>> 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.
I thought it was a reference, but this is not a big deal.