Subject: [MEDIACTRL] Fw: New MRB document (-04)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 31 Mar 2010 08:26:29 -0500

Hi, Chris,

This is NOT my understanding of the requirement for SIP option tags (see MARTINI for a counter-example) - the whole point of http://tools.ietf.org/html/rfc5727/, as I understood it, was to allow multiple groups to extend SIP, as long as they used a Standards Action for option tags, and as long as they weren't touching RFC 3261-3265, which is still the domain of SIPCORE.

If the point of this option tag is to say "yeah, we know a lot of SIP implementations don't support MIME multipart/mixed, but we're going to use it", I do think that a note to DISPATCH might be useful, and I'm thinking that the option name should not be tied to the IAMM usage (because it's applicable to other usages), but I think MEDIACTRL can do this. 

Eric, Robert - am I getting this right?

Thanks,

Spencer

----- Original Message ----- 
From: Chris Boulton 
To: [email-masked] 
Sent: Wednesday, March 31, 2010 3:14 AM
Subject: Re: [MEDIACTRL] New MRB document (-04)

2) Required/Support header in SIP

Ben also pointed out that a proper piece of information, an option tag, may be needed in the Required/Supported headers for the Consumer-over-SIP case to address the use of multipart/mixed payloads in IAMM. A proper name for the option tag, considering the use case, might be just 'iamm'. Is it acceptable to specify such information in this document (and if so, is there any guideline that should be followed), or is it something that falls instead under the responsibility of other WGs, e.g., SIPCORE?

  [Chris] We had similar issues earlier in the MediaCtrl process that got a bit messy when we started adding stuff to MediaCtrl documents and have taken a wide berth since.  I think we will upset a few people by having it defined in the MRB doc - do the chairs agree in the new world of SIPCORE and DISPATCH?  I suspect to complete we do need an option tag - and I suspect it needs to be submitted to SIPCORE?  Eric/Spencer - thoughts?

Chris.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies
m: +44.7876.476681

--------------------------------------------------------------------------------

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Mar 2010 18:54:21 +0200

I've not been able to find the original thread where Ben raised an issue, so I am guessing a bit at the issue...

However...

RFC 5727 says:

   2.  Standard SIP extensions that do not update RFCs 3261 through
       3265, including event packages, may advance through chartered
       activity in any RAI Area WG or (with the agreement of the RAI
       ADs) any IETF working group that constitutes an appropriate
       venue.

However it does reserve certain work to SIPCORE with statements like:

   1.  Documents that update or obsolete RFCs 3261 through 3265 must
       advance through the SIPCORE WG.

and

   Work overseen by the SIPCORE Working Group is required to protect the
   architectural integrity of SIP and must not add features that do not
   have general use beyond the specific case.  Also, SIPCORE must not
   add features just to make a particular function more efficient at the
   expense of simplicity or robustness.

But I would note that RFC 3261 was updated by RFC 5621 (it did not just create an extension), with the following text:

4.2.  Mandatory Support for 'multipart' Message Bodies

   For all MIME-based extensions to work, the recipient needs to be able
   to decode the multipart bodies.  Therefore, SIP UAs MUST support
   parsing 'multipart' MIME bodies, including nested body parts.
   Additionally, UAs MUST support the 'multipart/mixed' and 'multipart/
   alternative' MIME types.  Support for other MIME types such as
   'multipart/related' is OPTIONAL.

      Note that, by default, unknown 'multipart' subtypes are treated as
      'multipart/mixed'.  Also note that SIP extensions can also include
      'multipart' MIME bodies in responses.  That is why both UACs and
      UASs need to support 'multipart' bodies.

This text is in essence therefore part of RFC 3261. If I understand correctly, you wish to create an option tag to describe something that does not conform to existing mandatory practice, which is like creating an option tag for advertising RFC 2543 behaviour. 

Creating such an option tag would seem to me to be something affecting the core architecture of SIP in terms of what it does. 

I would also ask why you do not just ask the equipment to conform, rather than have to go through an exercise of developing code for a new option tag on a non-conformant device.

