Eric,
Some comments:
- "and negotiate
packages from the UAS' subsequent responses and the ACK"
The UAS doesn't send ACK.
- "Once a UAC advertises it is willing to receive a package, it MUST be
ready to receive INFO methods carrying that package type. This is
because the UAS MAY send such INFO requests at the same time as the
UAS sends its confirming Send-Info header, and the request may arrive
out of order. This also enables early exchange of INFO methods."
This does not recognise the fact that the UAS may advertise first (in a
response), in which case the UAS is subject to a similar rule. This
paragraph should be made direction-agnostic.
- " Similar rules apply for late Send-Info / Recv-Info negotiation,
such
as an empty INVITE, followed by an offer in the 200 OK and the
response in the ACK."
I think this is too vague for a normative section. In fact, as it is,
this statement is not normative, but there should be normative
statements regarding receiving in 1xx/2xx (not having sent in INVITE
request) and sending in ACK request.
- 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.
Another advantage of this would be that there would be no need to use
the special terminology in section 3 whereby UAC is specifically the UAC
for the INVITE request and the UAS is the UAS for the INVITE request.
This gets particularly confusing when considering a re-INVITE or UPDATE
request initiated by the UA that was the UAS for the original INVITE
request. Furthermore, in section 4 terminology reverts to the more
orthodox meanings of UAC and UAS. So even if we don't adopt my
suggestion above for getting rid of pair-wise exchanges of
Send-Info/Recv-Info, I think something should be done to avoid the
unorthodox terminology in section 3.
- "If the payload of the INFO method has multiple body parts, the UAC
SHOULD identify which body part belongs to a given Info Package. The
UAC does this by adding the modifier ";cid=<identifier>" to the Info-
Package header field value, where "<identifier>" is the Content-ID
MIME header value corresponding to the body part associated with the
Info-Package. The sole exception to this rule is if the particular
Info Package carries no payload. In this case there will be no body
part associated with the Info Package and thus there will be no
Content-ID to reference. In this case, the UAC MUST NOT include the
"cid" modifier."
Why not simply say:
"If the payload of the INFO method has multiple body parts, the UAC
MUST identify which body part (if any) belongs to a given Info
Package. The
UAC does this by adding the modifier ";cid=<identifier>" to the Info-
Package header field value, where "<identifier>" is the Content-ID
MIME header value corresponding to the body part associated with the
Info-Package. Some Info Packages may not involve the conveyance of a
body part."?
This would avoid using SHOULD - it is always preferable to use a
conditioned MUST.
- "1. Recall the response code to an INFO method request relates to the
INFO method request itself, "
Nothing has been stated previously about response codes to INFO
requests, so it is difficult to recall this! Delete "Recall".
"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.
- "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"?
- "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"?
- "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."
It is odd to say "MUST NOT" and then state that there is an exception.
Should it be a "SHOULD NOT"?
- "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.
- "The UAS MAY include its set of Send-Info and Recv-Info
packages."
Presumably this should say "... in a 2xx response to an OPTIONS
request".
- "For the UAC or UAS to renegotiate package support, they must use the
procedures described in Section 3."
Change "renegotiate" to "negotiate" (since OPTIONS does not negotiate).
- "That is, when the
UAC sends another INFO request before receiving a transaction
response from the UAS to a prior INFO request."
This is an incomplete sentence. Presumably it should say "... the
requests can arrive at the UAS out of order".
- 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.
- Why is Max-Breadth allowed in an INFO request, given that it cannot
fork?
- In 5.2, why are Send-Info and Recv-Info not allowed in UPDATE requests
and responses? In fact in 3.1 it says it is allowed.
- "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?
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
