![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
christian - i'd like to understand any technical concerns you might have on the the "soap over beep" specification. in reading your note, i think i found one, specifically how the "soap over beep" specification will interact with the not-yet-existent soap routing specification. if that's the case, then i'd have to say that it will work no worse than the "soap over http" mapping: 1. if all the routing information is carried in the envelope, then neither mapping will have a problem. 2. if the routing information is entirely out-of-band, it is a non-issue for both mappings. 3. if the routing thing requires some incompatible change, then we'll use feature negotiation to deal with it (which should make lloyd wood happy). (this third choice is something not in the "soap over http" mapping, so hopefully whoever does the soap routing specification will be sensitive to that.) if there are other technical issues, let me know. i think that the specification got scrubbed pretty well over the last three months, but i'm certainly happy to hear otherwise. /mtr
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.