My responses to Paul: > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 10 November 2008 04:10 > To: Elwell, John > Cc: Eric Burger; SIP IETF > Subject: Re: [Sip] Comments on sip-info-events-01 > > Some followups to John's comments. I've trimmed down to > relevant stuff. > > Thanks, > Paul > > Elwell, John wrote: > > > - I think I suggested once before that we should not treat > > Send-Info/Recv-Info exchanges like offer/answer, but should > just have a > > simple rule that says that a UA can send these header > fields at any time > > and they supersede any sent previously. A UA MUST not send > INFO unless > > the package has been identified in the last Send-Info sent > and the last > > Recv-Info received. A UA MUST (SHOULD?) discard a received > INFO unless > > the package has been identified in the last Recv-Info sent, > and MUST be > > prepared to receive an INFO for a package as soon as it has sent a > > Recv-Info identifying that package. These header fields MAY > be included > > in an INVITE request, in a dialog-forming response to an > INVITE request, > > or in any other request or response in the context of an > early or full > > INVITE-initiated dialog. This would be a lot simpler. Is there any > > reason it would not work? I am not certain I have enumerated all the > > rules here, but I doubt if very much more would need to be said > > normatively. > > I think this will work as long as he contents of these headers on one > side are not coupled with those on the other side. IOW, I > should be able > to mention a package in Recv-Info even if it wasn't mentioned by the > other side, and visa versa. [JRE] I agree that this would be a consequence, and yet a further simplification.
> > But can somebody remind me why we need Send-Info at all? > > However in any case we must accept that there is a race > condition, when > an INFO is in flight at the same time as a Recv-Info in the other > direction that forbids sending it. I think that is fine - it > will just > be rejected, and that should not be considered a serious error. > > > "If the UAS receives an INFO request with a Info-Package the UAC > > advertised with a Send-Info in the last dialog state update" > > It was not clear to me that every dialog state update MUST contain > > Send-Info/Recv-Info. In other words, if I send an UPDATE > request without > > these header fields, e.g., for session timer refresh, does > this cancel > > any previous negotiation of Info Packages? I would prefer > that it did > > not, that it simply left things unchanged. > > We need to be careful here, to prevent breaking 3pcc. If a > transfer is > done via 3pcc, how can we ensure that the desires of the > unchanged party > are made known to the transfer target? This could be ensured that the > Send-Info/Recv-Info headers are always sent when an offer or > answer is sent. [JRE] I don't object to mandating it, if this is what it takes to make it work in a 3PCC environment. Is it clear to everyone what "dialog state update" means? > > > - "If a server receives an INFO request with a body it > understands, but > > it has no Info-Package header, the UAS MAY render the body." > > This is the first mention of "render". In fact there is > nothing to say > > that a UAS must/should/may render a body when an INFO > request is not in > > error, so it seems odd to talk about rendering when there > is an apparent > > error in the INFO request. Is "rendering" necessarily the > appropriate > > thing to do with a received and valid INFO request. Should > we instead > > say "...the UAS MAY make use of the body"? > > Yeah, "render" could be quite confusing. Perhaps "process"? > > > - "The UAS MUST send a 481 Call Leg/Transaction Does Not > Exist message > > if the INFO request does not match any existing dialog." > > Shouldn't this say "...does not match any INVITE-initiated dialog"? > > INVITE-dialog-usage? [JRE] Yes, that would be better. > > (I could have a dialog that was initiated with an INVITE, then > piggybacked with a SUBSCRIBE, then BYE to the INVITE, but > subscription > remains. That is still an INVITE-initiated dialog, but INFO > isn't valid.) > > > - "The INFO message MUST NOT change the state of the SIP > dialog. The > > only exception to this rule is for specific failure responses as > > documented in RFC 5057 [RFC5057], which may cause the > INVITE dialog > > to terminate." > > This jogs another question in my mind. Is it permissible to pass > Send-Info / Recv-Info headers in an INFO? If so, then IMO > those change > the state of the dialog. > > > - "A UAC, the sender of the OPTIONS request, MAY include > Send-Info and > > Recv-Info headers, populated appropriately for the > packages the UAC > > supports. The UAS MAY include its set of Send-Info and Recv-Info > > packages. The UAS and UAC MUST NOT consider the OPTIONS > request to > > be part of a capabilities negotiation. The OPTIONS > request is purely > > a probe." > > The semantics of these header fields in an INVITE request or another > > message in an INVITE-initiated dialog means I am prepared to > > send/receive these packages in the context of this dialog. > However, for > > OPTIONS there is no dialog. So what exactly are the > semantics of these > > header fields in OPTIONS request? Presumably it just means I support > > these packages and may be prepared to send/receive them in > the context > > of an INVITE-initiated dialog. This should be clarified. > > I agree. (I have similar problems with everything in an OPTIONS.) > > > - In 5.1, Why is Contact allowed in an INFO request but not in a 2xx > > response to INFO? Since INFO is not allowed to change > dialog state, it > > cannot change target URIs, so what would be the meaning of > Contact in an > > INFO request. I think we should align with BYE and not > allow Contact in > > INFO. > > Agree. > > > - "For the purposes of matching Info Package types > indicated in Send- > > Info or Recv-Info with those in the Info-Package header > field value, > > one compares the Info-package-name portion of the > Info-package-type > > portion of the "Info-Package" header byte-by-byte with > that of the > > same in the "Send-Info" or "Recv-Info" header values." > > Presumably comparison is case-sensitive. Should we state this? > > By default I would assume case-insensitive behavior. That is the norm > for most things. Is there a reason to be case sensitive here? [JRE] I am happy for it to be case-insensitive, but the most likely interpretation of the existing words is case-sensitive. John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
