As a reasonably neutral observer, I would conclude
that the IETF was an appropriate venue, and it is understandable
that this particular standard did not conveniently fall under
the purview of an existing working group (or merit the creation
of a separate working group).
(And yes, "reasonably neutral observer" in this case
can appropriately be interpreted as "someone who
knows little about the content and therefore comments
about the process". OK, back to versioning and acl's,
where I should be spending my time :-).
Cheers,
Geoff
-----Original Message-----
From: Patrik Fältström [mailto:paf(_at_)cisco(_dot_)com]
Sent: Monday, September 10, 2001 4:58 PM
To: Christian Huitema; ned(_dot_)freed(_at_)mrochek(_dot_)com; Scott Brim
Cc: ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: Using SOAP in BEEP to Proposed Standard
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
<huitema(_at_)windows(_dot_)microsoft(_dot_)com>
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