[sipcore] Info on INFO

[Eric Burger <[e-mail]>]

Brett -
I updated the evil table.  Please take a look.

Xavier -
UAS behavior when receiving a legacy INFO is slightly more complex,  
because the UAS can reject the request (unlike RFC 2976).

Vijay & Paul -
Thank you SO MUCH for this thorough review.

The work group and the document reflect a change that clearly is not  
clear enough: this is an advertising model, not an offer/answer model.  
There was literally one bit of textual shrapnel in Section 4 that  
might have lead to such confusion. Attila Sipos caught that and I  
fixed it in this edition of the document. That means the whole  
discussion of lifetimes and negotiation is moot.

Responses inline.


On Jun 7, 2009, at 11:31 PM, Paul Kyzivat wrote:

> Vijay,
>
> Wow! A very thorough review!!! I haven't had time to do so.
> I just provide a few observations inline on yours.
>
> 	Thanks,
> 	Paul
>
> Vijay Gurbani wrote:
>> Sorry for the long review.
>> Summary statement:
>> This draft is on the right track but has open issues,
>> described in the review.
>> First of all, thanks for tackling this particular piece of work;
>> this is good stuff and it will make life easier for many
>> developers.
>> That said, the draft needs a substantial amount of work to be ready
>> for publication, both at the editorial level and at the content  
>> level.
>> Editorially, it is currently written in a collegial and informal
>> style, which is not appropriate for a standards-track document, and  
>> an
>> important one at that.  Besides gratuitous commas and run-on
>> sentences, the draft also contains phrases like "...and so on", "some
>> may think", "It is the hope of this draft's authors", "we could be
>> lazy ...", "we require...", "use a totally externally signaled
>> channel", "can do stuff", etc. (you get the idea.)  I think that
>> choosing one author as an editor and allowing him a couple of free
>> hours and a pint or two of beer will not be a bad idea ;-)
>> General comments (3 comments):
>> ------------------------------
>> 1) When talking about entities receiving or sending INFO requests,  
>> you
>> should either stick to "UAS" and "UAC" respectively, or "server" and
>> "client", respectively.  As the text is now written, in some places
>> "UAS" is used and in other, "server" is used.

Fixed.

>> 2) Should we add a subsection in S7 on INFO refresh (see comment
>> number 10 in the next section for more context)?

Not necessary - it's always the last thing you receive (not a  
negotiation).

>> 3) I found the Appendix fairly useful as historical context.  Is the
>> idea to retain it going forward?  If so, you may want to edit it
>> carefully.  Right now it looks like it has been written by two
>> co-authors independently and then mashed together: note that SA.1 -
>> SA.4 contain pretty much the same information as SA5.
>> Substantive content-specific comments (24 comments)

I thought about it, but then decided that it really, really does not  
matter. We've been going at this for two years and two weeks. It is  
not normative and not substantive.

>> ---------------------------------------------------
>> 1) S1, third paragraph, sentence on line 9: what you are describing
>> here is more akin to a problem of deciding how to render a JPEG image
>> instead of supporting it.  The sender and receiver both support the
>> JPEG image, where "support" means they will send and receive the
>> image; it is just that the receiver does not know how to render the
>> image because the sender did not provide any hints when it sent the
>> image.
>> I think you need to phrase the discussion here in that there is a
>> multiplicity of ways to render an image received with a "image/jpeg"
>> MIME type and that the sender of the image needs to provide some  
>> hints
>> to the receiver on how to render it.  In much the same way, the new
>> INFO package proposes to provide some hints to the receiver on how to
>> make sense of the user-to-user information being exchanged in the  
>> INFO
>> message.

Enhanced.  If people are still confused, they can read RFC 3458.

>> 2) S1, page 5, fourth paragraph, it is stated that "This document
>> provides a similar framework for INVITE-based application level
>> information exchange."  Do you not mean "INFO-based application level
>> information exchange instead?

Fixed.

>> Additional comment in the same paragraph: collect all the places  
>> where
>> you talk about SUBS/NOT in one place and distinguish them from how
>> Info packages are supposed to work.  Currently, you talk about
>> SUBS/NOT, then you talk about INFO, and then circle back to SUBS/NOT
>> and hop to INFO to close the paragraph.  This leaves the reader going
>> back and forth trying to bridge the gap between how SUBS/NOT differs
>> from INFO.  While this is okay for old SIP hands, new developers who
>> do not have the history of SIP embedded in their DNA genomes will be
>> completely lost.

