Re: Comments on Resource-Priority -07

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

Re: target dialog draft

Elwell, John wrote:
> Jonathan,
> 
> Section 3:
> "Typically this is the case when the dialog-initiating request would have
> otherwise been sent over an existing dialog, but was not since this
> specification allows the request to be sent on a new dialog instead."
> This is a bit convoluted. The reason for not using the existing dialog is
> that it would introduce problems with dialog reuse etc., as stated earlier
> in the document. The mere existence of this target dialog spec is not in
> itself sufficient reason for using a new dialog.

OK, I reworded.

> 
> In the next paragraph:
> Change "sent out a dialog" to "sent outside a dialog".

fixed.

> 
> Join and Replaces headers have "to-tag" and "from-tag" with corresponding
> text saying how these relate to the local tag and remote tag respectively at
> the recipient. Would it not be a good idea to stick to the same parameter
> names as Join and Replaces? Likewise the style of BNF is slightly different
> from that used in Join and Replaces. Would alignment be sensible? I don't
> have a strong opinion on these - just a suggestion.

I don't like using those names since they are misleading; whether those 
identifiers represent the values of a to or from tag depend on whether 
the user sends or receives a request. However, the local and remote tags 
are fixed, as they explicitly point to values stored locally in the UA.

You are correct though about the grammar style otherwise. I suspect it 
will confuse people, since the current grammar is more restrictive than 
Join; the parameter ordering is fixed. That is unusual for our 
parameters. So, I fixed this to look like the Join syntax.

> 
> What use do you envisage for this new header in an UPDATE request (for which
> it is marked optional in figure 4)?

Hmm. I think thats a bug. It only makes sense for dialog initiating 
requests, and that excludes UPDATE.

> 
> The title of figure 4 seems wrong.

Oops. Copy-paste error.

Thanks for your comments,
Jonathan R.

--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen <at> 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 <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Target-Dialog draft submitted - open issue around kpml, dialog package

Folks,

I've updated the target dialog draft based on discussions during IETF 
and some list comments, and submitted it. Until it appears, you can pick 
it up at:

http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-00.txt

Writing this up did pop out an open issue which we need to resolve. This 
issue might impact the dialog and kpml package drafts depending on how 
we go.

The issue is this. The target-dialog draft says to include this header 
field if you need a new request to be authorized by proving that you 
know about a specific dialog. We made this a header field so that it 
could work with REFER or SUBSCRIBE or even INVITE. With SUBSCRIBE, 
however, two of the potential event packages to use this (dialog and 
kpml), ALREADY have a means of proving that the subscriber knows the 
target dialog - through the Event header field parameters which each 
define. Thus, it would seem that including the event header field 
parameters and target-dialog header field is redundant.

I see three solutions:

1. Only include the target-dialog header field when there isn't already 
something in the message that proves you know the target dialog. The 
drawback here is that a UA seeking authorization of a request will need 
to potentially look in several places for proof of dialog awareness.

2. Include both of them. They have different semantics. The event header 
parameters are basically filters. The target-dialog header field is used 
to drive authorization. Thus, a single request will often have both 
containing the same dialog identifiers. One might imagine cases where 
they aren't the same; i.e. I subscribe using the dialog event package to 
dialog X, but authorization is based on my awareness of dialog Y.

3. Limit Target-DIalog to REFER, possibly INVITE.

(2) is more general but inefficient. (1) is more efficient, and more 
compatible with how kpml and the dialog event package work today. Going 
with approach (2) means that both documents might need to be updated; 
KPML at least probably would.

I'm inclined to go for (1), but there was ample arguments in favor of 
(1) and (2) that I wanted to bring it to the list. The target-dialog 
draft is currently written assuming solution (2), however. I'd need to 
update it if we go to (1).

I've also updated app-interaction to make usage of target dialog, but 
I'll wait to submit that until we've concluded this issue.

Thanks,
Jonathan R.

--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen <at> 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 <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

I-D ACTION:draft-ietf-sip-target-dialog-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-target-dialog-00.txt
	Pages		: 15
	Date		: 2005-4-4
	
This specification defines the Target-Dialog header field for the
   Session Initiation Protocol (SIP), and the corresponding option tag,
   tdialog.  This header field is used in requests that create SIP
   dialogs.  It indicates to the recipient that the sender is aware of
   an existing dialog with the recipient, either because the sender is
   on the other side of that dialog, or because it has access to the
   dialog identifiers.  The recipient can then authorize the request
   based on this awareness.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-ietf-sip-target-dialog-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:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-target-dialog-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.

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

Re: Target-Dialog draft submitted - open issue around kpml, dialog package

I prefer (1) with a slight modification: you need to say that event 
packages needing this information are required to choose which 
mechanism to use and document it. If an event package does not define a 
mechanism then the target-dialog header should be used. target-dialog 
extension must not be used with event packages the define where to 
place such info.

