Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Apr 2011 21:31:33 -0500

(oops, managed to miss Christer in the CC list. Sorry for the repeat)

Hi,

A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a face-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a backwards compatibility issue.

Specifically, an MSRP user agent implementing the sessmatch description that is behind an SBC or ALG that operates as the draft envisions cannot interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. The issue is not caused by the sessmatch extension per se, but by the SBC/ALG. However, the sole purpose of this extension is to allow such behavior.

We agreed that this was a backwards compatibility issue, and as such would not be acceptable without some negotiation mechanism.

We discussed the following options. Note that no one option was favored by all present--I will let people speak individually as to their preferences.

1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally different protocol from base MSRP

2) Create a SIP option tag that indicates that a UA both supports sessmatch, and does not use an MSRP relay.

3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, it must rewrite the MSRP header fields in a manner similar to an MSRP Relay.

The chairs would appreciate a quick resolution to this issue, and request anyone who cares please make their opinions known on the SIMPLE list as soon as possible.

Thanks!

Ben.
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Apr 2011 08:20:14 +0200

Hi,

I vote for option 2). I provides a mechanism to negotiate the usage of sessmatch, and the possibility for an SBC to perform fallback. Whether it does so, as Ben said, is an implementation/policy issue, but I can inform that there is at least one vendor considering such fallback support.

Option 3) is very bad, considering that there are already at least two other SDOs (OMA and 3GPP) refering to sessmatch (and have been doing so for quite a while already).

Option 1) is also bad, as it will cause confusing and additional work in other SDOs, and in the market in genral. And, option 2) provides the same outcome as option 1).

Regards,

Christer

________________________________________
From: Ben Campbell [[email-masked]]
Sent: Wednesday, April 06, 2011 5:31 AM
To: Simple WG
Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

Thanks!

Ben.

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 09:39:31 +0200

I support Option 2)

Thanks

Roland

> A small group (Christer, Cullen, Adam, Hadriel, John, and
> myself) held a face-to-face discussion of issues related to
> draft-ietf-simple-msrp-sessmatch-10. The discussion
> highlighted a backwards compatibility issue.
>
> Specifically, an MSRP user agent implementing the sessmatch
> description that is behind an SBC or ALG that operates as the
> draft envisions cannot interoperate with a peer that uses an
> MSRP Relay as defined in RFC 4976. The issue is not caused by
> the sessmatch extension per se, but by the SBC/ALG. However,
> the sole purpose of this extension is to allow such behavior.
>
> We agreed that this was a backwards compatibility issue, and
> as such would not be acceptable without some negotiation mechanism.
>
> We discussed the following options. Note that no one option
> was favored by all present--I will let people speak
> individually as to their preferences.
>
> 1) Treat MSRP over ALGs using the sessmatch extension as a
> fundamentally different protocol from base MSRP
>
> 2) Create a SIP option tag that indicates that a UA both
> supports sessmatch, and does not use an MSRP relay.
>
> 3) Give up on sessmatch, and assert that for an ALG or SBC to
> relay MSRP, it must rewrite the MSRP header fields in a
> manner similar to an MSRP Relay.
>
> The chairs would appreciate a quick resolution to this issue,
> and request anyone who cares please make their opinions known
> on the SIMPLE list as soon as possible.
>
> Thanks!
>
> Ben.

---

From: Atle Monrad <[email-masked]>
Date: Wed, 6 Apr 2011 10:49:12 +0200

Folks

As the new 3GPP / IETF coordinator, i can confirme that there is a 3GPP dependency on sessmatch since a quite long time.

I hope that we can solve the issue soon. Please don't drop or completely restart the topic.

I would also like to support option 2) for the reasons outlined by Christer below.

/atle 

________________________________ 

Atle Monrad
3GPP CT1 Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 6. april 2011 08:20
To: Ben Campbell; Simple WG
Cc: Cullen Jennings; [email-masked]; Adam Roach; John Mattsson
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

Regards,

Christer

