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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 21 Sep 2006 11:55:59 +0200

In regard to 3)

See http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-03.txt

403 Forbidden: This response concerns the transaction, not the usage.
      It has no effect on any other usages of the dialog.  In our
      example scenario, the subscription remains, and is not affected in
      any way.  The invite usage continues to exist.  Similarly, if the
      403 came in response to a reINVITE, the invite usage would
      continue to exist. 

Which is pretty much what I would expect for the new 433 response code.

Regards

Keith

> -----Original Message-----
> From: Jesske, R [mailto:[email-masked]] 
> Sent: 21 September 2006 07:31
> To: Drage, Keith (Keith); [email-masked]
> Subject: AW: [Sip] Comments on draft-ietf-sip-acr-code-02
> 
> 1)agreed
> 2)agreed and the other points should be mentioned as examples 
> how anonymity is understand
> 3) What effect you expect?
> 
> BR
> 
> Roland
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Drage, Keith (Keith) [mailto:[email-masked]]
> > Gesendet: Montag, 18. September 2006 12:32
> > An: [email-masked]
> > Betreff: [Sip] Comments on draft-ietf-sip-acr-code-02
> > 
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > Regards
> > 
> > Keith
> > 
> > 
> > 
> > Keith Drage
> > Lucent Technologies
> > [email-masked]
> > tel: +44 1793 776249
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip