Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-04.txt

From: [email-masked]
Date: Thu, 14 Jan 2010 00:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : Session Initiation Protocol (SIP) INFO Method and Package Framework
	Author(s)       : C. Holmberg, et al.
	Filename        : draft-ietf-sipcore-info-events-04.txt
	Pages           : 39
	Date            : 2010-01-13

This document defines a new method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261], and an Info Package mechanism.  The
document obsoletes [RFC2976].  For backward compatibility the
document also specifies a "legacy" mode of usage of the INFO method
that is compatible with the usage previously defined in [RFC2976],
referred to as "legacy INFO Usage" in this document.

Conventions Used in this Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The terminology in this document conforms to the Internet Security
Glossary [RFC4949].

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 18, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jan 2010 10:33:38 -0500

I just reviewed the latest version of this document.
I must say it is looking pretty good now!
I only have relatively minor comments:

Abstract:

NIT: "This document defines a new method, INFO, ..."
Such statements never age well, and that is especially the case for a 
revision document. How about just "This document defines a method, INFO, 
..."? (This correction should also be made to section 1 -Introduction, 
and section 2 - Applicability.)

Section 3.3.1:

    When a UA supports a specific Info-Package, the UA also support all
    message body MIME types associated with that Info-Package.  However,
    in accordance with [RFC3261] the UA still indicates the supported
    MIME types using the Accept header.

Is there supposed to be something normative here? As stated there isn't. 
Perhaps:

    When a UA supports a specific Info-Package, the UA MUST also support
    message body MIME types in accord with that Info-Package.
    However, in accordance with [RFC3261] the UA still indicates the
    supported MIME types using the Accept header.

(I said "in accord" rather than "all" in the above because some info 
package specifications might define mime type alternatives in a way that 
doesn't require all to be supported.)

Section 3.4:

    If specific applications need additional mechanisms for order of
    delivery, those mechanisms, and related procedures, are specified as
    part of the associated Info Package, and possible sequence numbers
    etc must be defined as application data.

The non-normative "must" seems awkward. How about:

    If specific applications need additional mechanisms for order of
    delivery, those mechanisms, and related procedures, are specified as
    part of the associated Info Package. (E.g. the use of sequence
    numbers within the application data.)

Section 4.4.2:

Nit: "Recv-Info" is misspelled as "Revc-Info" at least once.

The following:

    Once a UA has sent a set of Info Packages, the set is valid until the
    UA sends a new set, or an empty Recv-Info header field.

could be construed to mean INFO messages have been sent containing 
certain Info Packages. How about:

    Once a UA has sent a message with a Recv-Info header field containing
    a set of Info Packages, the set is valid until the UA sends a new
    Recv-Info header field containing a new, or empty set.

Section 4.2.3:

    NOTE: Similar to SDP answers, the receiver can include the same Recv-
    Info header field value in multiple responses (18x/2xx) for the same
    INVITE/re-INVITE transaction, but the receiver is not allowed to
    include a Recv-Info header field value which is different from a
    value that the receiver has already included in a response for the
    same transaction.

I think "the receiver is not allowed" is intended to be normative. But 
the language isn't normative. If it is indeed intended to be normative 
this needs to be rewritten.

Section 6.1:

Why is Info-Package permitted in 469? Is the expectation that the UAS 
will copy the Info-Package header (but not the body) from the request 
into the response? If so, then there ought to be some text somewhere 
that says that. But why bother? It would be more useful to include the 
Recv-Info header in the 469 response. (That would require added 
specification, since it is currently forbidden to do so.)

There is trouble with the formatting of the paragraph following the table:

    The support and usage of the Info-Package and Recv-Info header fields
    is not applicalbe to UAs that only support legacy INFO usages. * Not
    applicalbe to INFO requests and responses associated with legacy INFO
    usages. ** Mandatory in at least one reliable 18x/2xx response, if
    sent, to the INVITE request, if the associated INVITE request
    contained a Recv-Info header field. *** Mandatory if the associated
    request contained a Recv-Info header field.

Should presumably be:

    The support and usage of the Info-Package and Recv-Info header fields
    is not applicable to UAs that only support legacy INFO usages.

    *   Not applicable to INFO requests and responses associated with
        legacy INFO usages.

    **  Mandatory in at least one reliable 18x/2xx response, if
        sent, to the INVITE request, if the associated INVITE request
        contained a Recv-Info header field.

    *** Mandatory if the associated request contained a Recv-Info header
        field.

Section 7.4.1.3: NIT: s/ser/user/

Section 8.2:

There is a preferred method for defining extensions now:

    Method    =/ INFOm

Also, the following is missing but needed:

    message-header =/ (Info-Package / Recv-Info) CRLF

However these changes will require referencing RFC 5234

Section 10.4:

The cross reference to section 10.5 is wrong. And I'm not certain what 
the correct value is - perhaps 11.4???

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Jan 2010 13:56:59 -0600

>    Method    =/ INFOm 

This is more important than it may seem at first, so I want to put 
particular emphasis on it.

Christer: please fix this issue before we pubreq the document.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jan 2010 15:21:05 -0500

> Christer: please fix this issue before we pubreq the document.

The other one of those I called out:

is even *more* important, because it wasn't there in any form.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 13:17:47 +0100

Hi, 

>Such statements never age well, and that is especially the 
>case for a revision document. How about just "This document 
>defines a method, INFO, ..."? (This correction should also be 
>made to section 1 -Introduction, and section 2 - Applicability.)

Fixed.

-----------------
 
>Section 3.3.1:
> 
> When a UA supports a specific Info-Package, the UA also 
> support all message body MIME types associated with that 
> Info-Package. However, in accordance with [RFC3261] the UA 
> still indicates the supported MIME types using the Accept header.
> 
> When a UA supports a specific Info-Package, the UA MUST 
> also support message body MIME types in accord with that Info-Package.
> (I said "in accord" rather than "all" in the above because 
> some info package specifications might define mime type 
> alternatives in a way that doesn't require all to be supported.)

In principle the change looks good, but could "in accord" be something which non-english people have troubles to understand?

Could we say "in accordance with that Info-Package"?

-----------------
 
> delivery, those mechanisms, and related procedures, are 
> specified as part of the associated Info Package, and possible sequence numbers

Fixed.

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

>Nit: "Recv-Info" is misspelled as "Revc-Info" at least once.

Fixed.

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

>The following:
> 
> Once a UA has sent a set of Info Packages, the set is 
> valid until the UA sends a new set, or an empty Recv-Info header field.
> 
> could be construed to mean INFO messages have been sent 
> containing certain Info Packages. How about:
> 
> Once a UA has sent a message with a Recv-Info header 
> field containing a set of Info Packages, the set is 
> valid until the UA sends a new Recv-Info header field 
> containing a new, or empty set.

Fixed.

"Once a UA has sent a message with a Recv-Info header field containing a set 
of Info Packages, the set is valid until the UA sends a new Recv-Info 
header field containing a new, or empty, set of Info Packages."

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

>Section 4.2.3:
> 
> NOTE: Similar to SDP answers, the receiver can include 
> the same Recv-Info header field value in multiple responses (18x/2xx) 
> for the same INVITE/re-INVITE transaction, but the receiver is not allowed to
> I think "the receiver is not allowed" is intended to be 
> normative. But the language isn't normative. If it is indeed 
> intended to be normative this needs to be rewritten.
> 
> Section 6.1:
> 
> Why is Info-Package permitted in 469? Is the expectation that 
> the UAS will copy the Info-Package header (but not the body) 
> from the request into the response? If so, then there ought 
> to be some text somewhere that says that. But why bother? It 
> would be more useful to include the Recv-Info header in the 
> 469 response. (That would require added specification, since 
> it is currently forbidden to do so.)

I agree that Recv-Info makes more sense.

I guess we could add the following clarification text to section 3.2.2:

"If a UA receives an INFO request associated with an Info Package that
the UA has not indicated willingness to receive, the UA MUST send a
469 (Bad INFO Package) response (see Section 11.6)<new>, which contains a Recv-Info
Header field with Info Packages for which the UA is willing to receive
INFO requests. The UA MUST NOT use the response to update the set of Info
Packages, but simply to indicate the current set.</new> In the
terminology of Multiple Dialog Usages [RFC5057], this represents a
Transaction Only failure, and does not terminate the invite dialog
usage."

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

>The support and usage of the Info-Package and Recv-Info 
>header fields is not applicalbe to UAs that only support legacy INFO 
>usages. * Not applicalbe to INFO requests and responses associated with 
>legacy INFO usages. ** Mandatory in at least one reliable 18x/2xx response, if

Fixed.

-----------------
 
>Section 7.4.1.3: NIT: s/ser/user/

Fixed.

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

>However these changes will require referencing RFC 5234

I added a refernce to 5243 in the normative reference section.

Where do you want a reference in the text? Somewhere in section 8.1?

The text currently says:

"This section describes the syntax extensions required for the INFO
method, and for the Info-Package and Recv-Info header fields.  The
previous sections describe the semantics.  Note the formal syntax
definitions described in this document use the ABNF format used in
[RFC3261] and contain references to elements defined therein."

3261 refers to 2234 for ABNF, but maybe that doesn't matter.

Maybe we could say something like:

"This section describes the syntax extensions to the ABNF format defined in [RFC3261] required for the INFO
method, and for the Info-Package and Recv-Info header fields. The previous sections describe the semantics. 
The ABNF defined in this specification is conformant to [RFC5234]."

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

>Section 10.4:
> 
>The cross reference to section 10.5 is wrong. And I'm not 
>certain what the correct value is - perhaps 11.4???

It seems like some old text, that should have gone as part of some restructuring.

I suggest to remove the paragraph.

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jan 2010 10:13:52 -0500

Trimming to things that are worthy of further discussion...

> In principle the change looks good, but could "in accord" be something which non-english people have troubles to understand?

You are a better judge of that than I am, since I only speak English. :-)

> Could we say "in accordance with that Info-Package"?

That seems fine, better than what I proposed.

You didn't comment on the above.
Do you agree that this ought to be normative?

> Transaction Only failure, and does not terminate the invite dialog

That seems reasonable to me.
But then you also need to update the table in 6.1 to show that Recv-Info 
is permitted in 469 responses.

Almost. I suggest:

"This section describes the syntax extensions to the ABNF syntax defined 
in [RFC3261] required for the INFO
method, and adds definitions for the Info-Package and Recv-Info header 
fields. The previous sections describe the semantics.
The ABNF defined in this specification is conformant to [RFC5234]."

ok.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jan 2010 22:40:18 +0100

Hi, 

>>> package specifications might define mime type alternatives in a way 
>>> that doesn't require all to be supported.)
>> 

I wouldn't have understood it at least :)

>That seems fine, better than what I proposed.

Good.

-----------------
 
>> Section 4.2.3:
>>
>> NOTE: Similar to SDP answers, the receiver can include the same 
>> Recv-Info header field value in multiple responses (18x/2xx) for the 
>> same INVITE/re-INVITE transaction, but the receiver is not allowed to 
>> I think "the receiver is not allowed" is intended to be normative. 
>> But the language isn't normative. If it is indeed intended to be 
>> normative this needs to be rewritten.
>

Sorry, I forgot to write down my comment earlier.

Yes, I agree to making it normaive. I suggest to simply remove "NOTE:".

Also, I suggest to change "is not allowed" to "MUST NOT".

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

>>> that says that. But why bother? It would be more useful to include 
>>> the Recv-Info header in the
>>> 469 response. (That would require added specification, since it is 
>>> currently forbidden to do so.)
>> 
>> 469 (Bad INFO Package) response (see Section 11.6)<new>, which 
>> contains a Recv-Info Header field with Info Packages for which the UA 
>> is willing to receive INFO requests. The UA MUST NOT use the response 
>> to update the set of Info Packages, but simply to indicate the current 
>> set.</new> In the terminology of Multiple Dialog Usages [RFC5057], 
>> this represents a Transaction Only failure, and does not terminate the 
>> invite dialog usage."
>
>But then you also need to update the table in 6.1 to show that Recv-Info is permitted in 469 responses.

Yes.

-----------------
 
>> "This section describes the syntax extensions to the ABNF format 
>> defined in [RFC3261] required for the INFO method, and for the Info-Package and Recv-Info header fields. The previous sections describe the semantics.
>"This section describes the syntax extensions to the ABNF syntax defined in [RFC3261] required for the INFO method, and adds definitions for the Info-Package and Recv-Info header fields. The previous 
>sections describe the semantics. The ABNF defined in this specification is conformant to [RFC5234]."

Looks good.

-----------------
 
>>> Section 10.4:
>>>
>>> The cross reference to section 10.5 is wrong. And I'm not certain 
>>> what the correct value is - perhaps 11.4???
>> 

Gone it will be.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jan 2010 18:32:42 -0500

That works for me.

With all the changes you have proposed it all seems good to me.

	Thanks,
	Paul