Eric Burger wrote:
<I-still-hate-XML-but-fine-to-make-a-point>
:-)
I hate it too - not in the abstract, but in the way it has become the
solution to all problems. IMO it is ok as an extensible, interoperable,
program-to-program representation of complex structured data. But it is
not a programming language, or suitable as a user interface, and people
should not have to write it.
Going a step further: if SIP goes beyond the standard MIME processing, I
would offer that rather than use the hammer of the 1990's (MIME), we move to
the hammer of the 2000's (XML).
Perhaps if we were starting off to do SIP/3.0 (no I'm not suggesting
that we do that), it might make sense to use XML rather than MIME.
Given where we are, I don't think it makes sense to use XML rather than
MIME to represent multiple independent body parts in a request.
We are *already* defining most new body parts in XML, and making them
extensible so that they can contain other XML things. But I wouldn't go
out of my way to start redefining mime-type as XML just so they can be
incorporated into other XML things.
Paul
:-))
</I-still-hate-XML-but-fine-to-make-a-point>
On 5/30/07 4:53 AM, "Gonzalo Camarillo" <[EMAIL PROTECTED]>
wrote:
Hi,
what Keith says makes sense. I believe mandating support for multipart
in SIP is a SIP-specific problem. Mandating suppport for
multipart/alternative is also a SIP-specific problem, since a
SIP-specific problem such as the transition to new session description
formats depends on that.
However, specifying if an implementation that supports multipart should
support nested body parts or not is something more general on which the
email folks have a lot of experience.
Cheers,
Gonzalo
DRAGE, Keith (Keith) wrote:
Well, at the moment, what I am trying to do is get some understanding of
what we should scope as valid SIP work.
We need to be able to understand why something that is clearly a generic
problem for specification of nested MIME bodies merits a SIP specific
solution.
So:
- is a generic solution already documented elsewhere?
- if a generic solution is not documented elsewhere, should one be
documented, rather than a specific SIP solution?
Regards
Keith
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 8:52 AM
To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat
Cc: [email protected]
Subject: RE: [Sip] MIME: Nested bodies with option-tag?
Hi Keith,
Once we get down to a decision of supporting nested versus not
supporting nesting, presumably we are then entirely in the
realm of the
multipart coding itself.
Could I ask someone to elaborate on what generic
requirements already
exist within multipart/mime in this respect, before we start
looking at
defining SIP specific rules or indications?
I am very sure that I have seen text related to the support
of nested multiparts, and what nodes are expected to support,
somewhere, but I yet have not found it.
Regards,
Christer
Regards
Keith
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 2:47 PM
To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat
Cc: [email protected]
Subject: RE: [Sip] MIME: Nested bodies with option-tag?
Hi,
My main concern is not what wording (SHALL, MUST, etc) we use.
The issue is that I think we need text saying what
implementations
that DO NOT support alternative and/or nested shall do. If
we say that
they shall reject the message I believe that many of the existing
implementations will be compliant with the spec.
And, if we give the possibility to simply reject the message, I
believe it will be easier to get people to change their
implementations, if they currently simply discard
alternative and/or
nested today.
Regards,
Christer
-----Original Message-----
From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED]
Sent: 29. toukokuuta 2007 16:06
To: Paul Kyzivat
Cc: Christer Holmberg (JO/LMF); [email protected]
Subject: Re: [Sip] MIME: Nested bodies with option-tag?
Hi,
what I am hearing is that there are implementations out
there that
support multipart but not nested. Therefore, we need to
decide two
things:
1) do we want to have a MUST for multipart and a SHOULD for
nested? I
would say that we should have the same level (e.g., MUST, if we
decided that MUST is appropriate) for both.
2) do we need a way for implementations that support
multipart but not
nested to be quickly updated to, at least, report that
fact with an
error response? This may make sense.
Cheers,
Gonzalo
Paul Kyzivat wrote:
More or less repeating what I said before:
I expect we do have to account in some way for
implementations that
have already been deployed, in absence of a
clarifying document.
Exactly how we deal with that is still TBD.
But as we define what is required to support this in the
future, I
think there is *no* benefit to defining two levels of
support - full
and partial. Anybody that sets out to provide support
for this
document should be expected to do it all - its not that
much harder.
Paul
Christer Holmberg (JO/LMF) wrote:
Hi,
I wonder whether we should define an option-tag for the
support of
nested bodies.
I don't think there's a lot to be gained from
defining such an
option-tag. The sender should already be aware that
there is a risk
the recipient can't understand nested bodies, and have
arranged for
suitable fallbacks. Conversely, the recipient should (at
least) be
able to skip the nested multipart body part in the proper
"I don't
understand this body part" way. All an option-tag would
do is allow
the sender to not add a fallback.
In that case we need some specific text saying that if the
receiver
does not support nested multiparts it MUST
do-this-and-do-that.
Because, as I said earlier, I don't think we will
achieve what we
want by saying that one MUST be able to parse nested
multiparts. It
can be rather tricky to implement (depending on how the
parser is
implemented, though), and since there aren't really any
use-cases out
there yet I am pretty sure some people will choose not to
implement
it (and saying that people are not compliant in that
case will not
really help from an interop perspective). So, because of
that I think
it would be good not to mandate the support of nested
multiparts, but
to mandate appropriate behavior if not supported - just
like in any
other case when a MIME body contains an unsupported but
required content type.
Regards,
Christer
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
