Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 27 Oct 2009 03:34:37 +0100

Various miscellaneous comments. I have not yet trawled through all the other comments and discussion to find if these have already been made elsewhere. I suspect I will find some other comments at a later time.

1)	General. Please write responses in the format "200 (OK) response" rather than "200 OK response".

2)	General. Can we fix on the term of either "Info Package definition" or "Info Package specification" and use it consistently (in full) throughout where we mean that term.

3)	Section 3.2

   A UA which supports the Info Package mechanism MUST indicate, using
   the Revc-Info header field, the set of Info Packages for which it is
   willing to receive an INFO request.  
                      ^^^

Insert "an" as indicated.

4)	Section 3.2:

   If a UA is not willing to receive INFO requests for any Info Packages, during
                             ^^^^^^^^
   dialog establishment or later during the INVITE dialog usage, the UA
                                            ^^^^^^^
   MUST indicate this by including a Recv-Info header field with a 'nil'
   value.  

Insert "receive" as indicated. Replace "invite" with upper case as I believe this is the RFC 3261 convention.

5)	Section 3.2 indicates:

   A UA MUST NOT send an INFO request associated with an Info Package
   until it has received an indication that the remote UA is willing to
   receive INFO requests for that Info Package, and a dialog has been
   established with the remote UA.

and section 4.2 indicates:

   For a specific dialog, a UA
   MUST NOT send INFO requests associated with Info Packages that the
   remote UA has not indicated that it is willing to receive.

Are these not the same requirement. We need to eliminate one.

6)	Section 3.2 indicates:

   Likewise, even if a UA uses the Recv-Info header
   field to indicate that it supports the Info Package mechanism, in
   addition the UA MUST still also explicitly indicate support of the
   INFO method using the Allow header field.

I do not believe this should be a MUST, because it is surely already a MUST in RFC 3261 - all we need to do is write an informative sentence that in accordance with RFC 3261 the Allow header also indicates INFO requests.

7)	Section 3.3:

3.3.  Package Versioning

   The Info Package mechanism does not support package versioning.
   Specific Info Package payloads MAY contain version information, which
   is handled by the applications associated with the Info Package, but
   that is outside the scope of the Info Package mechanism.

   NOTE: Even if an Info Package name contains version numbering (e.g.
   foo_v2), the Info Package mechanism does not distinguish a version
   number from the rest of the Info Package name.

As this is all part of the Info Package name, and needs to form part of the Info Package specification if used, I think all the text here should be moved to section 10.3, and this section header deleted.

8)	Section 4.3 indicates:

   Info Package specifications MUST describe the application level
   information associated with the Info Package.  Each body part MUST
   have a MIME type value, and the syntax and content of the body part,
   defined.

   Each body part, when associated with an Info Package, MUST have a
   Content-Disposition header field with an 'Info-Package' value
   assigned, in order to be able distinguish body parts associated with
   the Info Package from other body parts.

Surely this is something where the MUST can only be met by the designer of the package, and therefore it belongs in section 10.

9)	Section 4.3:

   NOTE: Some SIP functions that are orthogonal to INFO may insert body
   parts unrelated to the Info Package.

Change "may" to "can".

10)	Section 4.3:

   However, when a body part in the INFO message is associated with an
   Info Package, it MUST always have a Content-Disposition header field
   with an 'Info-Package' value assigned.  

Is this not just a repeat of the requirement earlier in the section (1 paragraph before the note).

11)	Section 4.3:

   This document does not define Info Package specific rules on how body
   parts associated with Info Packages are to be inserted into multipart
   body parts, and what type of multiparts are used.  If an Info Package
   requires special rules regarding the usage of multipart body parts,
   the specification for that Info Package MUST specify such rules.

The MUST here has to be in section 10. This paragraph needs to remove the requirement, and refer to section 10 instead.

12)	Section 4.4:

   If a UA receives an INFO request for legacy usage, for which no Info-
   Package is associated (the INFO request does not contain an Info-
   Package header field), the UA MUST send a 200 OK response.

   The UAS MAY send other responses, such as Request Failure (4xx),
   Server Failure (5xx) and Global Failure (6xx) as appropriate for the
   request.

The second paragraph above contradicts the first above. I assume that means that there is a hidden condition that is missing from the first paragraph. Something along the lines of "that is otherwise syntactically correct and well structured".

13)	Section 4.4:

   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 Section 11.6.  In the terminology of
   Multiple Dialog Usages [RFC5057], this represents a Transaction Only
   failure.

I assume that "(see Section 11.6)" or something similar is meant in the end of the first sentence. 

I believe we also need to define whether the response code applies to the transaction or the dialog. It obviously has to be the transaction.

14)	Section 4.6:

   The Info Package mechanism relies on the CSeq header field to detect
   if an INFO request is received out of order.

Given that nowhere else in the document do we mention CSeq in this respect, I don't see how it can. I suspect we mean something more like

   Many Info Packages can rely on the CSeq header field to detect
   if an INFO request is received out of order.

15)	Section 4.6:

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

Change "must be specified" to "are specified". If we need a real MUST, then it has to be in section 10 in any case, and I would expect more on this issue there.

16)	Section 6.2:

   This document does not define values for Info-Package types.
   Individual Info Package specifications define these values.  Such
   specifications MUST register the values with IANA.  These values are
   Specification Required [RFC5226].

The MUST part of this paragraph belongs in section 10. It is not something the implementor of the Inof-Package header field can directly comply with.

17)	Section 7.3:

   One needs to consider the fate of the dialog usage of an INFO request
   is rejected.  In some cases it may be acceptable that the whole
   dialog usage is terminated, while in other cases is is desirable to
   maintain the dialog usage.

Change "may" to "can".

18)	Section 8.2:

   NOTE on the Recv-Info production: if the header field value is "nil",
   the header field MUST NOT contain any other Info Packages, and the
   SIP message MUST NOT contain more than one Recv-Info header field.

Please do not start a sentence containing RFC 2119 language with the word "Note". It confuses the hell out of people who understand that everything following that word is informative. In any case, the first half of this sentence is surely impossible in the ABNF and therefore the MUST is superfluous.

19)	Section 9.3.

   As described in Section 4, an INFO request associated with an Info
   Package always contains an Info-Package header field.  A legacy INFO
   request MUST NOT contain an Info-Package header field.

The first sentence of the above is fine. However the second sentence is not conformable by implementations of this specification. So I believe the "MUST" is incorrect and should be replaced by something more descriptive.

20)	Section 10.1:

   If an Info Package extends or modifies the behavior described in this
   document, it MUST be described in the definition for that Info
   Package.  Info Package definitions should not repeat procedures
   defined in this specification, unless needed for clarification or
   emphasis purpose.

Change "it MUST" to "that behaviour MUST"

As for the second sentence, assuming that we do not mean an RFC 2119 SHOULD, which I believe we do not, reword as follows: "It is bad practice for Info Package defintions to repeat procedures defined in this specification, unless..."

21)	Section 10.1:

   Info Packages MUST NOT weaken any behavior designated with "SHOULD"
   or "MUST" in this specification.  However, Info Packages MAY
   strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST"
   strength if applications associated with the Info Package requires
   it.

Do we mean "Info Packages" here or "Info Package Definitions"? (twice)

22)	Section 10.2:

   Annex A provides more information, and describes alternative
   mechanisms which one should consider for solving a specific use-case.

reword to:

   Annex A provides more information, and describes alternative
   mechanisms which are considered as part of the process for solving a specific use-case.

23)	Section 10.3

   The Info Package specification MUST define a for Info Package name
   (e.g.  "Info Package for X").

Do we mean:

   The Info Package specification MUST define an Info Package name
   (e.g.  "Info Package for X").

24)	Section 10.3

   The specification MUST also define the header field value (e.g.
   "infoX") to be used to indicate support of this package in the Recv-
   Info and Info-Package header fields.

Why do we allow the potential for a separate name for the package, and the value that appears in the header fields. I see this causing mixed usage in the IANA registrations. Surely it is simpler that whatever appears in the header fields is by definition the package name. It works for event packages surely.

25)	Section 10.4

   Note that Info Package parameters are only applicable for the Info
   Package(s) for which they have been explicitly defined.  They MUST
   NOT be used for other Info Packages.

I don't think we need the MUST here. By virtue of the fact that the Info Package specification defines only one Info Package, it can only define parameters to be associated with one Info Package. Yes other packages may define a parameter with the same name, but we are not precluding that anyway. So turn the second sentence into something informative rather than RFC 2119.

26)	Section 10.4

   NOTE: Info Package parameters defined for specific Info Packages may
   share the name with parameters defined for other Info Packages, but
   the parameter semantics are specific to the Info Package for which
   they are defined.

Change "may" to "can".

27)	Section 10.5

   SIP option tags MUST conform to the SIP Change Process
   [I-D.peterson-rai-rfc3427bis].

I don't believe we need the MUST here. We merely need a sentence that "the registration requirements for option tags are defined in ...". As you have only made this an informative reference in any case, that surely has to happen.

28)	Section 10.6

   The Info Package specification MUST define what type of message body
   parts are associated with the Info Package, and MUST refer to
   specifications where the syntax, semantics and MIME type of the
   message body parts are described.

The text above appears to preclude the Info Package specification defining them itself.

29)	Section 10.7

   The specification MUST define whether there are SIP level
   restrictions in the usage of the Info Package.  For example, an Info
   Package may require support of other SIP extensions (e.g. reliable
   provisional responses).

Change "may" to "can".

30)	Section 10.7

   As the SIP stack may not be aware of Info Package specific
   restrictions, it cannot be assumed that overlapping requests would be
   rejected.  As defined in Section 4.4, in most cases a 200 OK response
   will be sent for the INFO request.  The application logic associated
   with the Info Package needs to handle situations which can occur due
   to overlapping requests.

Change "may not" to "might not".

31)	Section 10.9

   The Info Package specification MUST contain an IANA Considerations
   section that includes definitions for the Info Package Name and, if
   needed, supported MIME types.

I believe this is unduly onerous for Info Package definitions not published by IETF and goes beyond what we require for media feature tags. They need to fit their zpecification structure. I believe that all we need to say is that the registration requirements for IANA need to be readily identifiable to IANA by including them in a single part of the document to which IANAs attention is drawn at the time of the registration request.

32)	Section 10.11

   The Info Package specification SHOULD contain a description of the
   application procedures associated with the Info Package, or
   alternatively refer to application procedures defined elsewhere.

This SHOULD is inconsistent with section 4.3 which contains:

   Info Package specifications MUST describe the application level
   information associated with the Info Package.  

I believe the MUST is correct.

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 27 Oct 2009 18:37:36 +0100

Some new comments and revision of one previous comment:

33)     Section 1:

   Use of the INFO method does not constitute a separate dialog usage.
   INFO messages are always part of, and share the fate of, an invite
   dialog usage [RFC5057].  INFO messages cannot be sent as part of
   other dialog usages.

Replace "invite" with upper case as I believe this is the RFC 3261 convention.

34)     Section 3.2:

   The indication of Info Packages can take place during the dialog
   establishment, and during a target refresh.  This includes INVITE,
   UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx
   only).  Note that the UAC is not required to indicate its set of Info
   Packages in the initial INVITE request.

This I guess supports the text in the table in section 6.1:

Header field where   ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR
------------------------------------------------------------------------
Info-Package   R      -   -   -   -   -   -   -   m*  -   -   -   -   -
Recv-Info      R      o   -   -   o   o   o   o   -   -   o   -   -   -
Recv-Info      2xx    o   -   -   o   o   -   o   -   -   o   -   -   -
Recv-Info      1xx    o   -   -   o   o   -   o   -   -   o   -   -   -
Recv-Info      r      o   -   -   -   o   -   o   -   -   o   -   -   -

but this leaves a lot of open questions in my mind as to the support of the Recv-Info header in various methods, as follows:

-       what is the purpose in the REGISTER request, and does this have any impact on a future dialog usage? Does it indicate willingness to support in all future INVITE dialogs. In the absence of any further text in the document I would rather take it out. If there really is some future usage, then we need more text in the document that just the appearance in the table.

-       can't REFER or SUBSCRIBE be used as a target refresh request within an INVITE dialog usage. I don't particularly want to add a usage, but I think this points to a lack of precision of the section 3.2 text, which in some ways I would like to contain RFC 2119 language as well. I think personally I would prefer to limit the Recv-Info header usage to only the INVITE transaction and the UPDATE transaction and be very precise on that. I see no real use for its appearance in PRACK, ACK.

-       section 3.2 needs to deal with the OPTIONS usage, which I think is valid.

-       if we have a 4xx - 6xx response to a reINVITE, wh       y is the support different that that for an UPDATE?

35)     Section 5.1:

For the supported header field tables I see no listing for the following headers:

-       Is a 415 response to INFO allowed containing the Accept header field?

-       Allow-Events (which I think is like Allow and appears in all requests and 2xx responses).

-       Referred-By header (again which I thought could appear in all methods).

-       Request-Disposition (again all methods).

-       Geolocation-Error (all responses).

-       Resource-Priority (allowed in all requests and responses, and needed if priority is applied on a per transaction basis rather than set for the entire dialog, which is one of the options in RFC 4412).

-       Accept-Resource-Priority in 2xx and 417 responses.

I would also comment on the following for which entries appear.

-       Organization. Given the semantics of this, it would be the same as appears in the original INVITE that created the dialog. The use case mentioned in RFC 3261 does not apply to subsequent requests within a dialog. Moreover I think it is harmful if people think they can use this header to carry information that really belongs in the application. Therefore I would exclude it.

-       Allow. RFC3261 allows this in all responses according to my interpretation, rather than specifically 2xx and 405 (which I agree do get special mention). The entry for a 405 response should be m as it is mandatory, but o for all other responses.

-       Privacy. Listed for requests only. I have an understanding that this is also allowed in responses.

-       Reason. Listed for responses only. Currently it is allowed in requests (BYE and CANCEL in particular) and not responses. There are proposals to extend it to responses but they have not been adopted yet. I suspect the use cases for this header field in INFO are pretty much non-existent in any case.

-       Can I check that the Accept header field is not needed for 2xx responses. RFC 3261 provides for its usage in certain methods, but I am not sure about whether there is a use case in INFO.

-       Proxy-Authenticate. I though was also allowed for a 401 response as well as a 407 response.

-       Does the Retry-After header also apply to 413 responses and 500 responses, or are these responses not valid for INFO.

Additional input on the following comment:

> I believe we also need to define whether the response code
> applies to the transaction or the dialog. It obviously has to
> be the transaction.
>

I do note the following text in 7.3

7.3.  Dialog Fate Sharing

   As described in [RFC5057], an INFO request is always part of an
   INVITE dialog usage.

However as we have a specific new response code that represents a failure of the INFO method extension rather than any specific package, I believe the actions for 469 in respect of the dialog usage should be defined in this document.

regards

Keith

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, October 27, 2009 2:35 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02
>
> Various miscellaneous comments. I have not yet trawled
> through all the other comments and discussion to find if
> these have already been made elsewhere. I suspect I will find
> some other comments at a later time.
>
> 2)    General. Can we fix on the term of either "Info Package
> definition" or "Info Package specification" and use it
> consistently (in full) throughout where we mean that term.
>
> 3)    Section 3.2
>
> Insert "receive" as indicated. Replace "invite" with upper
> case as I believe this is the RFC 3261 convention.
>
> I do not believe this should be a MUST, because it is surely
> already a MUST in RFC 3261 - all we need to do is write an
> informative sentence that in accordance with RFC 3261 the
> Allow header also indicates INFO requests.
>
> 7)    Section 3.3:
>
> 3.3.  Package Versioning
>
> As this is all part of the Info Package name, and needs to
> form part of the Info Package specification if used, I think
> all the text here should be moved to section 10.3, and this
> section header deleted.
>
> Surely this is something where the MUST can only be met by
> the designer of the package, and therefore it belongs in section 10.
>
> 9)    Section 4.3:
>
> The MUST here has to be in section 10. This paragraph needs
> to remove the requirement, and refer to section 10 instead.
>
> 12)   Section 4.4:
>
> The second paragraph above contradicts the first above. I
> assume that means that there is a hidden condition that is
> missing from the first paragraph. Something along the lines
> of "that is otherwise syntactically correct and well structured".
>
> 13)   Section 4.4:
>
> I believe we also need to define whether the response code
> applies to the transaction or the dialog. It obviously has to
> be the transaction.
>
> 14)   Section 4.6:
>
> Given that nowhere else in the document do we mention CSeq in
> this respect, I don't see how it can. I suspect we mean
> something more like
>
> Change "must be specified" to "are specified". If we need a
> real MUST, then it has to be in section 10 in any case, and I
> would expect more on this issue there.
>
> 16)   Section 6.2:
>
> The MUST part of this paragraph belongs in section 10. It is
> not something the implementor of the Inof-Package header
> field can directly comply with.
>
> 17)   Section 7.3:
>
> Please do not start a sentence containing RFC 2119 language
> with the word "Note". It confuses the hell out of people who
> understand that everything following that word is
> informative. In any case, the first half of this sentence is
> surely impossible in the ABNF and therefore the MUST is superfluous.
>
> 19)   Section 9.3.
>
> The first sentence of the above is fine. However the second
> sentence is not conformable by implementations of this
> specification. So I believe the "MUST" is incorrect and
> should be replaced by something more descriptive.
>
> 20)   Section 10.1:
>
> As for the second sentence, assuming that we do not mean an
> RFC 2119 SHOULD, which I believe we do not, reword as
> follows: "It is bad practice for Info Package defintions to
> repeat procedures defined in this specification, unless..."
>
> 21)   Section 10.1:
>
> Why do we allow the potential for a separate name for the
> package, and the value that appears in the header fields. I
> see this causing mixed usage in the IANA registrations.
> Surely it is simpler that whatever appears in the header
> fields is by definition the package name. It works for event
> packages surely.
>
> 25)   Section 10.4
>
> I don't think we need the MUST here. By virtue of the fact
> that the Info Package specification defines only one Info
> Package, it can only define parameters to be associated with
> one Info Package. Yes other packages may define a parameter
> with the same name, but we are not precluding that anyway. So
> turn the second sentence into something informative rather
> than RFC 2119.
>
> 26)   Section 10.4
>
> I don't believe we need the MUST here. We merely need a
> sentence that "the registration requirements for option tags
> are defined in ...". As you have only made this an
> informative reference in any case, that surely has to happen.
>
> 28)   Section 10.6
>
> I believe this is unduly onerous for Info Package definitions
> not published by IETF and goes beyond what we require for
> media feature tags. They need to fit their zpecification
> structure. I believe that all we need to say is that the
> registration requirements for IANA need to be readily
> identifiable to IANA by including them in a single part of
> the document to which IANAs attention is drawn at the time of
> the registration request.
>
> 32)   Section 10.11
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 27 Oct 2009 18:42:32 +0100