Hi,

Thanks!

Ben.

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Apr 2011 12:58:47 +0200

Hi,

option 2 seems to be the right choice.

/Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Atle Monrad
Sent: Wednesday, April 06, 2011 10:49 AM
To: Ben Campbell; Simple WG
Cc: Cullen Jennings; [email-masked]; Adam Roach; John Mattsson
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Folks

As the new 3GPP / IETF coordinator, i can confirme that there is a 3GPP
dependency on sessmatch since a quite long time.

I hope that we can solve the issue soon. Please don't drop or completely
restart the topic.

I would also like to support option 2) for the reasons outlined by
Christer below.

/atle 

Atle Monrad
3GPP CT1 Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg

Hi,

I vote for option 2). I provides a mechanism to negotiate the usage of
sessmatch, and the possibility for an SBC to perform fallback. Whether
it does so, as Ben said, is an implementation/policy issue, but I can
inform that there is at least one vendor considering such fallback
support.

Option 3) is very bad, considering that there are already at least two
other SDOs (OMA and 3GPP) refering to sessmatch (and have been doing so
for quite a while already).

Option 1) is also bad, as it will cause confusing and additional work in
other SDOs, and in the market in genral. And, option 2) provides the
same outcome as option 1).

Regards,

Christer

Hi,

A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a
face-to-face discussion of issues related to
draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a
backwards compatibility issue.

Specifically, an MSRP user agent implementing the sessmatch description
that is behind an SBC or ALG that operates as the draft envisions cannot
interoperate with a peer that uses an MSRP Relay as defined in RFC 4976.
The issue is not caused by the sessmatch extension per se, but by the
SBC/ALG. However, the sole purpose of this extension is to allow such
behavior.

We agreed that this was a backwards compatibility issue, and as such
would not be acceptable without some negotiation mechanism.

We discussed the following options. Note that no one option was favored
by all present--I will let people speak individually as to their
preferences.

1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally
different protocol from base MSRP

2) Create a SIP option tag that indicates that a UA both supports
sessmatch, and does not use an MSRP relay.

3) Give up on sessmatch, and assert that for an ALG or SBC to relay
MSRP, it must rewrite the MSRP header fields in a manner similar to an
MSRP Relay.

The chairs would appreciate a quick resolution to this issue, and
request anyone who cares please make their opinions known on the SIMPLE
list as soon as possible.

Thanks!

Ben.

---

From: Victor Pascual Avila <[email-masked]>
Date: Sun, 10 Apr 2011 21:21:33 +0200

+1

-- 
Victor Pascual Ávila

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 14 Apr 2011 13:15:23 -0400

I support option 2.

-hadriel

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Apr 2011 12:36:21 -0500

(as chair)

The responses so far seem to show a rough consensus in favor of option 2.  I think it's time to move on to a technical discussion on how such an option tag will work. 

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Apr 2011 21:19:11 +0200

Hi,

I've drafted some text regarding the usage of an option-tag for sessmatch.

Comments are welcome.

-----

 An MSRP entity that supports the sessmatch extension, and is not 
 located behind an MSRP relay, MUST insert the 'sessmatch' option-tag 
 in the Supported header field of the initial INVITE request for a session 
 that contains MSRP media.
 
 An MSRP entity that supports the sessmatch extension, and is not 
 located behind an MSRP relay, MUST insert the 'sessmatch' option-tag 
 in at least one reliably sent successful response to the intial INVITE 
 request for a session that contains MSRP media.
 
 In addition to inserting the 'sessmatch' option-tag in the Supported 
 header field of the INVITE request, if the MSRP entity is performing 
 MSRP related procedures that require the remote MSRP entity to support 
 the sessmatch extension in order to enable MSRP meddia, it MUST also 
 insert the 'sessmatch' option-tag in the Require header field ofthe request.
 
 NOTE: An example of a scenarios where an MSRP entity needs to insert 
 the 'sessmatch' option-tag in the Require header field, is when it 
 acts as an intermediary MSRP entity that modifies the SDP a=path 
 attribute address information, in order to anchor and forward MSRP 
 traffic, but does not perform the corresponding address information 
 changes in the associated MSRP messages. The actions taken by such 
 MSRP entity in case the remote MSRP entity does not support the sessmatch 
 extension, and therfore sends a 420 (Not Supported) response to the 
 INVITE request, is outside the scope of this specification.
 
 An MSRP entity that are deployed in environment where all MSRP 
 entities that it will communicate with are mandated to support the 
 sessmatch extension MAY omit the 'sessmatch' option tag.
 
 NOTE: The reason for omitting the 'sessmatch' option-tag is to provide 
 backward compability in networks where the MSRP entities are based on 
 an earlier version of the sessmatch specification, in which usage of 
 the option-tag was not defined.
 
