Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt

On 10/23/06, Alan Johnston <alan at sipstation.com> wrote:

All,

Thanks to to the detailed comments and corrections from the reviewers,
the SIP Service Examples I-D has been updated and is now ready to progress.

The only major change is the removal of the Single Line Extension call
flow.  I am working with the authors of draft-anil-sipping-bla-03.txt on
call flows for this feature in a separate I-D.

Thanks again to Vijay Gurbani, John Elwell, Joel Repiquet, Nagesh Kumar,
Chandra Ravipati, Eric Burger, Jeroen Bemmel, Miguel Garcia, and Dale
Worley.

Below are a few cases where I had some comments on the review.

Thanks,
Alan

- - -

Joël Repiquet wrote:

>
> 2.4.  Transfer - Unattended
> ------------------------------
>
> 1) The "Supported: replaces" message-header line in F1, F3, F4, F11
and F13
>    is superfluous and I suggest to remove it

I have left the Supported header field in - it is a good idea to list
supported features even if they are not being invoked at that time.

nagesh kumar wrote:
>
> 2.7
>
> F3 - Here proxy sends 181 when it is forwarding the call. However,
proxy shall not generate any response by itself as per RFC 3261 - P110.
> "Since a proxy may not insert a tag into the To header field of a 1xx
response to a request that did not contain one, it cannot issue
> non-100 provisional responses on its own. "

I have added a clarification that the Server is acting as a UAS when it
generates the 181 response.  I also included a To tag based on previous
list discussion.

Dale R. Worley wrote:
> Following is my review of sections 2.16 (Call Park) and 2.17 (Call
> Pickup) of draft-ietf-sipping-service-examples-10.txt.
>

>
> * Header line breaking
>
> While the grammar of RFC 3261 section 25.1 allows header values to be
> broken at most delimiters, it does not allow URIs to be broken.  (And
> this is confirmed by the examples in RFC 3261.)  So this header is
> invalid:
>
>       Refer-To: <sips:39itp34klkd at chicago.example.com?Replaces=
>        sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3
>        %3Bfrom-tag%3D8675309>
>
> and it must be written as:
>
>       Refer-To:
< sips:39itp34klkd at chicago.example.com?Replaces=sdjfdjfskdf%40biloxi.example.com%3Bto-tag%3D5f35a3%3Bfrom-tag%3D8675309>
>
> Note that "header parameters" on URIs can be broken, so this is valid:
>
>       Contact: <sip:foo at example.com>
>                ;q=.01
>
> Clearly, these long headers can't be represented directly in the I-D,
> so we need some sort of line-breaking convention.  Perhaps something
> like this could be added to section 1.1:
>
>     For publication, some headers must have line breaks inserted in
>     locations that the grammar does not permit line breaks.  A line
>     that is presented here as ending with "<<br>>" should be
>     interpreted by removing that string, the following line break, and
>     any leading whitespace on the next line.
>
> The locations I've discovered that need this treatment would then be
> presented as follows:
>
> Section 2.5:
>
>       F15 REFER Bob -> Alice
>
>

I have fixed this by using the <allOneLine> tag defined in RFC 4475.

Internet-Drafts at ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.
>
>       Title           : Session Initiation Protocol Service Examples
>       Author(s)       : A. Johnston, et al.
>       Filename        : draft-ietf-sipping-service-examples-11.txt
>       Pages           : 157
>       Date            : 2006-10-22
>
> This document gives examples of Session Initiation Protocol (SIP)
>    services.  This covers most features offered in so-called IP Centrex
>    offerings from local exchange carriers and PBX (Private Branch
>    Exchange) features.  Most of the services shown in this document are
>    implemented in the SIP User Agents, although some require the
>    assistance of a SIP Proxy.  Some require some extensions to SIP
>    including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces
>    and Join headers.  These features are not intended to be an
>    exhaustive set, but rather show implementations of common features
>    likely to be implemented on SIP IP telephones in a business
>    environment.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-11.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-sipping-service-examples-11.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>       mailserv at ietf.org.
> In the body type:
>       "FILE /internet-drafts/draft-ietf-sipping-service-examples-11.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e. documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP