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

Lorenzo,

Again, this is very helpful. Thank you for your quick response.

Spencer

----- Original Message ----- 
From: "Lorenzo Miniero" <lorenzo@meetecho.com>
To: <spencer@wonderhamster.org>
Cc: <keith.drage@alcatel-lucent.com>; <mediactrl@ietf.org>
Sent: Wednesday, March 31, 2010 2:19 PM
Subject: Re: [MEDIACTRL] Fw: New MRB document (-04)

Hi Spencer, Keith,

I think that, rather than the support for multipart itself, the option tag 
should actually advertise the support for the new content type that could be 
part of such a payload, i.e., the Consumer XML blob. In IAMM, 
multipart/mixed is exploited because such a payload needs to be put together 
with an SDP payload.

At least, that's my interpretation of Ben's comment:

"I think you really need a required/supported option tag to indicate the 
expected interpretation of the new body parts. You can't just infer the 
application by the presence of the body parts, as future applications could 
someday use the same MIME types."

I apologize if this wasn't clear enough in my original mail.

Thanks,
Lorenzo

---------- Original Header -----------

Da      : mediactrl-bounces@ietf.org
A          : "DRAGE, Keith (Keith)" keith.drage@alcatel-lucent.com, 
mediactrl@ietf.org
Cc          :
Data      : Wed, 31 Mar 2010 12:29:24 -0500
Oggetto : Re: [MEDIACTRL] Fw:  New MRB document (-04)

> 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)" <keith.drage@alcatel-lucent.com>
> To: "Spencer Dawkins" <spencer@wonderhamster.org>; <mediactrl@ietf.org>
> 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:
>
>    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: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On
> Behalf Of Spencer Dawkins
> Sent: Wednesday, March 31, 2010 2:26 PM
> To: mediactrl@ietf.org
> 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.
>
> Eric, Robert - am I getting this right?
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- 
> From: Chris Boulton <mailto:chris@ns-technologies.com>
> To: mediactrl@ietf.org
> 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 <http://www.ns-technologies.com>
> m: +44.7876.476681
>
>
> ________________________________
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>

--
Lorenzo Miniero
http://www.meetecho.com