-----

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 14. huhtikuuta 2011 20:36
To: Simple WG
Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

(as chair)

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Apr 2011 14:24:12 -0500

(as chair)

By the way, Gonzalo confirmed that we can in fact define an option tag in SIMPLE.

Thanks!

Ben.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 18 Apr 2011 10:32:07 +0200

Hi,

>  the option-tag was not defined.

The text sounds good to me, but those 2 last paragraphs may break
everything stated above.

Do we need to maintain backwards compatibility taking into account
that sessmatch is still a draft (which could change, as its doing
now)? Also, the use case for that feels a bit narrow to me, how can I
be sure I'll *only* communicate with sessmatch enabled devices? As
long as its not a walled garden :-)

My 2 cents.

Regards,

-- 
/Saúl
http://saghul.net | http://sipdoc.net

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 18 Apr 2011 10:38:45 +0200

>  the option-tag was not defined.

Hi, let me a question: is such earlier version of sessmatch
specification a draft or a RFC?

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Apr 2011 10:28:13 -0500

(as individual)

> long as its not a walled garden :-)

I concur. The whole point of the option tag is to avoid balkanizing the protocol. If you allow for scenarios where people think they don't need to interop can ignore the backward compatibility feature, then there's little point for the feature in the first place. 

The idea of an environment where all entities are mandated to support sessmatch contemplates entities being prohibited from communication with endpoints outside their walled garden. I don't think we want to encourage that. It's one thing to forbid this by policy--it's entirely different to prevent it via technology. If a carrier decides to open up at some point in the future, it would be ill-served to find its endpoints were unable to communicate because the implementor assumed they would never be used outside a walled garden.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Apr 2011 18:00:43 +0200

Hi,

I'm ok to remove the text paragraph and the note.

Regards,

Christer

________________________________________
From: Ben Campbell [[email-masked]]
Sent: Monday, April 18, 2011 6:28 PM
To: Saúl Ibarra Corretgé
Cc: Christer Holmberg; Simple WG
Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue]

(as individual)

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 18 Apr 2011 18:13:32 +0200

> I'm ok to remove the text paragraph and the note.

That's great, thanks!

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Apr 2011 20:46:33 +0200

Hi,

An uppdated version of the proposed option-tag text below.

The only difference is that I removed the last paragraph and note from the previous text proposal.

-----

 An MSRP entity that supports the sessmatch extension, and is not located behind an MSRP relay, MUST insert 
 the 'sessmatch' option-tag  in the Supported header field of the initial INVITE request for a session that 
 contains MSRP media.
 
 An MSRP entity that supports the sessmatch extension, and is not located behind an MSRP relay, MUST insert 
 the 'sessmatch' option-tag in at least one reliably sent successful response to the intial INVITE request 
 for a session that contains MSRP media.
 
 In addition to inserting the 'sessmatch' option-tag in the Supported header field of the INVITE request, 
 if the MSRP entity is performing  MSRP related procedures that require the remote MSRP entity to support 
 the sessmatch extension in order to enable MSRP meddia, it MUST also insert the 'sessmatch' option-tag 
 in the Require header field ofthe request.
 
 NOTE: An example of a scenarios where an MSRP entity needs to insert the 'sessmatch' option-tag in the 
 Require header field, is when it  acts as an intermediary MSRP entity that modifies the SDP a=path attribute
 address information, in order to anchor and forward MSRP traffic, but does not perform the corresponding 
 address information  changes in the associated MSRP messages. The actions taken by such  MSRP entity in 
 case the remote MSRP entity does not support the sessmatch extension, and therfore sends a 420 (Not Supported) 
 response to the  INVITE request, is outside the scope of this specification.
 