Is that all you have to say???????

Just kidding. I am half way with your initial comments, and they were
very good :) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
Sent: 27. lokakuuta 2009 19:38
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02

33)     Section 1:

Replace "invite" with upper case as I believe this is the RFC 3261
convention.

34)     Section 3.2:

but this leaves a lot of open questions in my mind as to the support of
the Recv-Info header in various methods, as follows:

-       what is the purpose in the REGISTER request, and does this have
any impact on a future dialog usage? Does it indicate willingness to
support in all future INVITE dialogs. In the absence of any further text
in the document I would rather take it out. If there really is some
future usage, then we need more text in the document that just the
appearance in the table.

-       can't REFER or SUBSCRIBE be used as a target refresh request
within an INVITE dialog usage. I don't particularly want to add a usage,
but I think this points to a lack of precision of the section 3.2 text,
which in some ways I would like to contain RFC 2119 language as well. I
think personally I would prefer to limit the Recv-Info header usage to
only the INVITE transaction and the UPDATE transaction and be very
precise on that. I see no real use for its appearance in PRACK, ACK.

-       section 3.2 needs to deal with the OPTIONS usage, which I think
is valid.

-       if we have a 4xx - 6xx response to a reINVITE, wh       y is the
support different that that for an UPDATE?

35)     Section 5.1:

For the supported header field tables I see no listing for the following
headers:

-       Is a 415 response to INFO allowed containing the Accept header
field?

-       Allow-Events (which I think is like Allow and appears in all
requests and 2xx responses).

-       Referred-By header (again which I thought could appear in all
methods).

-       Resource-Priority (allowed in all requests and responses, and
needed if priority is applied on a per transaction basis rather than set
for the entire dialog, which is one of the options in RFC 4412).

-       Organization. Given the semantics of this, it would be the same
as appears in the original INVITE that created the dialog. The use case
mentioned in RFC 3261 does not apply to subsequent requests within a
dialog. Moreover I think it is harmful if people think they can use this
header to carry information that really belongs in the application.
Therefore I would exclude it.

-       Allow. RFC3261 allows this in all responses according to my
interpretation, rather than specifically 2xx and 405 (which I agree do
get special mention). The entry for a 405 response should be m as it is
mandatory, but o for all other responses.

-       Privacy. Listed for requests only. I have an understanding that
this is also allowed in responses.

-       Reason. Listed for responses only. Currently it is allowed in
requests (BYE and CANCEL in particular) and not responses. There are
proposals to extend it to responses but they have not been adopted yet.
I suspect the use cases for this header field in INFO are pretty much
non-existent in any case.

-       Can I check that the Accept header field is not needed for 2xx
responses. RFC 3261 provides for its usage in certain methods, but I am
not sure about whether there is a use case in INFO.

-       Proxy-Authenticate. I though was also allowed for a 401 response
as well as a 407 response.

-       Does the Retry-After header also apply to 413 responses and 500
responses, or are these responses not valid for INFO.

Additional input on the following comment:

> I believe we also need to define whether the response code applies to 
> the transaction or the dialog. It obviously has to be the transaction.
>

7.3.  Dialog Fate Sharing

However as we have a specific new response code that represents a
failure of the INFO method extension rather than any specific package, I
believe the actions for 469 in respect of the dialog usage should be
defined in this document.

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Oct 2009 01:48:29 +0100

One new comment

36)     Subclause 6.1. The table specifies:

But section 3.1 lists:

   A UA which supports the Info Package mechanism MUST indicate, using
   the Revc-Info header field, the set of Info Packages for which it is
   willing to receive INFO request.  A UA can list multiple Info
   Packages in a single Recv-Info header field, and the UA can use
   multiple Recv-Info header fields.

and

   If a UA is not willing to receive INFO requests for any Info Packages, during
   dialog establishment or later during the invite INVITE dialog usage, the UA
   MUST indicate this by including a Recv-Info header field with a 'nil'
   value.  This informs other UAs that the UA still supports the Info
   Package mechanism.

Even if I only support legacy usage, I don't seem to find any text that waives the requirement for implementations that support this i-d to support the Recv-Info requirements. It is only the implementations that support and are conformant to RFC 2976 that will not include this header field. That means that if Recv-Info is allowed in a message, and I support this extension, I must include the header field, even if its value is "nil". Surely that would make all the entries in the table above "m".

regards

Keith

> Sent: Tuesday, October 27, 2009 5:38 PM
> To: [email-masked]
> but this leaves a lot of open questions in my mind as to the
> support of the Recv-Info header in various methods, as follows:
>
> -       what is the purpose in the REGISTER request, and does
> this have any impact on a future dialog usage? Does it
> indicate willingness to support in all future INVITE dialogs.
> In the absence of any further text in the document I would
> rather take it out. If there really is some future usage,
> then we need more text in the document that just the
> appearance in the table.
>
> -       can't REFER or SUBSCRIBE be used as a target refresh
> request within an INVITE dialog usage. I don't particularly
> want to add a usage, but I think this points to a lack of
> precision of the section 3.2 text, which in some ways I would
> like to contain RFC 2119 language as well. I think personally
> I would prefer to limit the Recv-Info header usage to only
> the INVITE transaction and the UPDATE transaction and be very
> -       if we have a 4xx - 6xx response to a reINVITE, wh
>   y is the support different that that for an UPDATE?
>
> 35)     Section 5.1:
>
> -       Resource-Priority (allowed in all requests and
> responses, and needed if priority is applied on a per
> transaction basis rather than set for the entire dialog,
> which is one of the options in RFC 4412).
>
> -       Organization. Given the semantics of this, it would
> be the same as appears in the original INVITE that created
> the dialog. The use case mentioned in RFC 3261 does not apply
> to subsequent requests within a dialog. Moreover I think it
> is harmful if people think they can use this header to carry
> information that really belongs in the application. Therefore
> I would exclude it.
>
> -       Allow. RFC3261 allows this in all responses according
> to my interpretation, rather than specifically 2xx and 405
> (which I agree do get special mention). The entry for a 405
> response should be m as it is mandatory, but o for all other
> responses.
>
> -       Privacy. Listed for requests only. I have an
> understanding that this is also allowed in responses.
>
> -       Reason. Listed for responses only. Currently it is
> allowed in requests (BYE and CANCEL in particular) and not
> responses. There are proposals to extend it to responses but
> they have not been adopted yet. I suspect the use cases for
> this header field in INFO are pretty much non-existent in any case.
>
> -       Can I check that the Accept header field is not
> needed for 2xx responses. RFC 3261 provides for its usage in
> certain methods, but I am not sure about whether there is a
> use case in INFO.
>
> -       Does the Retry-After header also apply to 413
> responses and 500 responses, or are these responses not valid
> for INFO.
>
>
>
>
> applies to
> However as we have a specific new response code that
> represents a failure of the INFO method extension rather than
> any specific package, I believe the actions for 469 in
> respect of the dialog usage should be defined in this document.
>
>
> regards
>
> Keith
>
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 28 Oct 2009 07:12:55 +0100

Hi Keith,

So, I guess we somewhere would need text saying that UAs that *only*
support legacy INFO usages are not mandated to use the Recv-Info header?

Regards,

Christer

> Sent: 28. lokakuuta 2009 2:48
> To: DRAGE, Keith (Keith); [email-masked]
> Even if I only support legacy usage, I don't seem to find any 
> text that waives the requirement for implementations that 
> support this i-d to support the Recv-Info requirements. It is 
> only the implementations that support and are conformant to 
> RFC 2976 that will not include this header field. That means 
> that if Recv-Info is allowed in a message, and I support this 
> extension, I must include the header field, even if its value 
> is "nil". Surely that would make all the entries in the table 
> above "m".
> 
> regards
> 
> Keith
> 
> 
> > but this leaves a lot of open questions in my mind as to 
> the support 
> > of the Recv-Info header in various methods, as follows:
> >
> > this have any impact on a future dialog usage? Does it indicate 
> > willingness to support in all future INVITE dialogs.
> rather take 
> > it out. If there really is some future usage, then we need 
> more text 
> > in the document that just the appearance in the table.
> >
> > request within an INVITE dialog usage. I don't particularly want to 
> > add a usage, but I think this points to a lack of precision of the 
> > section 3.2 text, which in some ways I would like to 
> contain RFC 2119 
> > language as well. I think personally I would prefer to limit the 
> > Recv-Info header usage to only the INVITE transaction and 
> the UPDATE 
> > transaction and be very precise on that. I see no real use for its 
> > appearance in PRACK, ACK.
> >
> > responses, and needed if priority is applied on a per transaction 
> > basis rather than set for the entire dialog, which is one of the 
> > options in RFC 4412).
> >
> the dialog. 
> > The use case mentioned in RFC 3261 does not apply to subsequent 
> > requests within a dialog. Moreover I think it is harmful if people 
> > think they can use this header to carry information that really 
> > belongs in the application. Therefore I would exclude it.
> >
> > to my interpretation, rather than specifically 2xx and 405 (which I 
> > agree do get special mention). The entry for a 405 response 
> should be 
> > m as it is mandatory, but o for all other responses.
> >
> > There are proposals to extend it to responses but they have 
> not been 
> > adopted yet. I suspect the use cases for this header field 
> in INFO are 
> > pretty much non-existent in any case.
> >
> > needed for 2xx responses. RFC 3261 provides for its usage 
> in certain 
> > methods, but I am not sure about whether there is a use 
> case in INFO.
> >
> > responses and 500 responses, or are these responses not valid for 
> > INFO.
> >
> >
> >
> >
> > >    If a UA receives an INFO request associated with an 
> Info Package 
> > > that
> > >    Multiple Dialog Usages [RFC5057], this represents a 
> Transaction 
> > > Only
> > >    failure.
> > >
> > > I assume that "(see Section 11.6)" or something similar 
> is meant in 
> > > the end of the first sentence.
> > >
> > failure of the INFO method extension rather than any 
> specific package, 
> > I believe the actions for 469 in respect of the dialog 
> usage should be 
> through all 
> > > the other comments and discussion to find if these have 
> already been 
> > > made elsewhere. I suspect I will find some other comments 
> at a later 
> > > time.
> > >
> consistently 
> > > (in full) throughout where we mean that term.
> > >
> > > 3)    Section 3.2
> > >
> > >    the Revc-Info header field, the set of Info Packages 
> for which it 
> > > is
> > >    dialog establishment or later during the INVITE dialog 
> usage, the 
> > > UA
> > >                                             ^^^^^^^
> > >    MUST indicate this by including a Recv-Info header 
> field with a 
> > > 'nil'
> > >    value.
> > >
> > > Insert "receive" as indicated. Replace "invite" with 
> upper case as I 
> > > believe this is the RFC 3261 convention.
> > >
> > >    until it has received an indication that the remote UA 
> is willing 
> > > to
> > > I do not believe this should be a MUST, because it is 
> surely already 
> > > a MUST in RFC 3261 - all we need to do is write an informative 
> > > sentence that in accordance with RFC 3261 the Allow header also 
> > > indicates INFO requests.
> > >
> > > 7)    Section 3.3:
> > >
> > > 3.3.  Package Versioning
> > >
> > >    Specific Info Package payloads MAY contain version 
> information, 
> > > which
> > >    is handled by the applications associated with the 
> Info Package, 
> > > but
> > > As this is all part of the Info Package name, and needs 
> to form part 
> > > of the Info Package specification if used, I think all 
> the text here 
> > > should be moved to section 10.3, and this section header deleted.
> > >
> > >    assigned, in order to be able distinguish body parts 
> associated 
> > > with
> > > Surely this is something where the MUST can only be met by the 
> > > designer of the package, and therefore it belongs in section 10.
> > >
> > > 9)    Section 4.3:
> > >
> > >    NOTE: Some SIP functions that are orthogonal to INFO 
> may insert 
> > > body
> > > Is this not just a repeat of the requirement earlier in 
> the section 
> > > (1 paragraph before the note).
> > >
> > > 11)   Section 4.3:
> > >
> > >    This document does not define Info Package specific 
> rules on how 
> > > body
> > > The MUST here has to be in section 10. This paragraph needs to 
> > > remove the requirement, and refer to section 10 instead.
> > >
> > > 12)   Section 4.4:
> > >
> > >    If a UA receives an INFO request for legacy usage, for 
> which no 
> > > Info-
> > >    Server Failure (5xx) and Global Failure (6xx) as 
> appropriate for 
> > > the
> > >    request.
> > >
> > > The second paragraph above contradicts the first above. I assume 
> > > that means that there is a hidden condition that is 
> missing from the 
> > > first paragraph. Something along the lines of "that is otherwise 
> > > syntactically correct and well structured".
> > >
> > > 13)   Section 4.4:
> > >
> > >    If a UA receives an INFO request associated with an 
> Info Package 
> > > that
> > >    Multiple Dialog Usages [RFC5057], this represents a 
> Transaction 
> > > Only
> > >    failure.
> > >
> > > I assume that "(see Section 11.6)" or something similar 
> is meant in 
> > > the end of the first sentence.
> > >
> > > I believe we also need to define whether the response 
> code applies 
> > > to the transaction or the dialog. It obviously has to be the 
> > > transaction.
> > >
> > > 14)   Section 4.6:
> > >
> > > Given that nowhere else in the document do we mention 
> CSeq in this 
> > > respect, I don't see how it can. I suspect we mean something more 
> > > like
> > >
> > > Change "must be specified" to "are specified". If we need a real 
> > > MUST, then it has to be in section 10 in any case, and I would 
> > > expect more on this issue there.
> > >
> > > 16)   Section 6.2:
> > >
> > >    specifications MUST register the values with IANA.  
> These values 
> > > are
> > > The MUST part of this paragraph belongs in section 10. It is not 
> > > something the implementor of the Inof-Package header field can 
> > > directly comply with.
> > >
> > > 17)   Section 7.3:
> > >
> > > Please do not start a sentence containing RFC 2119 
> language with the 
> > > word "Note". It confuses the hell out of people who 
> understand that 
> > > everything following that word is informative. In any case, the 
> > > first half of this sentence is surely impossible in the ABNF and 
> > > therefore the MUST is superfluous.
> > >
> > > 19)   Section 9.3.
> > >
> > >    Package always contains an Info-Package header field.  
> A legacy 
> > > INFO
> > > The first sentence of the above is fine. However the 
> second sentence 
> > > is not conformable by implementations of this specification. So I 
> > > believe the "MUST" is incorrect and should be replaced by 
> something 
> > > more descriptive.
> > >
> > > 20)   Section 10.1:
> > >
> > >    If an Info Package extends or modifies the behavior 
> described in 
> > > this
> > > As for the second sentence, assuming that we do not mean 
> an RFC 2119 
> > > SHOULD, which I believe we do not, reword as
> > > follows: "It is bad practice for Info Package defintions 
> to repeat 
> > > procedures defined in this specification, unless..."
> > >
> > > 21)   Section 10.1:
> > >
> package, 
> > > and the value that appears in the header fields. I see 
> this causing 
> > > mixed usage in the IANA registrations.
> fields is 
> > > by definition the package name. It works for event 
> packages surely.
> > >
> > > 25)   Section 10.4
> > >
> > > I don't think we need the MUST here. By virtue of the 
> fact that the 
> > > Info Package specification defines only one Info Package, it can 
> > > only define parameters to be associated with one Info 
> Package. Yes 
> > > other packages may define a parameter with the same name, 
> but we are 
> > > not precluding that anyway. So turn the second sentence into 
> > > something informative rather than RFC 2119.
> > >
> > > 26)   Section 10.4
> > >
> > >    NOTE: Info Package parameters defined for specific 
> Info Packages 
> > > may
> > > I don't believe we need the MUST here. We merely need a sentence 
> > > that "the registration requirements for option tags are 
> defined in 
> > > ...". As you have only made this an informative reference in any 
> > > case, that surely has to happen.
> > >
> > > 28)   Section 10.6
> > >
> > >    The Info Package specification MUST define what type 
> of message 
> > > body
> > >    restrictions in the usage of the Info Package.  For 
> example, an 
> > > Info
> > >    with the Info Package needs to handle situations which 
> can occur 
> > > due
> > >    to overlapping requests.
> > >
> > > I believe this is unduly onerous for Info Package definitions not 
> > > published by IETF and goes beyond what we require for 
> media feature 
> > > tags. They need to fit their zpecification structure. I 
> believe that 
> > > all we need to say is that the registration requirements for IANA 
> > > need to be readily identifiable to IANA by including them in a 
> > > single part of the document to which IANAs attention is 
> drawn at the 
> > > time of the registration request.
> > >
> > > 32)   Section 10.11
> > >

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Oct 2009 17:54:07 -0500

> support legacy INFO usages are not mandated to use the Recv-Info header?

Isn't that sort of like saying "Nodes not supporting this specification 
are not required to do anything this specification says"?

seems more than pointless to me.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Oct 2009 19:14:29 -0400

> seems more than pointless to me.

No, its not like that.

This specification is *replacing* RFC 2976.
So this document *is* the specification of legacy behavior as well as 
the new IP behavior.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Oct 2009 21:18:59 -0500

On Oct 28, 2009, at 6:14 PM, Paul Kyzivat wrote:

>> Isn't that sort of like saying "Nodes not supporting this  
>> specification are not required to do anything this specification  
>> says"?
> So this document *is* the specification of legacy behavior as well  
> as the new IP behavior.
>

Ah well, in that case, yes, we need it to say that.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Oct 2009 08:38:23 +0100

Hi,
 
>are not required to do anything this specification says"?

No. The draft also specifies legacy INFO usage. 

There were WGLC comments that we should make that more clear, instead of simply refering to the RFC for legacy procedures.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Oct 2009 23:48:32 +0100

Hi Keith,

I've collected the comments from all your e-mails into one single reply.
I appretiate the numbering you've used, because it really made it easier
to refer to other comments when needed.

-----------

>response" rather than "200 OK response".

Fixed.

I did the same for other response codes in the document also, e.g. 481
and 469.

-----------

>consistently (in full) throughout where we mean that term.

Fixed.

Now there should only be "Info Package specification".

-----------
 
>the Revc-Info header field, the set of Info Packages for 
>which it is willing to receive an INFO request.  
>                       ^^^
> 

The text is supposed to say "receive INFO requestS".

-----------

value.  
> 
>Insert "receive" as indicated.

Fixed.

convention.

"invite dialog usage" is RFC 5057 terminology.

-----------

>    For a specific dialog, a UA MUST NOT send INFO requests associated
with Info Packages that the
>Are these not the same requirement. We need to eliminate one.

I did the following:

In section 3.2, which talks about *Info Packages*, we say that Info
Packages must not be sent until an indication that the other entity
wants to receive them has arrived.

    "For a specific dialog, a UA MUST NOT send an INFO request
associated with an Info Package
    until it has received an indication that the remote UA is willing to
receive INFO requests for that Info Package"

In section 4.2, which talks about the *INFO method*, we say that INFO
can be sent once a (early-)dialog has been established. Because, that
applies also to legacy INFO usage. And, since 4.2 already contains text
which says that INFOs can be sent once the dialog has been established,
I will remove the text You refered to above.

-----------

>Allow header also indicates INFO requests.

I modified the text as below:

    "Likewise, even if a UA uses the Recv-Info header field to indicate
that it 
    supports the Info Package mechanism, in addition the UA also
indicates support 
    of the INFO method using the Allow method."

The paragraph already earlier refers to 3261 for the Allow method, so I
don't think we need it twice.

-----------
 
>all the text here should be moved to section 10.3, and this 

Fixed.

-----------

>the designer of the package, and therefore it belongs in section 10.

Pending.

As the whole section will change based on the body part discussion, I
suggest that we come back to section 4.3 once the
new text have been submitted.

-----------

>9)	Section 4.3:
> 
>    NOTE: Some SIP functions that are orthogonal to INFO may 
>    insert body parts unrelated to the Info Package.
> 
>Change "may" to "can".

Fixed.

-----------

>section (1 paragraph before the note).

Pending.

See reply on comment 8.

-----------

>11)	Section 4.3:
> 
>    This document does not define Info Package specific rules 
>    on how body parts associated with Info Packages are to be inserted 
>    into multipart body parts, and what type of multiparts are used.
If an 
>    Info Package requires special rules regarding the usage of
multipart body parts,
>to remove the requirement, and refer to section 10 instead.

Pending.

See reply on 8).

-----------

>    which no Info-Package is associated (the INFO request does not
contain an Info-
>of "that is otherwise syntactically correct and well structured".

Fixed.

I added the following text:

"if the request is otherwise syntactically correct and well structured."

I added the same text also to the paragraph above, which talks about 200
(OK) responses
for I-P INFO requests.

-----------
 
> 13)	Section 4.4:
> 
>    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
>meant in the end of the first sentence. 

Fixed.
 
failure of the INFO method extension rather than any specific package, I
believe the actions for 469 in respect of the dialog usage 
>should be defined in this document.

Pending.

I initiated a dedicated e-mail thread on this issue.

-----------

>    if an INFO request is received out of order.

I modified the text as below:

"The Info Package mechanism does not define a delivery order mechanism.
Many Info Packages can rely on the CSeq header field to detect if an 
INFO request is received out of order."

-----------

>    delivery, those mechanisms, and related procedures, must 
>    be specified as part of the associated Info Package, and possible 
>    sequence numbers etc must be defined as application data.
> 

Fixed.

-----------

>    specifications MUST register the values with IANA.  These 
>    values are Specification Required [RFC5226].
> 

I keept the 2 first sentences in 6.2:

"This document does not define values for Info-Package types.
Individual Info Package specifications define these values."

-----------
 
>17)	Section 7.3:
> 
>    One needs to consider the fate of the dialog usage of an 
>    INFO request is rejected.  In some cases it may be acceptable that
the whole
>    maintain the dialog usage.

Fixed.

-----------

>18)	Section 8.2:
> 
>    NOTE on the Recv-Info production: if the header field 
>    value is "nil", the header field MUST NOT contain any other 
>    Info Packages, and the SIP message MUST NOT contain more than 
>    one Recv-Info header field.
> 

I modified the text as below:

"If a UA inserts a "nil" value in the Recv-Info header field, it MUST
NOT indicate 
additional Info-Packages."

-----------
 
>    Package always contains an Info-Package header field.  A 
>    legacy INFO request MUST NOT contain an Info-Package header field.
> 

I modified the text as below:

"As described in Section 4, an INFO request associated with an Info
Package always contains 
an Info-Package header field. A UA MUST NOT insert an Info-Package
header filed in a legacy INFO request."

-----------
 
>    described in this document, it MUST be described in the definition 
>    for that Info Package. Info Package definitions should not repeat 
>    procedures defined in this specification, unless needed for
clarification or
>Change "it MUST" to "that behaviour MUST"

Fixed.

>repeat procedures defined in this specification, unless..."

Fixed. 

See my reply to comment 21).

-----------

>Do we mean "Info Packages" here or "Info Package Definitions"? (twice)

"Info Package Definitions", which based on commet 2) now has become
"Info Package Specifications"

I modified the two paragraphs as below:

"If an Info Package specification extends or modifies the behavior
described in this
document, that behaviour MUST be described in the specification for that
Info Package.
It is bad practice for Info Package specifications to repeat procedures
defined in this document, 
unless needed for clarification or emphasis purpose."

"Info Package specifications MUST NOT weaken any behavior designated
with "SHOULD"
or "MUST" in this specification.  However, Info Packages definitions MAY
strengthen
"SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if
applications associated with the Info Package requires it.

-----------
 
>    solving a specific use-case.

Fixed.

-----------

>   (e.g.  "Info Package for X").

Fixed.

-----------

>    "infoX") to be used to indicate support of this package in 
>    the Recv-Info and Info-Package header fields.
> 

Pending.

Someone else had this same comment. My reply was giving an example, that
the name could be
Something like "Info Package for DTMF transport", while the header field
could be something
like "infoDtmf"

Having said that, the draft which defines the Info Package will of
course have a name by default, so I can remove the text if it confuses
people.

But, then I think we should maybe also change the section name to
"Recv-Info/Info-Package header field value", or something like that...

-----------
 
>turn the second sentence into something informative rather 

Pending.

The current text was provided by someone, but I can think of some
re-wording.

But, I was actually wondering whether we should allow Info Packages to
use parameters (not only the name, but also the semantics) defined in
other Info Packages.
So, instead of re-defining the same parameter, the package specification
could simply refer to the Info Package specification which defines the
parameter.

I initiated a separate e-mail thread on this issue.

-----------

>26)	Section 10.4
> 
>    NOTE: Info Package parameters defined for specific Info 
>    Packages may share the name with parameters defined for other Info
Packages, but
>    the parameter semantics are specific to the Info Package for which

Fixed.

-----------

>informative reference in any case, that surely has to happen.

Fixed.

-----------

>28)	Section 10.6
> 
>    The Info Package specification MUST define what type of 
>    message body parts are associated with the Info Package, and MUST
refer to
>The text above appears to preclude the Info Package specification
defining them itself.

That is not the intention.

I modified the text as below:

    "The Info Package specification MUST define what type of 
    message body parts are associated with the Info Package, and the
specification MUST either define
    those body parts, or refer to specifications where the syntax,
semantics and MIME type 
    of the body parts are described."

-----------

>    Package may require support of other SIP extensions (e.g. reliable

Fixed.

-----------

>    restrictions, it cannot be assumed that overlapping 
>    requests would be rejected.  As defined in Section 4.4, in most
cases a 200 
>    OK response will be sent for the INFO request.  The application
logic 
>    associated with the Info Package needs to handle situations which
can 
>    occur due to overlapping requests.
> 

Fixed.

-----------

>media feature tags. They need to fit their specification 

Pending.

Could you provide some text, please?

-----------

>I believe the MUST is correct.

I modified the text in section 4.3 to more informative, as below:

	"Info Package specifications describe the application level 
	information associated with the Info Package, and the syntax,
content and MIME value
	of the body parts associated with the Info Package."

I modified the text in 10.10, by replacing SHOULD with MUST, as below:

	"The Info Package specification MUST contain a description of
the application 
	procedures associated with the Info Package, or alternatively
refer to application 
	procedures defined elsewhere."

-----------
 
convention.

See my reply to comment 4).

-----------

any impact on a future dialog usage? Does it indicate willingness to
support in all future INVITE dialogs. In the absence of any 
>further text in the document I would rather take it out. If there
really is some future usage, then we need more text in the document that
just the appearance in the table.

There is some text about REGISTER in Section 3.4.

within an INVITE dialog usage. I don't particularly want to add a usage,
but I think this points to a lack of precision of the section 
>3.2 text, which in some ways I would like to contain RFC 2119 language
as well.

We used to have REFER and SUBSCRIBE there, but I was asked to remove it.

>I think personally I would prefer to limit the Recv-Info header usage
to only the INVITE transaction and the UPDATE 

This was discussed a long time ago, and I think people said that we more
or less should have the same options as we have for sending SDP.

is valid.

Section 3.5 talks about OPTIONS. Do you want me to move 3.5 (and 3.4, I
assume) as subsections to 3.2?

-       if we have a 4xx - 6xx response to a reINVITE, why is the
support different that that for an UPDATE?

It is not.

I have updated the table based on different feedback that I received,
and it now looks like:

                     ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR
------------------------------------------------------------------------
Info-Package   R      -   -   -   -   -   -   -   m*  -   -   -   -   -
Recv-Info      R      o   -   -   o   m   o   o   -   -   o   -   -   -
Recv-Info      2xx    -   -   -   o   m   -   o   -   -   o   -   -   -
Recv-Info      1xx    -   -   -   o   -   -   -   -   -   -   -   -   -
Recv-Info      469    -   -   -   -   -   -   -   m*  -   -   -   -   -
Recv-Info      r      -   -   -   o   o   -   o   -   -   o   -   -   -

			The support and usage of the Info-Package and
Recv-Info header fields is not applicalbe to
			UAs that only support legacy INFO usages.
			
			* The usage of the Info-Package header field is
not applicalbe to INFO requests and responses 
			associated with legacy INFO usages.

Pending.

Note that the table may still change, based on the outcome on the
ongoing e-mail discussion related to for which methods the Recv-Info
header can be used.

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

>For the supported header field tables I see no listing for the
following headers:

I should have supported Dean on getting rid of these tables.... ;)

field?

Fixed.

"Accept                     415      o"

I think it should be allowed. It's for sure useful for body parts
associated with legacy INFO usages.

As far as I understand it only appears in requests (and their responses)
which initiates dialogs, and OPTIONS. See section 3.3.7 of RFC 3265 (I
assume 3265bis doesn't change that).

methods).

Fixed.

"Referred-By                 R       o"

I guess nothing prevents one from using REFER to trigger an INFO in
another dialog, so...

>-       Request-Disposition (again all methods).

Fixed.

"Request-Disposition         R       o"

I am not really sure what it would be used for in a mid-dialog request,
but since 3841 allows it in with any method....

>-       Geolocation-Error (all responses).

Fixed.

"Geolocation-Error           r       o"

needed if priority is applied on a per transaction basis rather than set
for the entire dialog, which is one of the options in RFC 
>4412).

Fixed.

"Resource-Priority                   o"

>-       Accept-Resource-Priority in 2xx and 417 responses.

Fixed.

"Accept-Resource-Priority 2xx,417    o"

as appears in the original INVITE that created the dialog. The use case
mentioned in RFC 3261 does not apply to subsequent requests 
>within a dialog. Moreover I think it is harmful if people think they
can use this header to carry information that really belongs in the
application. Therefore I would exclude it.

Fixed.

"Organization                        -"

interpretation, rather than specifically 2xx and 405 (which I agree do
get special mention). The entry for a 405 response should be m 
>as it is mandatory, but o for all other responses.

Fixed.

"Allow                       R       o
 Allow                      405      m
 Allow                       r       o"

Fixed.

"Privacy                             o"

requests (BYE and CANCEL in particular) and not responses. There are
proposals to extend it to responses but they have not been 
>adopted yet. I suspect the use cases for this header field in INFO are

Fixed.

"Reason                      R       o"

See above. At least for legacy INFO usages it is needed, and I guess
someone could also insert an unsupported body part type for an Info
Package even if the package doesn't allow it.

>-       Proxy-Authenticate. I though was also allowed for a 401
response as well as a 407 response.

Fixed.

"Proxy-Authenticate         401      m"

According to 3261 it is "m" for 401 and "o" for 407.

Fixed.

"Retry-After         404,413,480,486 o
 Retry-After              500,503    o
 Retry-After              600,603    o"

In my opinion they apply also to INFO.

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

>Even if I only support legacy usage, I don't seem to find any text that
waives the requirement for implementations that support this i-d to
support the Recv-Info requirements. It is only the 
>implementations that support and are conformant to RFC 2976 that will
not include this header field. That means that if Recv-Info is allowed
in a message, and I support this extension, I must include the 
>header field, even if its value is "nil". Surely that would make all
the entries in the table above "m".

See the text below the new table I showed in my reply to comment 34).

Regards,

Christer