Re: [sipcore] Content-Length in multipart body parts

[<[e-mail]>]

I just noticed that the status of erratum #3167 on RFC 6086 (SIP INFO) was changed from "Reported" to "Held for Document Update" rather than "Approved/Verified".

I guess that this decision was made based on the following guidelines for errata processing
http://www.ietf.org/iesg/statement/errata-processing.html

1) Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 
2) Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update.

Although the reported error occurs in examples only, I would like to stress that they do cause significant confusion as some vendors have relied on such examples. I'm aware of practical interoperability issues currently encountered in some networks due to these examples. Therefore, I don't think the "Held for Document Update" status is appropriate.

The same applies to other errata submitted (or to be submitted) on the RFCs mentioned below, especially Erratum #3183 on RFC3261, although its status is still marked as "Reported".

Bruno


> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part
> de Paul Kyzivat
> Envoyé : mardi 3 avril 2012 00:37
> À : Hadriel Kaplan
> Cc : Dale R (Dale) Worley; <[e-mail]>
> Objet : Re: [sipcore] Content-Length in multipart body parts
> 
> On 4/2/12 6:21 PM, Hadriel Kaplan wrote:
> >
> > Ugh.  Yeah, that's not good for examples to show.
> > So what's the solution?  Errata?
> 
> Yes, I think the errata process is the right one for this.
> 
> 	Thanks,
> 	Paul
> 
> > -hadriel
> > p.s. I like the "Suspicious Line" thing - all RFC lines are
> suspicious! ;)
> >
> >
> > On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote:
> >
> >> [reposting with a subject line]
> >>
> >> On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote:
> >>> Bruno Chatras has pointed out that a number of examples in various
> SIP-related
> >>> RFCs show Content-Length header fields in the headers of body-parts of
> multipart
> >>> entities.  MIME does not define the meaining of such header fields, as
> the MIME
> >>> framing of body parts is done by the boundary markers.
> >>>
> >>> As Dale Moberg has pointed out, these header fields might not be truly
> incorrect
> >>> but merely redundant or "to be ignored".
> >>>
> >>> But given that MIME multipart already frames the body-parts, Content-
> Length
> >>> headers on body-parts are never necessary.
> >>>
> >>> So it seems to me that we should decide on a "best practices" for the
> use of
> >>> Content-Length in the headers of a body part, to clarify the
> ambiguities in the
> >>> specifications, and to state whether it's preferable to include such a
> Content-Length
> >>> or not.
> >>>
> >>> I've appended a list of all the examples carrying such Content-Length
> headers
> >>> that I could find by automated means.
> >>>
> >>> Dale
> >>> ----------------------------------------------------------------------
> ----------------------------------
> >>> RFC 2848
> >>>
> >>>                         The PINT Service Protocol:
> >>>     Extensions to SIP and SDP for IP Access to Telephone Call Services
> >>>
> >>> Suspicious line at rfc2848.txt:2195:       Content-Length: 236
> >>> Suspicious line at rfc2848.txt:2209:       Content-Length:50
> >>> Suspicious line at rfc2848.txt:2268:       Content-Length: 316
> >>> Suspicious line at rfc2848.txt:2284:       Content-Length: 172
> >>> Suspicious line at rfc2848.txt:2372:    Content-Length: 325
> >>> Suspicious line at rfc2848.txt:2387:    Content-Length: 352
> >>>
> >>> Several of these body-part headers are not separated from the
> >>> body-part contents by CR-LF-CR-LF.
> >>>
> >>> RFC 3261
> >>>
> >>>                      SIP: Session Initiation Protocol
> >>>
> >>> Suspicious line at rfc3261.txt:11846:         Content-Length: 231
> >>>
> >>> RFC 3892
> >>>
> >>>        The Session Initiation Protocol (SIP) Referred-By Mechanism
> >>>
> >>> Suspicious line at rfc3892.txt:642:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:687:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:702:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:879:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:887:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:938:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:964:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:972:       Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:1056:      Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:1106:      Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:1168:      Content-Length: (appropriate
> value)
> >>> Suspicious line at rfc3892.txt:1196:      Content-Length: (appropriate
> value)
> >>>
> >>> RFC 3893
> >>>
> >>>                     Session Initiation Protocol (SIP)
> >>>                  Authenticated Identity Body (AIB) Format
> >>>
> >>> Suspicious line at rfc3893.txt:249:    Content-Length: 147
> >>> (This has an extra CR-LF before the body-part headers.)
> >>> Suspicious line at rfc3893.txt:263:    Content-Length: 608
> >>>
> >>> RFC 4463
> >>>
> >>>                  A Media Resource Control Protocol (MRCP)
> >>>                Developed by Cisco, Nuance, and Speechworks
> >>>
> >>> Suspicious line at rfc4463.txt:1705:        Content-Length:176
> >>> Suspicious line at rfc4463.txt:1714:        Content-Length:104
> >>> Suspicious line at rfc4463.txt:2977:       Content-Length:176
> >>> (Also missing the CR-LF after the body part headers.)
> >>> Suspicious line at rfc4463.txt:2985:       Content-Length:104
> >>>
> >>> RFC 5547
> >>>
> >>>        A Session Description Protocol (SDP) Offer/Answer Mechanism
> >>>                          to Enable File Transfer
> >>>
> >>> Suspicious line at rfc5547.txt:1645:    Content-Length: [length of SDP]
> >>> Suspicious line at rfc5547.txt:1670:    Content-Length: [length of
> image]
> >>> Suspicious line at rfc5547.txt:2093:    Content-Length: [length of SDP]
> >>> Suspicious line at rfc5547.txt:2118:    Content-Length: [length of
> image]
> >>>
> >>> RFC 5589
> >>>
> >>>         Session Initiation Protocol (SIP) Call Control - Transfer
> >>>
> >>> Suspicious line at rfc5589.txt:2609:    Content-Length: 2961
> >>> (An extra CR-LF in the middle of the body part headers.)
> >>> Suspicious line at rfc5589.txt:2677:    Content-Length: 156
> >>> (An extra CR-LF in the middle of the body part headers.)
> >>> Suspicious line at rfc5589.txt:2696:    Content-Length: 2961
> >>>
> >>> RFC 6086
> >>>
> >>>    Session Initiation Protocol (SIP) INFO Method and Package Framework
> >>>
> >>> Suspicious line at rfc6086.txt:1594:    Content-length: 59
> >>> Suspicious line at rfc6086.txt:1620:    Content-length: 59
> >>> Suspicious line at rfc6086.txt:1637:    Content-length: 59
> >>> Suspicious line at rfc6086.txt:1664:    Content-length: 59
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >
> >
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.