-----

Regards,

Christer 

-----Original Message-----
From: Saúl Ibarra Corretgé [mailto:[email-masked]] 
Sent: 18. huhtikuuta 2011 19:14
To: Christer Holmberg
Cc: Ben Campbell; Simple WG
Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue]

That's great, thanks!

Regards,

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Apr 2011 12:08:45 +0200

The second paragraph does not state which header field is used. I assume from the third paragraph "In addition", that it is the Supported header field.

Nowhere do you appear to state what the recipient understands when it receives such an option tag, and therefore what it can safely do as a result, nor what it should assume if it does not receive it. 

Keith

> Sent: 18 April 2011 19:47
> To: 'Saúl Ibarra Corretgé'
> Cc: Simple WG
> Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-
> ietf-simple-msrp-sessmatch-10 Issue] - Version 2
> 
> 
> Hi,
> 
> header field of the INVITE request,
> insert the 'sessmatch' option-tag

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Apr 2011 12:38:55 +0200

Hi Keith, 

>The second paragraph does not state which header field is 
>used. I assume from the third paragraph "In addition", that 
>it is the Supported header field.

Correct.

	"An MSRP entity that supports the sessmatch extension, and is not 
	located behind an MSRP relay, MUST insert the 'sessmatch' 
	option-tag in the Supported header field of at least one reliably 
	sent successful response to the intial INVITE request for a 
	session that contains MSRP media."

>Nowhere do you appear to state what the recipient understands 
>when it receives such an option tag, and therefore what it 
>can safely do as a result, nor what it should assume if it 
>does not receive it. 

Good point.

I suggest to re-write the paragraph mentioned above:

	"If an MSRP entity that supports the sessmatch extension receives an 
	initial INVITE request that contains the 'sessmatch' option-tag in 
	the Supported or Require header field of the request, and if it is not 
	located behind an MSRP relay, it MUST insert the 'sessmatch' option-tag 
	in the Supported header field of at least one reliably sent successful 
	response to the intial INVITE request, and it MUST use the session
	matching procedures defined in this specification during the session.
	Otherwise the MSRP entity MUST NOT insert the 'sessmatch' option-tag in
	a successful response to the initial INVITE request, and it MUST use 
	the session matching procedures defined in [RFC4975]."

In addition, I suggest to re-write the first paragraph:

	"An MSRP entity that supports the sessmatch extension, and is not 
	located behind an MSRP relay, MUST insert the 'sessmatch' option-tag  
	in the Supported header field of the initial INVITE request for a session 
	that contains MSRP media. If at least one reliably sent successful 
	response to the intial INVITE request contains the 'sessmatch' option-tag
	in the Supported header field of the response, the MSRP entity MUST 
	use the session matching procedures defined in this specification during 
	the session. Otherwise the MSRP entity MUST use the procedures defined 
	in [RFC4975]."

Regards,

Christer

> > The only difference is that I removed the last paragraph 
> and note from 
> > the previous text proposal.
> > 
> > -----
> > 
> > in the Supported header field of the initial INVITE request for a 
> > session that  contains MSRP media.
> > 
> > insert the 'sessmatch' option-tag  in the Require header 
> field ofthe 
> > request.
> > 
> > MSRP entity in  case the remote MSRP entity does not support the 
> > sessmatch extension, and therfore sends a 420 (Not Supported)  
> > ietf-simple-msrp-sessmatch-10 Issue]
> >