Fixed.

>> 3) S1, page 6, first complete paragraph on that page: I would suggest
>> that you replace "near end" and "far end" with something else; for
>> instance, instead of saying "If the far end indicates it can  
>> receive a
>> package offered by the near end,..." how about "If one peer indicates
>> it can receive a package offered by the the other peer ...".  The
>> terms "near end" and "far end" are subjective: near to who?  far from
>> who?

Done.

>> Same paragraph, you may also want to inform the reader that the
>> Recv-Info and Info-Package headers are both defined in this document.
>> That is, instead of saying "The Recv-Info header indicates ...", how
>> about "The Recv-Info header, defined in this document,  
>> indicates ...".
>> Similarly for the succeeding sentence that discusses Info-Package.

Yup.

>> 4) Section 3 requires a lot of work, IMHO; more so because this is a
>> very important section and lays down the behavior of the  
>> communicating
>> entities.  As such, as much as we can avoid ambiguity here and  
>> provide
>> clear instructions to developers, the better off we'd be in the long
>> run.  The next few issues are around making this section less  
>> ambiguous.
>> S3.1, general comment on the section: it appears that this section
>> has been written while keeping a UAS in mind.  It will be much better
>> if this section was broken down into two subsections, one discussing
>> UAS behavior and the other discussing UAC behavior.
>> 5) S3.1, first paragraph: As I read this paragraph, is becomes  
>> obvious
>> that if we do not specify in some detail how the negotiation for
>> sending Recv-Info is done, we could run into interoperability
>> problems.  For instance, given the INVITE transaction, I can see at
>> least two ways to probe for support of this package:
>> i) Initiating-UA triggered INFO package negotiation:
>>    INVITE sip:...
>>    Recv-Info: foo, bar
>>    ...
>>    180 Ringing sip:...
>>    Recv-Info: bar
>> or
>> ii) Target-UA triggered INFO package negotiation:
>>     INVITE sip:...
>>     ...
>>     180 Ringing SIP/2.0
>>     Recv-Info: foo, bar
>>     ...
>>     ACK sip:...
>>     Recv-Info: bar
>> In case (i), the UAS could have indicated support for the INFO
>> packages in a 200 as well.  In case (i), the ACK will not have any
>> Recv-Info headers (please confirm.)
>> Now, to make matters more complex, from the table in S5.2, it appears
>> that INFO negotiations can be done in a PRACK/200 and an UPDATE/200  
>> as
>> well.  While doing the INFO negotiation in UPDATE/200 is fine, I am
>> curious why we would want to do it in PRACK/200, since that  
>> particular
>> transaction is nested within the INVITE transaction (thus adding more
>> complexity when it could easily be avoided.) Is that the intent?  Are
>> we sure we want to add this additional complexity on top of PRACK?   
>> Is
>> there a good reason why we would want to take on additional  
>> complexity
>> introduced by PRACK.  If there is, we should at least provide clear
>> guidelines.
>
> There is need to get the negotiation done well before the ACK, so  
> that the INVO can be used before the request is accepted. (At least  
> I think it is.)
>
> That is covered in case (1), but if it is UAS that wants to use it,  
> then case (2) isn't enough. This could be covered using 18x/prack.  
> Or it could be covered using UPDATE.
>
>> So, there are two specific comments here: (1) Provide better
>> guidelines to implementers (see case i and ii above) including  
>> showing
>> portions of a SIP message and flow to be more explicit on the intent;
>> and (2) determine if we need to do INFO event negotiation in a PRACK,
>> and if so, provide better guidelines, including showing call flows  
>> and
>> portions of SIP messages to be more explicit of the intent.

Rewritten, and really, really clear this is NOT a negotiation but and  
advertisement.  It is much LESS complex then you thought it was.

>> 6) S3.1, page 7, last paragraph, second last line:
>> s/the UAS MUST list the preferred Info Package lexically earlier in
>> the message./it MUST maintain an ordinal sequence of the preferred  
>> Info
>> Package among others./

People understand the word 'lexical' from SMTP. Only one RFC has the  
phrase "ordinal sequence": RFC 5401 (3491). It does not have the  
meaning there we want to use here.