I don't think the drawback you mention for 1 is a drawback really. 
Implementers of an event package that already defines where to find 
target dialog information (like dialog package) would not use this 
extension and therefore recipients who also understand the package 
would not look in 2 places. The package document tells you where to 
look.

Hisham

On Apr 4, 2005, at 9:23 AM, Jonathan Rosenberg wrote:

> Folks,
>
> I've updated the target dialog draft based on discussions during IETF 
> and some list comments, and submitted it. Until it appears, you can 
> pick it up at:
>
> http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-00.txt
>
> Writing this up did pop out an open issue which we need to resolve. 
> This issue might impact the dialog and kpml package drafts depending 
> on how we go.
>
> The issue is this. The target-dialog draft says to include this header 
> field if you need a new request to be authorized by proving that you 
> know about a specific dialog. We made this a header field so that it 
> could work with REFER or SUBSCRIBE or even INVITE. With SUBSCRIBE, 
> however, two of the potential event packages to use this (dialog and 
> kpml), ALREADY have a means of proving that the subscriber knows the 
> target dialog - through the Event header field parameters which each 
> define. Thus, it would seem that including the event header field 
> parameters and target-dialog header field is redundant.
>
> I see three solutions:
>
> 1. Only include the target-dialog header field when there isn't 
> already something in the message that proves you know the target 
> dialog. The drawback here is that a UA seeking authorization of a 
> request will need to potentially look in several places for proof of 
> dialog awareness.
>
> 2. Include both of them. They have different semantics. The event 
> header parameters are basically filters. The target-dialog header 
> field is used to drive authorization. Thus, a single request will 
> often have both containing the same dialog identifiers. One might 
> imagine cases where they aren't the same; i.e. I subscribe using the 
> dialog event package to dialog X, but authorization is based on my 
> awareness of dialog Y.
>
> 3. Limit Target-DIalog to REFER, possibly INVITE.
>
>
>
> (2) is more general but inefficient. (1) is more efficient, and more 
> compatible with how kpml and the dialog event package work today. 
> Going with approach (2) means that both documents might need to be 
> updated; KPML at least probably would.
>
> I'm inclined to go for (1), but there was ample arguments in favor of 
> (1) and (2) that I wanted to bring it to the list. The target-dialog 
> draft is currently written assuming solution (2), however. I'd need to 
> update it if we go to (1).
>
> I've also updated app-interaction to make usage of target dialog, but 
> I'll wait to submit that until we've concluded this issue.
>
> Thanks,
> Jonathan R.
>
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen <at> 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 <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Question to Identity draft

Hi Jon, hi Cullen,

by reading the IDs regarding enhanced identity management
(draft-ietf-sip-identity-04) and certificate management
(draft-ietf-sipping-certs-01) I've got a question to a possible use case. 

Assumed that two user A and B from two different domains X and Y want to
communicate securely. User A sends his INVITE with an attached certificate
to User B in domain Y. The INVITE is send through an authentication service,
which authenticates (according the identity draft) that the AOR matches the
FROM field. Additionally a digital signature is calculated also over the
body of the message. Thus also the attached certificate is signed. Using
this approach would assure User B that User A has registered with his
credentials in domain X. User B could then use the received certificate to
communicate securely with user A at least for the duration of the session.
User B may also send his certificate to user B also through an
authentication service. Within a next session, when both users newly
registered, the certificates may be different than in the session before.

Is this scenario somehow covered by the identity draft? It could save the
credential server in certain scenarios. The approach itself may require an
enhanced storing of the username and certificate associations if
non-repudiation is desired.

Regards	
	Steffen

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

Comments : draft-sparks-sip-nit-problems-02

Hi Robert,

Please find below the comments I have on the mentioned
draft.

regards
Rayees
(Flextronics Software Systems, India)

Sedtion 1.1
-----------
o Other option could be to make NITs 3-way handshaked
as opposed to the current 2-way one

Section 1.3
-----------
o DNS SRV records have a TTL value which is returned
along with other params in a DNS SRV query. This
parameter can be used to determine when to flush it
out from cache
o As soon as it is flushed out from cache SIP EP
should retry to get the DNS SRV record from DNS 
o It does make sense to have a black list. However,
the question arises again when is an address removed
from the blacklist? Should we have a mechanism of
pinging the addresses in the blacklist so that if it
responds it is removed from the list

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Sports - Sign up for Fantasy Baseball. 
http://baseball.fantasysports.yahoo.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 <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Question for 'Preconfigured Outbound-Proxy' and 'Out-Dialog Request'

Hello.

I am Sip Stack Developer and have a question for ‘Preconfigured Outbound-Proxy’ and ‘Out-Dialog Request’.

For example, preconfigured Outboud-Proxy address is ‘outbound.domain.com:5060’ and this request
is out dialog.
And Request Uri or To Header Field is not equal to outbound proxy.
Then which one is correct?

Case 1.
REGISTER sip:domain.com SIP/2.0
To: <sip:apple <at> domain.com>
Route: <sip:outbound.domain.com;lr>
... ...
and this message is automatically sent to outbound.domain.com by sip stack.

