As the Area Director which is taking care of this draft, I must comment on
this thread.
First of all, I agree completely with what is said by my co-ad Ned in
regards of "what organization do what".
Secondly, moving individual submissions onto Standards Track is perfectly
alright, and done quite often.
What we do though is normally to use a 4-week last call, and not a 2-week
last call. Further, I personally as AD always verify the document and see
that the document have been discussed in appropriate areas.
Now, let's look at the comments by Christian below (the rest of the issues
raised by others, such as the issue with naming convention by using URL's
are sorted out I think).
The draft itself specifies from my point of view how to run Soap over Beep.
This doesn't prohibit other specifications of how to run Soap over foo, or
Soap over bar. I.e. this is not _the_ way of moving Soap over the Internet.
It is about how to move Soap over Beep.
Because it _only_ talks about doing Soap over Beep, the important issue was
that this document have been reviewed in beep community. This I found was
ok as the document has been known on the beep mailing list.
About cooperation with W3C, all documents we in the IETF find is in a gray
area between IETF and W3C are discussed in the meetings that our respective
liaisons have. That is the path for move of information between the two
organizations.
After finding a few issues with the document, and having the document
updated once, I agreed issuing a last call.
All comments are input to the IESG decision which will happen after the
last call ends.
Last, about Soap over TCP, well, that is probably not something we in Apps
Area like. Beep solves an important problem we have, which is abstraction
of the transport layer, so things end up being "nicer" to TCP. Remember all
discussions a year or two ago about a generic application layer protocol?
Beep in the current incarnation might not be what we talked about _then_,
but it solves a need that we have today. And noone have come up with
anything better.
It's certainly better (from an architectural standpoint) than HTTP
regarding "generic protocol for transport of application layer messages".
HTTP is today extremely complicated, and just that should scare people away
which doesn't work with traditional "web related things".
Yes, I might exaggerate, but sometimes I find I have to just to get peoples
brains start moving a bit :-)
paf
--On 01-09-10 10.34 -0700 Christian Huitema <[EMAIL PROTECTED]>
wrote:
>> SOAP is going to see widespread use no matter what. The other
>> application
>> transport for SOAP is HTTP. Use of HTTP for things it isn't well
>> suited for is
>> something we want to discourage. So doing this correctly is of
>> considerable
>> concern to the application layer.
>
> It is true that HTTP is the only transport defined in the SOAP
> specification, but SOAP can be mapped to a variety of transports,
> including direct mapping over TCP or UDP. Do we really believe that
> carrying SOAP over BEEP is better than carrying it over TCP? Did we even
> discuss that? Did we get some form of requirement from the WG defining
> the XML protocol in the W3C? How can we define a mapping to BEEP
> channels without even considering the potential requirements for
> multi-step forwarding of SOAP messages across various transports? What
> is the relation with SOAP extensions to handle such forwarding, that are
> currently debated in the W3C?
>
> I don't think it is a good idea for the IETF to issue a proposed
> standard on how to transport SOAP over the Internet without first having
> an organized discussion of what the transport should be, and without a
> well defined cooperation with the W3C -- unless indeed our intent is to
> maximize confusion. An individual draft such as draft-etal-beep-soap-04
> should not be published as an RFC, let alone a proposed standard,
> without first chartering a working group on the general issue of
> transporting SOAP.
>
> -- Christian Huitema
>