>> 7) S3.1, page 8, towards the top of the page it is said that "Listing
>> a package multiple times does no harm."  I am curious, why even allow
>> the listing of the same package multiple times?  It will make parsing
>> more cumbersome and force the receiving side to maintain a larger set
>> of Info packages where some elements may occur multiple times.  All
>> this can be trivially avoided by just mandating that packages must be
>> listed once.

Sigh. OK.

>> 8) S3.1, the indented "NOTE" in the middle of page 8: I would advise
>> to make the text more terse and more formal; something like the
>> following (please feel free to edit as you see fit):
>>  NOTE: While an empty Recv-Info header could be used to indicate
>>  that the sender does not wish to receive any Info packages, such
>>  usage will fall short should a richer negotiation strategy be
>>  required at some later time.  Using the value 'nil' makes the
>>  intent of the sender of the Recv-Info request explicit.

Gone. "Just say 'nil.'"

>> 9) S3.1, page 8, in the discussion on the second half of that page, I
>> am lost as to your intent.  The initiating UA sends an INV with
>> support for two packages P and R.  You do not show what the target UA
>> supports -- did it support both packages, or did the target UA send a
>> 200 OK with an additional package, T?  You then go on to show an ACK
>> going from the initiating UA with package R and T.  This implies that
>> there is an offer/counter-offer/answer type of negotiation, which is
>> not what you had outlined in the beginning of Section 3.1.  Can the
>> target UA add a package that was not present in the Recv-Info header
>> of the initiating UA?  This is very important to clarify if we want  
>> to
>> get the negotiation right.

NO NEGOTIATION ;-)

>> 10) S3.1, page 9, the paragraph "In the case of ... specified by this
>> document." is a very important one and needs to be highlighted more.
>> Essentially, if I read the paragraph correctly, the validity of an
>> INFO message is bounded by either of the following two conditions:
>>  (i) The dialog is terminated normally; or
>>  (ii) A peer receives a dialog refresh request, but that request
>>     did not have a Recv-Info header in it.
>> Case (i) can be characterized as the normal behavior, after all, if a
>> dialog goes away, it makes sense that any state associated with it
>> vanishes as well.  Case (ii), however, is rather important if the
>> intent of the draft is indeed to terminate Info package state if it  
>> is
>> not refreshed by a dialog refresh request.
>> Case (ii) implies that Info packages have a lifetime that may be less
>> than that of the dialog in which they are contained.  If that is
>> indeed the case, then a mid-dialog refresh request appears to be a
>> means to terminate an Info package state before the dialog itself is
>> terminated.  This would normally be okay, but brings to the fore
>> another important question: what if a dialog usage does not have a
>> mid-dialog request but the services of an Info package are no longer
>> needed for the duration of the lifetime of the dialog.  In such
>> a case, should we come up with a specific Info-Expires header?
>
> This termination mid-dialog is important to ensure that 3pcc  
> scenarios can work.
>
> I don't understand your question here. If you want an info usage to  
> go away mid-dialog, why not use a dialog refresh to cause that? This  
> would be entirely analogous to termination of a session-timer mid- 
> session.

Agree w/ Paul. Old stuff stayed.

>> To make matters worse, while S3.1 appears to state that the Info
>> packages may have a lifetime less than that of the dialog they are
>> contained in, S4.1, fourth paragraph, appears to contradict this
>> assertion.  In S4.1, fourth paragraph, it is stated that "The INFO
>> method has no lifetime or usage of its own ..."
>
>> So, some more thoughts on the lifetime of an Info package seem
>> appropriate and they should be spelled out in detail in this section.
>> Personally, I think that it should be okay to simply bound the
>> lifetime of an Info package with that of the dialog and leave it at
>> that.  Exhorting implementers to expire an Info package if the dialog
>> refresh did not include a Recv-Info header seems to be calling for
>> more complexity than needed.  Are there existing usages of Info that
>> require such behavior?
>
> Any time you do a 3pcc transfer, one side things their dialog is  
> preserved, while on the other side there have been two distinct  
> dialogs. If the first of those supported the info pkg, but the 2nd  
> does not, then you need a way to renegotiate.

Precisely.

>> 11) S3.2, second paragraph: The second reason for why versioning is
>> not supported needs to be made a bit more clear.  I would suggest the
>> following replacement text (edit as needed):
>>  A second reason for not supporting a package versioning system
>>  is that not all payloads are capable of encoding a version
>>  number.  In the end, while it is easy for user agents to
>>  negotiate Info package support, asking them to also negotiate
>>  specific package versions closely ties the signaling to a
>>  specific payload version.  Since the payload is to be
>>  interpreted by a transaction user, such coupling may not be
>>  beneficial as a general rule.

No one was suggesting this.  See the updated text.

>> 12) S4.1, page 10, last paragraph: I am curious -- why are we  
>> allowing
>> early INFO requests?  More so since when they interact with
>> forking, they seem to produce undesirable complexity.
>
> Well, since the poster child has always been DTMF, that is something  
> that is frequently desired in early dialogs.

Precisely.

>> RFC2976 does not mention INFO forking in the context of a initiating
>> UA receiving multiple INFO messages, which is what is being discussed
>> here.  RFC2976 does talk about the INFO request forking, but this is
>> in the context of a forking proxy sending out multiple INFO requests.
>> As such, if we intend to allow the first behavior, i.e., an  
>> initiating
>> UA receiving multiple INFO requests as result of a forked INVITE,  
>> then
>> we'd better say a lot more than this one paragraph on the resulting
>> complexity (this small paragraph is the only place in the document
>> where early INFO is mentioned.)  The behavior in this section for  
>> such
>> a case is inadequately specified: should the initiating UA expect  
>> INFO
>> requests before the provisionals or after the provisionals, or does  
>> it
>> not matter?  What if PRACK is used?  Should the target UA wait for a
>> PRACK before it sends an INFO?  And so on.
>> IMHO, since we are defining new behavior for INFO, why take on
>> additional complexity in the form of burdening the initiating UA with
>> receiving multiple INFO requests?  Is there a proposed Info package
>> that requires such behavior?  Or conversely, is there a legacy Info
>> usage whose behavior we want to preserve by this complexity?  If the
>> answer is no, then I really think we should simply mandate that the
>> INFO request is to be sent once the dialog has been established.
>
> Once again I think DTMF gives an example.
> You might need to send it during early dialog, and in conjunction  
> with forking you then may be exchanging them on multiple early  
> dialogs.

Clarified.

>> 13) S4.2, second paragraph: I don't understand this -- why is it left
>> to the UAC to determine whether it is "appropriate to send that
>> payload to the UAS"?  Should this not be the task of the Info package
>> designer?  In other words, all we need to say here is "If the Info
>> package defines a payload, the UAC MUST include the payload and the
>> MIME type described in the Info package."

Clarified.

>> 14) S4.2, third paragraph: The sentence here is self-evident; I am  
>> not
>> sure why list this behavior out explicitly.

Doesn't hurt? There was a lot of list discussion on this point, so I  
figured I would head it popping up again.

>> 15) S4.2, fourth paragraph: what do you mean by "INFO proper"?  I
>> presume you either mean RFC2976, or the ad-hoc use of INFO in the
>> Internet.  If so, please restate as such.  If not, please amplify the
>> meaning of "INFO proper".

Done.

>> 16) S4.7, first paragraph, it is stated that the "UAS cannot use the
>> CSeq to determine the sequence of INFO messages."  I am not sure I
>> understand why.  Is it not the case that the CSeq number of later
>> requests will be higher than the one of previous requests?  Sure,
>> there will be gaps, but later requests will have a CSeq number bigger
>> than previous ones.
>> Same section, second paragraph, it is stated that "Since overlapping
>> requests will occur even if the application (Info package) does not
>> allow it..." -- I don't understand why overlapping would occur if
>> the Info package did not allow it?  Is it because of some legacy INFO
>> usage that behaves in this way?  If so, simply state that as the
>> reason, and if not, you may want to add text that supports why a
>> developer should be prepared to handle overlapped requests if the  
>> Info
>> package prohibits these.

Clarified.

>> 17) S6, last paragraph: should we not do more than "hope" that  
>> vendors
>> who implement proprietary Info usages submit their mechanisms as Info
>> package extension documents?  That is, shouldn't we "require" them to
>> do ss at least using a SHOULD strength?

