I didn't intend to sidestep - I was asserting what I thought the spec should say. I think its right as is (if not as clear as it should be).
more inline On Mon, 2004-06-21 at 14:09, Paul Kyzivat wrote: > Robert, > > You looked at the same text I did, and came to the same conclusion I did > about what the spec currently says. But you sidestepped the questions I > raised about whether that is what is *should* say. > > More below. > > Paul > > Robert Sparks wrote: > > So, here's the guiding text: > > > > 2. Definition: message/sipfrag > > > > A valid message/sipfrag part is one that could be obtained by > > starting with some valid SIP message and deleting any of the > ^^^^^ > The above requirement to start with a *valid* sip message is > questionable. One of the key use cases for sipfrag is for the NOTIFY > messages that report on the status of a REFERed request. > > Now suppose that the REFER caused an INVITE, and the response to the > invite was itself invalid, either in the SIP or the SDP. Is it > permissible to put that invalid message in the NOTIFY, as a sipfrag, > even though it is an invalid sip message? It would be inconvenient if > that were illegal. So the question is if it's ok to pass something totally invalid back in a sipfrag (move the context here into the headers - is it OK to pass a sipfrag with a malformed Via for example). The spec currently says no. I think that's right - its hard to construct a plausible scenario where something receiving a sipfrag with garbage in it is algorithmically going to do something sane (other than just asking a human to look at it, in which case it can be text/plain). > > I guess I can imagine some other type than sipfrag, that has weaker > constrains on what it can contain. Maybe something like > message/ostensibly-sip or message/ostensibly-sipfrag. But if there was > such a thing, would there still be a use for message/sipfrag? You're thinking at the wrong level - the type of the overall message should still be message/sipfrag. The type of the body it contains is the one that needs to be modified. The point of this is to be able to use the parser that goes along with the advertised MIME type at any level when chewing through a nested set of MIME bodies. > > > following: > > > > o the entire start line > > > > o one or more entire header fields > > > > o the body > > > > Thus, the body of any given sipfrag must be able to occur as the body > > of some valid SIP message (that otherwise matches the rest of the > > information in this given sipfrag of course). > > > > So, for the particular example you are exploring, you are correct. > > Advertising application/sdp and then only including a syntactically > > incorrect SDP body would be incorrect. You'll need to put that > > fractional SDP in something that makes sense from a MIME perspective: > > either create an sdpfrag type, or shove it into a wrapper (text/plain?) > > and make decoding it part of the semantics of whatever context you're > > using such a thing in. > > > > RjS > > > > > > > > On Mon, 2004-06-21 at 11:19, Paul Kyzivat wrote: > > > >>I received a question from a coworker regarding valid content for > >>application/sipfrag. The question was: > >> > >>if the fragment represents part of a message that contained a body, can > >>the fragment contain just a portion of the body? > >> > >>(I've generalized this - the actual question was whether the fragment > >>could contain a Content-Type:application/sdp, and then contain just a > >>portion of the actual sdp - a portion that was not syntactically correct > >>SDP.) > >> > >>Based on my reading of rfc 3420, I think the answer is NO. But it does > >>raise the question whether the answer (to the generalized question) > >>*should* be YES. I'm undecided on this, and would like to hear other > >>opinions, but I am inclined to be pretty lenient. > >> > >>In part there is an uncertainty principle here. How would you be able to > >>tell a valid usage from an invalid one? Sipfrag is often used to relay > >>messages received from others. It is possible that those received > >>messages were ill-formed. In that case, a sipfrag that conveys the > >>ill-formed message could appear identical to one that was obtained by > >>invalid subsetting from a valid message. If you can't tell the > >>difference, why ban the practice? > >> > >>Another reason is that there may be increasing reason to subset the body > >>when building a sipfrag. For instance, the original message may have had > >>a large multipart body. But for purposes of the sipfrag only one of the > >>parts is significant. > >> > >> Paul > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