regards

Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
	Sent: Wednesday, March 31, 2010 2:26 PM
	To: [email-masked]
	Subject: [MEDIACTRL] Fw: New MRB document (-04)

	Hi, Chris,
	 
	This is NOT my understanding of the requirement for SIP option tags (see MARTINI for a counter-example) - the whole point of <http://tools.ietf.org/html/rfc5727> http://tools.ietf.org/html/rfc5727 <http://tools.ietf.org/html/rfc5727/> /, as I understood it, was to allow multiple groups to extend SIP, as long as they used a Standards Action for option tags, and as long as they weren't touching RFC 3261-3265, which is still the domain of SIPCORE.

	 
	Thanks,
	 
	Spencer
	 
	----- Original Message ----- 
	From: Chris Boulton <mailto:[email-masked]>  
	To: [email-masked] 
	Sent: Wednesday, March 31, 2010 3:14 AM
	Subject: Re: [MEDIACTRL] New MRB document (-04)

	
	Chris.

	-- 
	Chris Boulton
	CTO & Co-founder
	NS-Technologies <http://www.ns-technologies.com> 
	m: +44.7876.476681

	________________________________

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 31 Mar 2010 12:29:24 -0500

Keith, this is extremely helpful - thanks for the background!

Chris, please tell me if I'm confused about something - I thought that what 
you guys were talking about was an option tag for stuff that DID conform to 
the statement Keith is pointing to - the problem was that current 
implementations don't handle multipart well, and this option tag would say 
"you can send us multipart, and it will work".

Did I get this wrong? If so, my apologies (and, of course, Keith's questions 
about RFC 5621 become interesting).

Thanks,

Spencer

----- Original Message ----- 
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 31, 2010 11:54 AM
Subject: RE: [MEDIACTRL] Fw: New MRB document (-04)

I've not been able to find the original thread where Ben raised an issue, so 
I am guessing a bit at the issue...

However...

RFC 5727 says:

and

But I would note that RFC 3261 was updated by RFC 5621 (it did not just 
create an extension), with the following text:

This text is in essence therefore part of RFC 3261. If I understand 
correctly, you wish to create an option tag to describe something that does 
not conform to existing mandatory practice, which is like creating an option 
tag for advertising RFC 2543 behaviour.

Creating such an option tag would seem to me to be something affecting the 
core architecture of SIP in terms of what it does.

I would also ask why you do not just ask the equipment to conform, rather 
than have to go through an exercise of developing code for a new option tag 
on a non-conformant device.

regards

Keith

From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Spencer Dawkins
Sent: Wednesday, March 31, 2010 2:26 PM
To: [email-masked]
Subject: [MEDIACTRL] Fw: New MRB document (-04)

Hi, Chris,

This is NOT my understanding of the requirement for SIP option tags (see 
MARTINI for a counter-example) - the whole point of 
<http://tools.ietf.org/html/rfc5727> http://tools.ietf.org/html/rfc5727 
<http://tools.ietf.org/html/rfc5727/> /, as I understood it, was to allow 
multiple groups to extend SIP, as long as they used a Standards Action for 
option tags, and as long as they weren't touching RFC 3261-3265, which is 
still the domain of SIPCORE.

If the point of this option tag is to say "yeah, we know a lot of SIP 
implementations don't support MIME multipart/mixed, but we're going to use 
it", I do think that a note to DISPATCH might be useful, and I'm thinking 
that the option name should not be tied to the IAMM usage (because it's 
applicable to other usages), but I think MEDIACTRL can do this.

Thanks,

Spencer

----- Original Message ----- 
From: Chris Boulton <mailto:[email-masked]>
To: [email-masked]
Sent: Wednesday, March 31, 2010 3:14 AM
Subject: Re: [MEDIACTRL] New MRB document (-04)

Ben also pointed out that a proper piece of information, an option tag, may 
be needed in the Required/Supported headers for the Consumer-over-SIP case 
to address the use of multipart/mixed payloads in IAMM. A proper name for 
the option tag, considering the use case, might be just 'iamm'. Is it 
acceptable to specify such information in this document (and if so, is there 
any guideline that should be followed), or is it something that falls 
instead under the responsibility of other WGs, e.g., SIPCORE?

[Chris] We had similar issues earlier in the MediaCtrl process that got a 
bit messy when we started adding stuff to MediaCtrl documents and have taken 
a wide berth since.  I think we will upset a few people by having it defined 
in the MRB doc - do the chairs agree in the new world of SIPCORE and 
DISPATCH?  I suspect to complete we do need an option tag - and I suspect it 
needs to be submitted to SIPCORE?  Eric/Spencer - thoughts?

Chris.