Because vendor behavior is not a protocol and there is no way to  
measure it. Absolutely not a RFC 2119 thing.

>> 18) S7.1 - S7.11: In certain sub-sections, the text says "This
>> section, [...], MUST be present..."  Why the singling out of certain
>> sections in this manner?  Shouldn't it be the case that ALL sections
>> MUST be present in an Info package extension document?  If they are
>> not relevant to that specific package, the package designer can  
>> simply
>> state "N/A".  As these sections are now written, if I was an Info
>> package designer, I would automatically assume that some sections,
>> especially those ones where it does not say that they MUST be  
>> present,
>> can be omitted when documenting my Info package.
>> I don't think that is the intent here, is it?

It actually is the intent: if there is nothing to say, say nothing.   
Do we want Info Packages to be the first protocol to try this  
experiment?

>> 19) S7.6 and S7.7: I think the meat of these two sub-sections deals  
>> with
>> overlapped INFO requests, and as such, a new sub-section on this  
>> topic
>> should be added if overlapped requests are to be allowed.  The UAC
>> generation of INFO requests takes only a paragraph and can be moved  
>> to
>> its own sub-section.  Likewise for UAS processing of INFO requests.

The UAS/UAC reorganization should make this clearer.

>> 20) S7.10, discussion in the middle of the section: The reason for  
>> not
>> mandating TLS is not because there are "few protocol mechanisms to
>> enforce this" -- indeed, there are few protocol mechanisms to enforce
>> any arbitrary behavior, which is why policing network traffic is so
>> lucrative a business model.  The main reason why TLS is not  
>> sufficient
>> is because of its hop-by-hop nature, intermediaries will be privy to
>> any INFO package contents.  Now, there really isn't a way around this
>> in SIP unless you do an end-to-end certificate exchange to bootstrap
>> TLS.  S/MIME, which is given as an option in the draft, is academic
>> since I do not believe that many SIP implementations, if any, support
>> it at all.
>> I am not sure what to say here except that the text needs to be
>> cleaned up a bit to inform Info package designers that while TLS is
>> better than nothing, it will still leak Info package bodies to
>> intermediaries (i.e., remove the "few protocol mechanisms to enforce
>> this" sentence.)  Those Info implementations that want to protect
>> their payload should use S/MIME or some other means to prevent
>> intermediary eavesdropping.

Clarified.

>> 21) S8, in the Info-package-type production rule, why is the dot  
>> (".")
>> used to separate parameters when everywhere else in SIP the
>> semi-colon (";") plays the same role?

Because I made a mistake that I fixed in the current draft.

>> 22) S10: S7.11 asks Info package designers to provide
>> complete and syntactically correct SIP messages as examples.
>> Ironically, this very issue is violated by your examples :-)
>> It would be good to provide complete messages, if possible.

Sigh. I did now. I hope they are correct!

>> 23) S10.1: The example in this section can also result in a situation
>> where package "bar" never gets triggered even though Bob may indeed
>> support it.  Here's how, and please let me know if I am
>> misunderstanding something here: Let's say Bob supported both "foo"
>> and "bar".  According to your text in S10.1, while Alice supports
>> sending "bar", she can send AND receive "foo"; so she only puts "foo"
>> in the Recv-Info header.
>> Now, when the Recv-Info header reaches Bob, all Bob knows is that
>> Alice supports receiving "foo".  Bob can receive "bar", but does not
>> know that Alice can indeed send "bar".  So, "bar" as an Info package
>> has inadvertently been cut out.  This is not good, right (if I am
>> missing something critical here, please do let me know.)
>> If the above is indeed true, then we may have a bigger problem on our
>> hands. The example in this section got me thinking about the
>> distinction between Recv-Info containing package names that can be
>> sent and received versus packages that can only be sent (and
>> therefore, not received?)  The text in S10.1 states that "Alice can
>> support sending or receiving "foo" Info packages, and sending "bar"
>> Info Packages."  Does that mean that Alice cannot receive "bar"
>> package?  Only send it?
>> Is there a distinction between Recv-Info containing package names  
>> that
>> a UAC can "send", "receive" or "send and receive"?  S1 starts to  
>> tease
>> this on page 6 when it states that "Each UA enumerates which Info
>> Packages it can receive." but it does not finish the discussion; much
>> is left unsaid.  Does that mean that when a UAC includes an Info
>> package name in Recv-Info, it can only receive that type of package
>> but cannot send it?  In fact, how can a UAC indicate support for Info
>> packages that it can send?  It looks like a UAC cannot use the
>> "Supported" header for this (c.f., S3.1).  Similarly, how does a UAC
>> include support for Info packages it can send and receive?
>> Clearly, if a UAC is capable of receiving an Info package, is it not
>> capable of sending it as well?  In other words, consider the  
>> following
>> exchange -- a UAC sends:
>>  INVITE ...
>>  Recv-Info: A, B
>> to which a UAS replies:
>>  200 OK ...
>>  Recv-Info: B
>> And the UAC now sends an INFO request with Info package B.  So,
>> "receive" seems to automatically imply "send", and thereby "send and
>> receive" as well.  Am I correct or am I just plain missing something
>> here?  To me at least, this is a rather important distinction that
>> ought to be spelled out.  Right now I am not sure whether Recv-Info
>> implies both receive and send -- I think it does, but portions of the
>> draft lead me to believe otherwise.