Case 2.
REGISTER sip:domain.com SIP/2.0
To: <sip:apple <at> domain.com>
... ...
and this message is implicitly sent to outbound.domain.com by client transceiver.

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

Fwd: Comments : draft-sparks-sip-nit-problems-02

Note: forwarded message attached.

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

From: Rayees Khan <rakhanhss <at> yahoo.com>
Subject: Comments : draft-sparks-sip-nit-problems-02
Date: 2005-04-04 12:25:54 GMT

Hi Robert,

Please find below the comments I have on the mentioned
draft.

regards
Rayees
(Flextronics Software Systems, India)

Sedtion 1.1
-----------
o Other option could be to make NITs 3-way handshaked
as opposed to the current 2-way one

Section 1.3
-----------
o DNS SRV records have a TTL value which is returned
along with other params in a DNS SRV query. This
parameter can be used to determine when to flush it
out from cache
o As soon as it is flushed out from cache SIP EP
should retry to get the DNS SRV record from DNS 
o It does make sense to have a black list. However,
the question arises again when is an address removed
from the blacklist? Should we have a mechanism of
pinging the addresses in the blacklist so that if it
responds it is removed from the list

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Sports - Sign up for Fantasy Baseball. 
http://baseball.fantasysports.yahoo.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 <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

RE: Target-Dialog draft submitted - open issue around kpml, dialog package

We also prefer (1), and, being a "legacy" event package, KPML uses the
mechanism documented in the draft.

> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org]On Behalf Of
> Hisham Khartabil
> Sent: Monday, April 04, 2005 4:12 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] Target-Dialog draft submitted - open issue around
> kpml, dialog package
> 
> 
> I prefer (1) with a slight modification: you need to say that event 
> packages needing this information are required to choose which 
> mechanism to use and document it. If an event package does 
> not define a 
> mechanism then the target-dialog header should be used. target-dialog 
> extension must not be used with event packages the define where to 
> place such info.
> 
> I don't think the drawback you mention for 1 is a drawback really. 
> Implementers of an event package that already defines where to find 
> target dialog information (like dialog package) would not use this 
> extension and therefore recipients who also understand the package 
> would not look in 2 places. The package document tells you where to 
> look.
> 
> Hisham
> 
> On Apr 4, 2005, at 9:23 AM, Jonathan Rosenberg wrote:
> 
> > Folks,
> >
> > I've updated the target dialog draft based on discussions 
> during IETF 
> > and some list comments, and submitted it. Until it appears, you can 
> > pick it up at:
> >
> > http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-00.txt
> >
> > Writing this up did pop out an open issue which we need to resolve. 
> > This issue might impact the dialog and kpml package drafts 
> depending 
> > on how we go.
> >
> > The issue is this. The target-dialog draft says to include 
> this header 
> > field if you need a new request to be authorized by proving 
> that you 
> > know about a specific dialog. We made this a header field 
> so that it 
> > could work with REFER or SUBSCRIBE or even INVITE. With SUBSCRIBE, 
> > however, two of the potential event packages to use this 
> (dialog and 
> > kpml), ALREADY have a means of proving that the subscriber 
> knows the 
> > target dialog - through the Event header field parameters 
> which each 
> > define. Thus, it would seem that including the event header field 
> > parameters and target-dialog header field is redundant.
> >
> > I see three solutions:
> >
> > 1. Only include the target-dialog header field when there isn't 
> > already something in the message that proves you know the target 
> > dialog. The drawback here is that a UA seeking authorization of a 
> > request will need to potentially look in several places for 
> proof of 
> > dialog awareness.
> >
> > 2. Include both of them. They have different semantics. The event 
> > header parameters are basically filters. The target-dialog header 
> > field is used to drive authorization. Thus, a single request will 
> > often have both containing the same dialog identifiers. One might 
> > imagine cases where they aren't the same; i.e. I subscribe 
> using the 
> > dialog event package to dialog X, but authorization is based on my 
> > awareness of dialog Y.
> >
> > 3. Limit Target-DIalog to REFER, possibly INVITE.
> >
> >
> >
> > (2) is more general but inefficient. (1) is more efficient, 
> and more 
> > compatible with how kpml and the dialog event package work today. 
> > Going with approach (2) means that both documents might need to be 
> > updated; KPML at least probably would.
> >
> > I'm inclined to go for (1), but there was ample arguments 
> in favor of 
> > (1) and (2) that I wanted to bring it to the list. The 
> target-dialog 
> > draft is currently written assuming solution (2), however. 
> I'd need to 
> > update it if we go to (1).
> >
> > I've also updated app-interaction to make usage of target 
> dialog, but 
> > I'll wait to submit that until we've concluded this issue.
> >
> > Thanks,
> > Jonathan R.
> >
> >
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Director, Service Provider VoIP Architecture   Parsippany, NJ 
> > 07054-2711
> > Cisco Systems
> > jdrosen <at> 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 <at> cs.columbia.edu for questions on current sip
> > Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip