Eric Burger wrote:
Well, we are only sort-of munging MIME. The default is always RENDER.
However, *what* is a render is an exercise for the protocol to specify.
That is the wiggle room for SIP to say "render means by-context."
What we do not have the wiggle room for is to say the default
content-disposition is something other than RENDER.
Well, we have *already* said that the default Content-Disposition is
something other than "render" for certain Content-Types. E.g. for C-T of
application/sdp the default disposition is "session". There are other
special cases for some other content types as well.
Is that really kosher for MIME, or did we already do something bad?
In any case, what I was suggesting is that we spend some effort defining
what "render" means for SIP.
Paul
On 7/22/07 12:17 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
Eric Burger wrote:
I would offer this is where we can "add value" to MIME for SIP usage. Note
that I do not say, "deviate from MIME." I would suggest we NOT try to
deviate from MIME in any respect.
Oh MIME sage, your comment is inscrutable! :-)
I don't understand in this case where the line is between "adding value"
and "deviating".
If we try to ascribe some common meaning to "render" then I believe sip
is already violating it. If we have thus already "deviated" from MIME,
which takes precedence: correcting the deviation, or backward compatibility.
My assumption is that backward compatibility is more important.
Paul
On 7/19/07 9:59 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
[snip]
I think we just have to grandfather the use of 'refer' in SIP, and
document that the usage in sip does not mean "render", but rather means
that the usage must be determined by other context - specifically the
type of message or response and the content type. IOW, 'render' in sip
can be thought of as a peculiar spelling for 'by-context'. It might be
helpful to give guidance for development of future specs about when
'render' should be used vs defining a new disposition.
[snip]
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and have
received this message in error, please immediately return this by email and
then delete it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