Total misunderstanding - the offending sentence that made it look like  
it was a negotiation was removed.

>> 24) S11: I think what you are trying to do here is to establish a  
>> Info
>> package registry in the same way that we established the tel URI
>> parameter registry (RFC5341) and the sip URI parameter registry
>> (RFC3969), correct?  If so, I agree with the note that this section
>> may be a separate document altogether since the mechanics of  
>> assigning
>> an expert review, etc. are described in such registry documents (you
>> can use RFC5341 and RFC3969 as templates.)

This was language mandated by Keith. Given the reorganization of SIP/ 
SIPPING, I would offer the section goes away. However, that decision  
is above my pay grade to decide.

>> Nits and editorials (11 comments)
>> ---------------------------------
>> 1) Abstract, first sentence: Instead of saying, "This document
>> defines a new SIP INFO method", probably better to say that
>> "This document provides new semantics to the INFO method of
>> RFC2976, obsoleting the old usage in a backwards-compatible
>> manner."
>> My reason for this comment is that this document is not defining
>> a new method called INFO as much as it is trying to provide a
>> new context and semantics for the use of an existing method called
>> INFO.

Done

>> 2) Abstract, paragraph three:
>> s/Be mindful/The reader is urged to be mindful/

What is wrong with the imperative case?

>> 3) S1, page 6, last paragraph:
>> s/Conversely, this can be/Conversely, this can also be/

I could also be duplicately redundant :-)

>> 4) S3, opening paragraph:
>> s/To be abundantly clear, as stated/As stated

OK

>> 5) S3.1, page 8, towards the end of the page:
>> s/send form package/send package/

done

>> 6) S3.1, page 9:
>> s/UA in the dial will/UA in the dialog will/

oops

>> 7) S3.1, last paragraph: consider replacing "far-end" with something
>> else -- something as such:
>> OLD
>> If the far-end UA does not indicate support for an Info package that
>> the local server requires, the server MAY terminate the session with
>> a CANCEL or BYE request.
>> NEW
>> If the UA receiving the INFO request did not indicate support
>> for a required Info package, the sender of the INFO MAY
>> terminate the session with a CANCEL or a BYE request.

OK

>> 8) S4.3, page 13, the indented "NOTE" paragraph at the top of the
>> page: I think you can remove this paragraph -- you are mandating that
>> a 489 be sent when the UAS receives an INFO message with a package it
>> does not understand.  That should be it; I think pointing out the  
>> link
>> between INFO and NOTIFY serves only to confuse the issue.  As a
>> developer, I want to know what to send when I get a request I cannot
>> handle.  As long as the good RFC tells me to send a 489, so be it.

Corrected with the move to 469.

>> 9) S4.3, page 13, second paragraph:
>> s/but it has no/but the INFO request has no/
>> s/as it sees fit//       (i.e., remove "as it sees fit")

OK

>> 10) S8, first paragraph:
>> s/user-to-user data exchange in SIP./INFO method./
>> Same section, second paragraph is redundant and can be easily removed
>> without impacting readability or understanding.

done

>> 11) S12, first paragraph:
>> s/improve the security of the Internet./improve the security of
>> SIP-based communications./

Sigh. done.