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

[<[e-mail]>]

> -----Message d'origine-----
> De : Paul Kyzivat [mailto:[e-mail]]
> Envoyé : lundi 25 juin 2012 16:15
> À : CHATRAS Bruno RD-CORE
> Cc : Hadriel Kaplan; Dale R (Dale) Worley; <[e-mail]>
> Objet : Re: [sipcore] Content-Length in multipart body parts
> 
> On 6/25/12 7:24 AM, [e-mail] wrote:
> > 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.
> 
> How many times do we need to repeat that examples are non-normative?
> 
> People who implement to examples rather than the specs almost always run
> into problems. IMO the way this gets fixed is for someone who encounters
> an interop problem due to someone else having implemented to an example
> rather than the spec needs to call this out as an error and request that
> it be fixed. Anybody who argues that their implementation is justified
> because it is compliant with an example won't get support for that
> position.
> 
> The implementers who have this problem most likely won't have looked at
> the errata either. 
[BC] Their customers can tell them to look at the errata when requesting them to fix the error.

If they do look at the errata, will changing the
> status from "Held" to "Accepted" change their behavior?
[BC] That's what I understood from at least one of them...




> 
> 	Thanks,
> 	Paul
> 
> > 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.
> >
> >


_________________________________________________________________________________________________________________________

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.