Re: [sipcore] Proposed rewrite of parts of rfc4424bis

[Mary Barnes <[e-mail]>]

Hi folks,

I've seen no responses to John's suggestion. If folks could please read and
provide feedback as to whether they support this change, we should be able
to get final updates done for 4244bis and get it ready for another WGLC.

Thanks,
Mary.

On Wed, Feb 23, 2011 at 2:30 PM, Elwell, John <
[e-mail]> wrote:

> Based on responses from Mary to my recent questions, I am convinced that
> procedures could be documented in a much simpler way. Basically I think we
> can have common procedures for the different entities (UAC, UAS, Proxy,
> Redirect) - how you behave on receipt of a request, forwarding a request,
> receipt of a response or forwarding a response is pretty much independent of
> the type of entity. In recent emails I developed a model of what I believe
> we want to happen. I have tried to capture this model in text in a new
> section X, which should occur between sections 8 and 9. Sections 6, 7 and 8
> essentially just reference section X. I would like WG opinion as to whether
> this is easier to understand, as well as opinions as to whether it
> accurately reflects the intent of the current I-D.
>
> <text>
> 6. User Agent Handling of the History-Info Header Field
> A B2BUA MAY adopt the behavior of a proxy (section 7) as an alternative to
> adopting the behaviour of a UAS (section 6.2) and the behaviour of a UAC
> (section 6.1). In behaving as a proxy, a B2BUA will carry forward hi-entries
> received in requests at the UAS to requests forwarded by the UAC and will
> carry forward hi-entries received in responses at the UAC to responses
> forwarded by the UAS, subject to privacy considerations.
>
> 6.1 User Agent Client (UAC) Behavior
> When issuing a request, a UAC MUST behave in accordance with X.2 for
> sending a request. Note that the cache of previous requests will be empty
> and the index of the hi-entry added to the sent request will be 1, except
> where the UAC issues a retargeted request as a result of a received
> response. When receiving a response, a UAC MUST behave in accordance with
> X.3. In addition, if a UAC would like to receive the History-Info header
> field in responses, it MUST include in the sent request a Supported header
> field containing option tag histinfo.
>
> 6.2 User Agent Server (UAS) Behaviour.
> When receiving a request, a UAS MUST behave in accordance with X.1. When
> sending a response other than a 3xx response, a UAS MUST behave in
> accordance with X.4. When sending a 3xx response, the UAS MUST behave as a
> redirect server in accordance with section 8. An application at the UAS can
> make use of the cached hi-entries, taking into account the considerations of
> section 10.
>
> 7. Proxy /Intermediary Handling of the History-Info Header Field
> The following behaviour is applicable to a proxy or a B2BUA that behaves as
> a proxy (see section 6).
> A proxy / intermediary MUST behave:
> - in accordance with X.1 when receiving a request;
> - in accordance with X.2 when sending (forwarding) a request;
> - in accordance with X.3 when receiving a response;
> - in accordance with X.4 when sending a response.
> Sometimes the internal design of a proxy or B2BUA will result in a request
> being retargeted twice before the request is forwarded, i.e., it is "sent"
> to an internal target, which is resolved by that same entity internally by
> retargeting to an external target. A proxy or B2BUA in this case MAY behave
> as if the request had actually been sent to the internal target before
> sending to the external target, thereby generating an hi-entry for that
> internal target, in addition to the hi-entry for the external target. Both
> hi-entries would then be seen "on the wire" in the resulting request sent
> downstream and any response sent upstream, subject to privacy
> considerations.
>
> 8. Redirect Server Handling of the History-Info Header Field
> When receiving a request, a Redirect Server MUST behave in accordance with
> X.1. When sending a response, a Redirect Server MUST behave in accordance
> with X.4 and MUST add an "rc" or "mp" header field parameter to the Contact
> header field if either of these parameters is applicable according to 9.4.
>
> X. Common Handling of the History-Info Header Field
> X.1 Receiving a Request
> When receiving a request, an entity MUST create a cache of hi-entries
> associated with that request and include in that cache any hi-entries in the
> received request.
>
> If the Request-URI of the received request does not match the URI in the
> last hi-entry in the cache, the entity MUST add to the end of the cache an
> hi-entry containing that URI as the hi-targeted-to-uri. For the added
> hi-entry, the entity MUST behave in accordance with 9.1 if privacy is
> required, MUST populate the hi-index in accordance with 9.3, and MUST NOT
> include an "rc" or "mp" header field parameter.
>
> X.2 Sending a Request
> When sending a request, and entity MUST include all cached hi-entries in
> the request. In addition, the entity MUST include in the request an
> additional hi-entry containing the Request-URI as the hi-targeted-to-uri but
> MUST NOT cache this hi-entry. For the new hi-entry, the entity MUST behave
> in accordance with 9.1 if privacy is required, MUST populate the hi-index in
> accordance with 9.3, and, if applicable, MUST include in the new hi-entry an
> "rc" or "mp" parameter in accordance with 9.4. If the sent request is a
> direct result of retargeting to a contact URI received in a 3xx response and
> the Contact header field in that response contained an "rc" or "mp" header
> field parameter, the entity MUST include the corresponding parameter in the
> new hi-entry in accordance with 9.4.
>
> X.3 Receiving a response
> When receiving a response other than 100, an entity MUST add to the cache
> the new hi-entry that was added to the sent request that led to that
> response (if not already in the cache) and include in that cached hi-entry
> (whether or not it was already cached) a Reason header field in accordance
> with 9.2 denoting the SIP response code in the response. The entity MUST
> also add to the cache any hi-entries in the response that are not already in
> the cache (i.e., any hi-entries added by downstream entities). When adding
> hi-entries to the cache, the entity MUST maintain hi-entries in ascending
> order of index (e.g., 1.2.1 comes after 1.2 but before 1.3). Note that the
> cache will not contain hi-entries for requests that have not attracted a
> non-100 response, so there can be gaps in the indices (e.g., 1.2 and 1.4
> could be present but 1.3 absent).
>
> X.4 Procedures for sending a response
> When sending a response other than 100, an entity MUST include in the
> response all cached hi-entries, with the exception that when the received
> request contained no hi-entries and no histinfo option tag in the Supported
> header field, the entity MUST NOT include any hi-entries in the response.
> </text>
>
> I think I have covered most of what was in sections 6, 7 and 8, but I have
> left out some explanatory material giving reasons (the simplified
> procedures, in my opinion, don't require so much explanation, or if really
> needed it can be done in section 5).
>
> The original word count of 1719 is reduced to 956, a significant reduction
> arising mainly from avoidance of any duplication and also the loss of some
> explanation. However, in my opinion behaviour is specified in a more logical
> way, and in a way that makes it a lot more likely that people will implement
> this. The question is whether the WG feels this is a worthwhile change at
> this late stage.
>
> I have not checked section 9 in detail to see whether any slight changes
> are required to align with this new text.
>
> John
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>