Subject: Re: [Sipping] WGLC of draft-ietf-sipping-service-examples-10.txt

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 Jul 2006 09:13:32 +0300

Hi:

Now replying to the correct thread...

This is my review of Sections 2.14 and 2.15.

1) About the call flow in Section 2.14: Alice receives the 403 in flow 
F8, including an Error-Info URI. I would assume that the INVITE F10 goes 
straight forward to that URI. However, flow F10 traverses once more the 
Proxy (proxy that wasn't initially traversed in flow F1). I don't think 
this is the natural behavior, why should Alice route the INVITE F10 via 
the proxy, once she got a URI that does not embed a Route header? Notice 
that the proxy is not Alice's outbound proxy, so I see no reason for 
this behavior.

2) The text under the flow in Section 2.14 refers to "user B". It should 
be "Bob" instead.

3) In all INVITE requests of both Sections 2.14 and 2.15 I am missing an 
Allow header. According to RFC 3261 Section 13.2.1,

    An Allow header field (Section 20.5) SHOULD be present in the INVITE.

4) In all the SDP bodies of both Sections 2.14 and 2.15, the "s=" line 
is populated as "s=Session SDP". RFC 3264 Section 5 recommends to set it 
to a white space or a dash for unicast streams:

    The SDP "s=" line conveys the subject of the session, which is
    reasonably defined for multicast, but ill defined for unicast.  For
    unicast sessions, it is RECOMMENDED that it consist of a single space
    character (0x20) or a dash (-).

       Unfortunately, SDP does not allow the "s=" line to be empty.

5) In all the SDP bodies of both Sections 2.14 and 2.15 the "t=" line is 
populated with an initial time, such as "t=3034423619 0". According to 
RFC 3264 Section 5, it should be set to "t=0 0".

    The SDP "t=" line conveys the time of the session.  Generally,
    streams for unicast sessions are created and destroyed through
    external signaling means, such as SIP.  In that case, the "t=" line
    SHOULD have a value of "0 0".

6) Section 2.14, Flow F5. The Proxy-Authenticate header contains a 
"domain" directive set to "sips:ss1.example.com". However, RFC 2617 
Section 3.2.1 suggest not to include the domain directive in the 
Proxy-Authenticate header:

      This directive is not meaningful in Proxy-Authenticate headers, for
      which the protection space is always the entire proxy; if present
      it should be ignored.

7) Same flow and header as in 6): I am missing a qop directive, perhaps 
set to "auth,auth-int". RFC 2617 Section 3.2.1. insists that the qop 
directive is optional just for backward compatibility issues only, so it 
should be present int eh Proxy-Authenticate header.

      This directive is optional, but is made so only for backward
      compatibility with RFC 2069 [6]; it SHOULD be used by all
      implementations compliant with this version of the Digest scheme.

And also RFC 3261 in Section 22.4, bullet point 8 states the same:

           However,
           servers MUST always send a "qop" parameter in WWW-Authenticate
           and Proxy-Authenticate header field values.

If you accept this change, then the INVITE request in flow F7 has to add 
a qop="auth", a nc=00000001 and a cnonce (of your choice) to the 
Proxy-Authorization header to make the Digest authentication correct.

8) I noticed that flow F9 in Section 2.14 contains a Proxy-Authorization 
header. I think it is weird that the ACK request for a 403 response 
contains a Proxy-Authorization header. There is nothing the proxy can do 
with that group of credentials.

The same applies to Flow F6 in Section 2.15.

9) Flow F12 in Section 2.14 uses "announce.example.com" as the hostname 
of the announcement server in the Contact header. However, the SDP in 
the same message and subsequent SIP message use 
"announcement.example.com", so they should be synchronized.

10) Flow F15 in Section 2.14 misses ".example" in the Request-URI, so it 
should be: sips:[email-masked]

11) There are empty lines in the following flows:
     Section 2.14: F10, F16
     Section 2.15: F4, F6 (double)

12) There is a bracket sign "[" right as the first line of Section 2.14, 
before the figure.

Please let me know if you want me to review some other section, I will 
be able to do it in the following days.

BR,

     Miguel

Gonzalo Camarillo wrote:
> Folks,
> 
> we would like to working group last call (WGLC) the following draft:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-10.txt 
> 
> 
> as you have probably noticed if you clicked on the link above, this is a 
> very long draft. Therefore, we would like to get at least ten volunteers 
> to review it. We will assign a couple of sections to each reviewer.
> 
> If you are interested and willing to review this draft, please send an 
> email to the SIPPING chairs.
> 
> The email below should be considered as a WGLC comment:
> 
> http://www1.ietf.org/mail-archive/web/sipping/current/msg10886.html
> 
> This is the output of the idnits tool:
> 
> idnits 1.96
> 
> tmp/draft-ietf-sipping-service-examples-10.txt:
> 
> 
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
> 
>     Checking conformance with RFC 3978/3979 boilerplate...
> 
>     the boilerplate looks good.
> 
>   * There is 1 instance of too long lines in the document, the longest one
>     being 1 character in excess of 72.
> 
>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>     Nothing found here (but these checks do not cover all of
>     1id-guidelines.txt yet).
> 
>   Miscellaneous warnings:
>   - Line 1028 has weird spacing: '... /* Bob  place...'
>   - Line 1404 has weird spacing: '... /* Bob  takes...'
>   - Line 1732 has weird spacing: '... /* Bob  place...'
>   - Line 2459 has weird spacing: '...and Bob  have ...'
>   - Line 2597 has weird spacing: '... /* Bob  puts ...'
>   - (4 more instances...)
> 
>   Experimental warnings:
>   - Unused Reference: [18] is defined on line 7860, but not referenced
>   - Unused Reference: [13] is defined on line 7839, but not referenced
>   - Unused Reference: [14] is defined on line 7842, but not referenced
>   - Unused Reference: [1] is defined on line 7795, but not referenced
> 
> 
> 
> 
> This WGLC will end on July 1st, 2006 (a long draft needs a long WGLC).
> 
> Thanks,
> 
> Gonzalo
> SIPPING co-chair
> 
> 
> _______________________________________________
> 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
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
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