Subject: RE: [Sipping] Re: I-D ACTION:draft-elwell-sipping-update-pai-00.t xt

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 Oct 2006 15:38:23 +0100

Paul,

Thanks for your further remarks. See in-line again.

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 18 October 2006 18:54
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] Re: I-D 
> ACTION:draft-elwell-sipping-update-pai-00.t xt
> 
> 
> 
> Elwell, John wrote:
> > Paul,
> > 
> > No particular reason, except that I don't have any use 
> cases for any of the
> > other methods that are not already allowed, and I would 
> certainly have a
> > hard time justifying it in REGISTER or CANCEL, or even ACK 
> or PRACK. We
> > would need to say what it means to put it there.
> 
> All it means is that somebody has knowledge allowing them to 
> assert the 
> identity of the sender of the message. It doesn't *require* it to be 
> inserted. Is some common cases it wouldn't be included in REGISTER 
> because nobody knows enough to do so. I see no problem with 
> including it 
> in CANCEL.
[JRE]Generally we don't include stuff just because it is easy to do - we
tend to require use cases. In this case I agree it does no harm, but I
wouldn't want to put it in and find I get comments asking for the
motivation. Anyone else got an opinion?

> 
> For instance, the identity coexistence stuff could result in this.
> 
> > When you say any message, presumably you mean any request.
> 
> No, I meant to include responses. They are already permitted. 
> And P-A-ID 
> is already used in responses in IMS.
[JRE] It must be a couple of years ago when I raised the question of PAI in
a response (the RFC is ambiguous, because sometimes it talks about messages
rather than requests, and in other places just about requests). At the time
I received opinions that it was not intended for responses, based on a
belief that you can't authenticate a response and therefore you can't assert
an identity. However, there may be circumstances where you can assert an
identity (e.g., if received from a UA over a TLS connection over which the
UA has already been authenticated).

The other point is that for authenticated connected identity you need to use
a request in the reverse direction, not a response. There does not seem a
lot of point in promoting PAI in a response if authenticated connected
identity requires a request in the opposite direction. If we do work on
co-existence, we would want the two identities to be in the same message,
not different messages.

> 
> 	Paul
> 
> > John
> > 
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[email-masked]] 
> >> Sent: 17 October 2006 14:15
> >> To: sipping
> >> Subject: [Sipping] Re: I-D 
> >> ACTION:draft-elwell-sipping-update-pai-00.txt
> >>
> >> John,
> >>
> >> Since you are forced to go though the trouble of updating 
> >> 3325, why not 
> >> do a more thorough job - allow PAI in any message - and so 
> >> prevent the 
> >> need for another update in the future?
> >>
> >> Is there any reason *not* to allow it in all messages?
> >>
> >> 	Paul
> >>
> >> [email-masked] wrote:
> >>> A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> >>> directories.
> >>>
> >>>
> >>> 	Title		: The use of Asserted Identity in the 
> >> Session Initiation Protocol (SIP) UPDATE method
> >>> 	Author(s)	: J. Elwell
> >>> 	Filename	: draft-elwell-sipping-update-pai-00.txt
> >>> 	Pages		: 6
> >>> 	Date		: 2006-10-16
> >>> 	
> >>>    SIP has a mechanism for conveying the asserted identity of the
> >>>    originator of a request by means of the 
> >> P-Asserted-Identity header
> >>>    field.  This header field is specified for use in 
> >> requests using a
> >>>    number of SIP methods, in particular the INVITE method.  
> >> However, it
> >>>    is not specified for use in requests using the SIP 
> UPDATE method.
> >>>    This document extends RFC 3325 by allowing use of the 
> P-Asserted-
> >>>    Identity header field in UPDATE requests.
> >>>
> >>>    This work is being discussed on the [email-masked] 
> >> mailing list.
> >>>
> >>>
> >>> A URL for this Internet-Draft is:
> >>>
> >> http://www.ietf.org/internet-drafts/draft-elwell-sipping-updat
> > e-pai-00.txt
> >>> To remove yourself from the I-D Announcement list, send a 
> >> message to 
> >>> [email-masked] with the word unsubscribe in 
> >> the body of 
> >>> the message. 
> >>> You can also visit 
> >> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> >>> to change your subscription settings.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP. 
> Login with the 
> >>> username "anonymous" and a password of your e-mail address. After 
> >>> logging in, type "cd internet-drafts" and then 
> >>> "get draft-elwell-sipping-update-pai-00.txt".
> >>>
> >>> A list of Internet-Drafts directories can be found in
> >>> http://www.ietf.org/shadow.html 
> >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> >>> Internet-Drafts can also be obtained by e-mail.
> >>>
> >>> Send a message to:
> >>> 	[email-masked].
> >>> In the body type:
> >>> 	"FILE /internet-drafts/draft-elwell-sipping-update-pai-00.txt".
> >>> 	
> >>> NOTE:	The mail server at ietf.org can return the document in
> >>> 	MIME-encoded form by using the "mpack" utility.  To use this
> >>> 	feature, insert the command "ENCODING mime" before the "FILE"
> >>> 	command.  To decode the response(s), you will need "munpack" or
> >>> 	a MIME-compliant mail reader.  Different MIME-compliant 
> >> mail readers
> >>> 	exhibit different behavior, especially when dealing with
> >>> 	"multipart" MIME messages (i.e. documents which have been split
> >>> 	up into multiple messages), so check your local documentation on
> >>> 	how to manipulate these messages.
> >>>
> >>> Below is the data which will enable a MIME compliant mail reader
> >>> implementation to automatically retrieve the ASCII version of the
> >>> Internet-Draft.
> >>>
> >>>
> >>>
> >> --------------------------------------------------------------
> >> ----------
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP
> >> Use [email-masked] for questions on current sip
> >> Use [email-masked] for new developments of core SIP
> >>
> > 
> 

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