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

From: <[email-masked]>
Date: Mon, 25 Jun 2012 11:24:09 +0000

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 : [email-masked] [mailto:[email-masked]] De la part
> de Paul Kyzivat
> Envoyé : mardi 3 avril 2012 00:37
> À : Hadriel Kaplan
> Cc : Dale R (Dale) Worley; <[email-masked]>
> 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
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >
> >
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jun 2012 10:15:17 -0400

> 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 interoperab…

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. If they do look at the errata, will changing the 
status from "Held" to "Accepted" change their behavior?

	Thanks,
	Paul

>> Cc : Dale R (Dale) Worley;<[email-masked]>

---

From: <[email-masked]>
Date: Mon, 25 Jun 2012 14:43:50 +0000

> De : Paul Kyzivat [mailto:[email-masked]]
> Envoyé : lundi 25 juin 2012 16:15
> À : CHATRAS Bruno RD-CORE
> Cc : Hadriel Kaplan; Dale R (Dale) Worley; <[email-masked]>
> > 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".
> >
> > 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 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
> >
> >
> ________________________________________________________________________
> _________________________________________________
> >
> > 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,
> > This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> > As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> > Thank you.
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jun 2012 11:01:31 -0400

> [BC] That's what I understood from at least one of them...

IIUC you are saying that the following happened:

- Customer complains to implementer: Your implementation is wrong, and 
is breaking my system because you are using Content-Length in a body 
part. I claim that this is incorrect because according to the MIME specs 
C-L is not a valid header.

- Implementer responds: my use of C-L is valid, because it is shown in 
an example in RFC 6086.

- Customer responds to implementer: examples aren't normative. Please 
cite some normative text that permits C-L here. Also, the use of C-L in 
that example has already been reported to be an error.

- Implementer responds: I still consider the example to be valid because 
the error is still in state "held" rather than "accepted". I don't need 
to cite normative text for my use.

!@#$%^&*(

IMO such an implementer is either new, and needs to be clued in to how 
standards work, or else he is a lost cause. If he is a lost cause, then 
you need a neutral 3rd party to mediate.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 25 Jun 2012 11:55:13 -0400

> [BC] That's what I understood from at least one of them...

Please name the vendor so that we can all laugh at them!  (And know to
avoid buying their gear.)

Dale