[Sip] Re: Comments on draft-ietf-sip-acr-code-02

Drage, Keith (Keith) wrote:

> I have reviewed the entire draft.
> 
> 1)	In section 3, I wondered if it would be appropriate to have a
> couple more key statements of when it does not apply. 
> 
> For example, if we are using RFC 4474, and the recipient of the SIP
> request has received the identity but has been unable to obtain the
> certificate for the identity, then the proposed 433 response code is
> inappropriate, and indeed RFC 4474 specifies response codes for this
> situation, which should always be used in preference.

OK. I added this:

<t>
In addition, requests where the identity of the requestor cannot be 
determined
or validated, but it is not a consequence of an explicit action on the
part of the requestor, are not consider anonymous. For example, if a
request contains a non-anonymous From header field, along with the
Identity and Identity-Info header fields <xref target="RFC4474"/>, but
the certificate could not be obtained from the reference in the
Identity-Info header field, it is not considered an anonymous request,
and the 433 response code SHOULD NOT be used.
</t>

> 
> 2)	Section 3. 
> 
>    o  The request contained a Privacy header field whose value was 'id'
>       [3] or 'user'.  This explicitly excludes the 'header' and
>       'session' privacy services, since those do not directly convey the
>       identity of the requestor.
> 
> I have noted the ongoing discussion on this, and certainly my
> interpretation was that the "header" value in the Privacy header could
> cover the P-Asserted-Identity header. However I think we should avoid
> that this draft attempts to fix unclear specification in RFC 3323 and
> (and possibly RFC 3325). I would therefore suggest that we strike the
> offending words.

Fine. In the interests of forward progress I will strike the offending 
sentence.

> 
> 3)	Section 4.
> 
> This section seems to be the one that should talk about dialog usage.
> While identities are usefully provided in the initial transaction in a
> dialog, there is nothing that prevents them being exchanged in later
> transactions, and indeed for the support of some services it is
> necessary, as the identity will have changed. 
> 
> The document should indicate the effect of receiving a 433 response to a
> request sent within an existing dialog, where the implementation does
> support this extension, which I assume should be the defauly 4xx
> response treatment.

I've added the following:

<t>
Receipt of a 433 response to a mid-dialog request SHOULD NOT cause the
dialog to terminate, and SHOULD NOT cause the specific usage of that
dialog to terminate <xref target="I-D.ietf-sipping-dialogusage"/>.
</t>

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip