[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] WSS SwA profile Issue 364 - close
|
I agree with Dana S. Kaufman VP of Product Management Forum Systems, Inc. Tel: (781) 788-4232 E-Mail: dkaufman@forumsys.com Visit http://www.forumsys.com From:
Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] Brian I believe draft 17 reflects the current TC
opinion regarding conveying XML attachments. I outlined the rationale for this
on the TC call and there was agreement on the call. I think it is an overstatement to say that
this means XML cannot be conveyed in attachments. First of all, TC members
informed me that most implementations would not be expected to process the XML
in attachments (unless intended at the application layer), so this should not
be an issue for these implementations. For those implementations that find this
an issue, it is possible to encode the attachment so it is not processed (e.g.
base64). As noted in the document, many do not want to require the overhead
of canonicalization and I believe there was strong opinion on this point. As editor I will rely on the direction of
the TC, which I believe has been clear. If the TC believes a vote is necessary,
I would request a motion that "The TC adopt the resolution to issue 364 as
provided in draft 17 of the SwA profile". I would like to request that TC members
review this issue in advance of the next WSS meeting on 3 May so that it may be
closed at that meeting. Please send any discussion to the WSS list in advance
so that the TC can make an informed decision. regards, From: ext Brian
LaMacchia [mailto:bal@exchange.microsoft.com] Hi Frederick, I haven’t seen any substantive
discussion of Issue 364 on the mailing list, nor in the minutes of the bi-weekly
conference calls, so I am somewhat surprised by the TC’s reversal on this
issue as reflected in Draft 17. It seems to me that the language in Draft
17 makes the situation worse – it basically says that unless the node
constructing the message has direct knowledge of the processing behavior of
every intermediate node, XML attachments cannot be attached and transported as
XML. Working under this model, a general-purpose WSS SwA message construction
library would have to assume that an intermediary *might* be XML-aware and thus, by default, encode all XML
attachments into some opaque format. Note also that because no *specific* encoding format is required for
encapsulated XML attachments, it will be impossible for smart intermediaries
that have knowledge about the “XML safeness” of their downstream
links to decode the encoded XML attachments. This essentially pushes XML
attachment decoding to the ultimate receiving endpoint. Are details of the TC’s reasoning
behind the decision to reject XML canonicalization for signed XML attachments
available anywhere? I continue to believe that WSS SwA has a problem if
it does not require XML canonicalization of XML attachments and that the
language in Draft 16 was the proper way to resolve Issue 364. Thanks,
--bal P.S. I note that in the minutes of the
04/19/2005 conference call that John Weiland just sent out, Issue 364 is listed
as having been closed during the call. I assume that, given your e-mail
of this morning, the minutes are in error and the Issue remains “pending
review”. From:
Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] I believe issue 364 should be closed [1]. It was marked
pending at the meeting before last (5 April) and was resolved by reverting to
the approach of the Committee Draft, ie. that attachments are not to be XML
canonicalized. I have received no additional feedback since 5 April, so I
believe this can be closed on the next call. If this incorrect please send an email to WSS list before
the next call. regards, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]