Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] echoBase64

Expand Messages
  • Andrew Layman
    If one is using the datatypes defined by XML Schemas March 30, 2001, then the rules of those datatypes apply, not the commentary in the SOAP specification
    Message 1 of 13 , Apr 26, 2001
    • 0 Attachment
      If one is using the datatypes defined by XML Schemas March 30, 2001, then
      the rules of those datatypes apply, not the commentary in the SOAP
      specification which was describing earlier and unfinished schema types. The
      XML Schemas specification description of base64Binary refers to RFC 2045,
      which in turn says


      Table 1: The Base64 Alphabet

      Value Encoding Value Encoding Value Encoding Value Encoding
      0 A 17 R 34 i 51 z
      1 B 18 S 35 j 52 0
      2 C 19 T 36 k 53 1
      3 D 20 U 37 l 54 2
      4 E 21 V 38 m 55 3
      5 F 22 W 39 n 56 4
      6 G 23 X 40 o 57 5
      7 H 24 Y 41 p 58 6
      8 I 25 Z 42 q 59 7
      9 J 26 a 43 r 60 8
      10 K 27 b 44 s 61 9
      11 L 28 c 45 t 62 +
      12 M 29 d 46 u 63 /
      13 N 30 e 47 v
      14 O 31 f 48 w (pad) =
      15 P 32 g 49 x
      16 Q 33 h 50 y

      The encoded output stream must be represented in lines of no more
      than 76 characters each. All line breaks or other characters not
      found in Table 1 must be ignored by decoding software.

      See http://www.ietf.org/rfc/rfc2045.txt, section 6.8.

      It is pretty clear that white space and any other non-table-1 character
      should be ignored during parsing.

      What I am not sure of, since RFC 2045 was written in the context of MIME
      representation, is whether the 76-character restriction applies to
      xsd:base64Binary. I've copied the editors of the schema specification for
      clarification.

      ----- Original Message -----
      From: "Rich Salz" <rsalz@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Thursday, April 26, 2001 6:48 PM
      Subject: Re: [soapbuilders] echoBase64


      > I took the sentence "However, the line length restrictions that normally
      > apply to base64 data in MIME do not apply in SOAP" to mean that when
      > serializing out base64 you don't have to worry about wrapping, and so it
      > should be one long string. but i can see how that might not be the
      meaning.

      I took it to read "you MAY send one long line, but it is not a MUST that
      you do so."

      I'd recommend that at least linebreaks be ignored, probably
      linebreak-whitespace is best, but ignoring all whitespace is okay.
      /r$

      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Paul Kulchenko
      Hi, David! Agree. SOAP::Lite ignores whitespaces in base64 encoded elements. I ve also added support for sparse arrays (in my understanding ALL elements should
      Message 2 of 13 , Apr 26, 2001
      • 0 Attachment
        Hi, David!

        Agree. SOAP::Lite ignores whitespaces in base64 encoded elements.

        I've also added support for sparse arrays (in my understanding ALL
        elements should be tagged with position attribute; order doesn't
        matter; works for single dimension only), so interop endpoint will
        work with sparse, multidimensional and partial arrays.

        Best wishes, Paul.

        --- David Crowley <dcrowley@...> wrote:
        >
        >
        > I did some digging.
        >
        > Quote from the XML schema on whitespace collapse:
        > replace
        > All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage
        > return) are
        > replaced with #x20 (space)
        > collapse
        > After the processing implied by replace, contiguous sequences of
        > #x20's are
        > collapsed to a single #x20, and leading and trailing #x20's are
        > removed.
        > NOTE: The notation #xA used here (and elsewhere in this
        > specification)
        > represents the Universal Character Set (UCS) code point hexadecimal
        > A (line
        > feed), which is denoted by U+000A. This notation is to be
        > distinguished
        > from
        , which is the XML character reference to that same UCS
        > code point.
        >
        > Here's a quote from RFC2045:
        > The encoded output stream must be represented in lines of no more
        > than 76
        > characters each. All line breaks or other characters not found in
        > Table 1
        > must be ignored by decoding software. In base64 data, characters
        > other than
        > those in Table 1, line breaks, and other white space probably
        > indicate a
        > transmission error, about which a warning message or even a message
        >
        > rejection might be appropriate under some circumstances.
        >
        > What applies most is "All line breaks or other characters not found
        > in
        > Table 1 must be ignored by decoding software."
        >
        > So as far as I can tell, whitespace (at least space, tab, line
        > feed,carriage return) should be allowed anytime, anywhere in base64
        > :)
        >
        > David
        >
        >
        > At 02:20 PM 4/26/2001, you wrote:
        > >I think trailing and leading whitespace is ok, but not in the
        > middle
        > >
        > >-----Original Message-----
        > >From: David Crowley [mailto:dcrowley@...]
        > >Sent: Thursday, April 26, 2001 2:18 PM
        > >To: soapbuilders@yahoogroups.com
        > >Subject: Re: [soapbuilders] echoBase64
        > >
        > >
        > >
        > >Well, the example in section 5.2.3 shows at least leading and
        > trailing
        > >whitespace... I don't see a reason to specifically disallow
        > whitespace. I
        > >would think the implementations would be more robust if whitespace
        > were
        > >just ignored.
        > >
        > >
        > >At 02:08 PM 4/26/2001, you wrote:
        > > >Hi, David!
        > > >
        > > >I don't believe it's valid. While it might be properly decoded
        > in
        > > >MIME message, in my opinion any whitespace inside this element
        > should
        > > >be avoided.
        > > >
        > > >Best wishes, Paul.
        > > >
        > > >--- David Crowley <dcrowley@...> wrote:
        > > > >
        > > > > I've been trying out echoBase64 (type SOAP-ENC:base64) with a
        > few
        > > > > implementations and have run across a couple problems. The
        > base64
        > > > > string I
        > > > > am sending contains whitespace. The SOAP spec says the
        > base64 type
        > > > > isn't
        > > > > subject to the line length restrictions in base64 for MIME.
        > 4s4c
        > > > > looks
        > > > > like it only transforms the test to binary up to the first
        > non
        > > > > base64 char
        > > > > or whitespace char and then stops. the MStk and MS.net
        > endpoints
        > > > > complain
        > > > > about the string length not being appropriate for a base64
        > string,
        > > > > etc. I
        > > > > am assuming it's valid to have whitespace in this value, it's
        > just
        > > > > not
        > > > > required. Thoughts? Here's a sample envelope I'm sending:
        > > > >
        > > > >
        > > > > <V:Envelope
        > > > > xmlns:V="http://schemas.xmlsoap.org/soap/envelope/"
        > > > > xmlns:C="http://schemas.xmlsoap.org/soap/encoding/"
        > > > > xmlns:i="http://www.w3.org/1999/XMLSchema-instance"
        > > > > xmlns:d="http://www.w3.org/1999/XMLSchema"
        > > > >
        > V:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        > > > > <V:Body>
        > > > > <m:echoBase64
        > > > > xmlns:m="http://soapinterop.org/">
        > > > > <inputBase64
        > > > >
        > > > >
        > >
        >
        >i:type="C:base64">nDYVZdjG1gh6fxVTwm05Y2o14aU2WRw9zLjcqcZUqKEGWJJCSVppbP/dL
        > >2lbGs3P
        > > > >
        > pgAGp9h5qs5p7wycZQ+1xL/MWnvnpwzdni6vjArDrZoFn+ypuxf9UHQdlsGuCUKp
        > > > >
        > b5pXWNk3KCL/e30F9/FAjDEcefIGu32LlEphYMrMtRm/yG8hSJImBMnLgRxLK+5s
        > > > >
        > z36XzOLtkkdyf1fB4OB43FZgjB1bPmxLpSejGC76HwSKzi19dzakS7bEXysZy/G6
        > > > >
        > 3mmVlTvFZL86lstDx+U7GgcTIk7sHRtgBx9h6J0Xinv87HLRD691JzEg4eM/dKp3
        > > > >
        > 8VVgh2orX04NmkY+k0uq5lrwCxkAggZNMc3NQb0v1ePunc5wGObY3XE89HYj8LjF
        > > > >
        > oH1ItTbIgffjpnelap8iJabyVFEf2O7U2w1U13eNHt52mxHs2AhN7u6yx1ZuS/oH
        > > > >
        > w1zacaaJCv3yFk6rtKpD+YJTTggPy9L6/PqmnvC7xk/q40gZ1oCSHl9eyzgF0I/g
        > > > >
        > b6znTwKYeOKyhPrDGHjsxsWQhpHXRfAAyu2xyJCFalrjr8QK2vencLparQ4PCdY0
        > > > >
        > /Gp9IdBgimvZzOqhfVQ8LoZjzYC+cMdqvISlx/326mE3eRMR6VrKJzcCXAv1wm0l
        > > > >
        > AtDr+9eMQJlfCMw2CsiSFB3GMahMuRf7ipfxUCBZZQf8/g==</inputBase64>
        > > > > </m:echoBase64>
        > > > > </V:Body>
        > > > > </V:Envelope>
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > To unsubscribe from this group, send an email to:
        > > > > soapbuilders-unsubscribe@yahoogroups.com
        > > > >
        > > > >
        > > > >
        > > > > Your use of Yahoo! Groups is subject to
        > > > > http://docs.yahoo.com/info/terms/
        > > > >
        > > > >
        > > >
        > > >
        > > >__________________________________________________
        > > >Do You Yahoo!?
        > > >Yahoo! Auctions - buy the things you want at great prices
        > > >http://auctions.yahoo.com/
        > > >
        > > >To unsubscribe from this group, send an email to:
        > > >soapbuilders-unsubscribe@yahoogroups.com
        > > >
        > > >
        > > >
        > > >Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        > >
        > >
        > >
        > >To unsubscribe from this group, send an email to:
        > >soapbuilders-unsubscribe@yahoogroups.com
        > >
        > >
        > >
        > >Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        > >
        > >
        > >To unsubscribe from this group, send an email to:
        > >soapbuilders-unsubscribe@yahoogroups.com
        > >
        > >
        > >
        > >Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        === message truncated ===


        __________________________________________________
        Do You Yahoo!?
        Yahoo! Auctions - buy the things you want at great prices
        http://auctions.yahoo.com/
      • Andrew Layman
        RFC 2045 says that, on generation, the base64 output stream must have a line break every 76 or fewer characters. It also says that, on input, line break and
        Message 3 of 13 , Apr 30, 2001
        • 0 Attachment
          RFC 2045 says that, on generation, the base64 output stream must have a
          line break every 76 or fewer characters. It also says that, on input,
          line break and other non-base64 characters must be ignored.

          Our question pertains to the first statement, that is, to generation.
          Does the lexical form of a base64Binary value require a line break every
          76 or fewer characters?

          -----Original Message-----
          From: Ashok Malhotra
          Sent: Monday, April 30, 2001 9:55 AM
          To: Andrew Layman
          Cc: 'soapbuilders@yahoogroups.com'; Biron,Paul V
          Subject: RE: [soapbuilders] echoBase64


          I'm confused by the following paragraph in the mail below:
          > The encoded output stream must be represented in lines of no more
          > than 76 characters each. All line breaks or other characters not
          > found in Table 1 must be ignored by decoding software.

          Does this mean that line breaks must appear at 76 characters or
          less but will be ignored by the decoding software as they are not
          in the table above? In that case it does not matter if they appear
          or not!

          As I said in a previous message, the potential problem that I see
          is that if the white space facet was set to "replace"
          it will replace line breaks with spaces and cause problems with the 76
          character line requirement.

          We can ask Schema to fix this in an erratum.

          All the best, Ashok
          ===========================================================
          Ashok Malhotra <mailto: ashokma@...>
          Microsoft Corporation
          212 Hessian Hills Road
          Croton-On-Hudson, NY 10520 USA
          Redmond: 425-703-9462 New York: 914-271-6477


          -----Original Message-----
          From: Andrew Layman [mailto:yahoo@...]
          Sent: Thursday, April 26, 2001 7:59 PM
          To: soapbuilders@yahoogroups.com
          Cc: Paul.V.Biron@...; Ashok Malhotra
          Subject: Re: [soapbuilders] echoBase64


          If one is using the datatypes defined by XML Schemas March 30, 2001,
          then the rules of those datatypes apply, not the commentary in the SOAP
          specification which was describing earlier and unfinished schema types.
          The XML Schemas specification description of base64Binary refers to RFC
          2045, which in turn says


          Table 1: The Base64 Alphabet

          Value Encoding Value Encoding Value Encoding Value Encoding
          0 A 17 R 34 i 51 z
          1 B 18 S 35 j 52 0
          2 C 19 T 36 k 53 1
          3 D 20 U 37 l 54 2
          4 E 21 V 38 m 55 3
          5 F 22 W 39 n 56 4
          6 G 23 X 40 o 57 5
          7 H 24 Y 41 p 58 6
          8 I 25 Z 42 q 59 7
          9 J 26 a 43 r 60 8
          10 K 27 b 44 s 61 9
          11 L 28 c 45 t 62 +
          12 M 29 d 46 u 63 /
          13 N 30 e 47 v
          14 O 31 f 48 w (pad) =
          15 P 32 g 49 x
          16 Q 33 h 50 y

          The encoded output stream must be represented in lines of no more
          than 76 characters each. All line breaks or other characters not
          found in Table 1 must be ignored by decoding software.

          See http://www.ietf.org/rfc/rfc2045.txt, section 6.8.

          It is pretty clear that white space and any other non-table-1 character
          should be ignored during parsing.

          What I am not sure of, since RFC 2045 was written in the context of MIME
          representation, is whether the 76-character restriction applies to
          xsd:base64Binary. I've copied the editors of the schema specification
          for clarification.

          ----- Original Message -----
          From: "Rich Salz" <rsalz@...>
          To: <soapbuilders@yahoogroups.com>
          Sent: Thursday, April 26, 2001 6:48 PM
          Subject: Re: [soapbuilders] echoBase64


          > I took the sentence "However, the line length restrictions that
          > normally apply to base64 data in MIME do not apply in SOAP" to mean
          > that when serializing out base64 you don't have to worry about
          > wrapping, and so it should be one long string. but i can see how that
          > might not be the
          meaning.

          I took it to read "you MAY send one long line, but it is not a MUST that
          you do so."

          I'd recommend that at least linebreaks be ignored, probably
          linebreak-whitespace is best, but ignoring all whitespace is okay. /r$

          To unsubscribe from this group, send an email to:
          soapbuilders-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/





          To unsubscribe from this group, send an email to:
          soapbuilders-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
        • blm@halcyon.com
          ... I would say yes, as it just says it s based on RFC 2045. However, I would say that any server that checks that was being overly pedantic. Brian
          Message 4 of 13 , Apr 30, 2001
          • 0 Attachment
            |Our question pertains to the first statement, that is, to generation.
            |Does the lexical form of a base64Binary value require a line break every
            |76 or fewer characters?

            I would say yes, as it just says it's based on RFC 2045. However, I would
            say that any server that checks that was being overly pedantic.

            Brian
          Your message has been successfully submitted and would be delivered to recipients shortly.