Subject: [MEDIACTRL] Fw: AD review of draft-ietf-mediactrl-vxml

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 6 May 2008 12:06:41 -0500

Greetings,

Eric and I have received Jon's review comments for this draft, as follows. 
We encourage quick responses, so we can work through Jon's issues and move 
the draft forward.

Please respond onlist.

Thanks,

Spencer, as co-chair

----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 29, 2008 8:48 PM
Subject: AD review of draft-ietf-mediactrl-vxml

A few notes on this one.

The biggest point of contention here is obviously the fixed 'dialog'
user name. While I understand that this document follows the precedent
of RFC4240, that document is Informational and this is Standards Track.
I also understand that RFC4240 (Section 7) offers a critique of RFC3087
in defense of fixed user names. However, I'm not sure I find that
analysis complete, and thus I'm a bit uncomfortable that mediactrl-vxml
simply seems to accept the analysis of RFC4240 as having proven the case
and goes forward from there. I do think this requires a bit more
justification. The first sentence of the Security Considerations alludes
to one of these problems - and merely authenticate endpoint requests
does not completely answer that concern. Internationalization is another
concern I hear raised about standardizing user parts.

I'd be interested in hearing from the chairs on that first point, in
terms of how strong the consensus is in the working group for this.

In 1.1.4, expand the first use of CCXML.

I'm a little concerned that 2.1 is providing BNF for the sip and sips
URI schemes. Clearly BNF for those schemes is already given in RFC3261.
While providing BNF for the various parameters is appropriate, I'm less
sure about casting it as a 'dialog URL' or what have you; it comes
across as a profile of the sip/sips schemes.

The statement towards the end of 2.1 that

   Incorrectly formed requests MUST be rejected with the appropriate 4xx
   class response.

makes me a bit nervous. What is the appropriate 4xx class response if
the HTTP query to fetch the VoiceXML document leads to a 401 challenge
for which the media server has no password? What if the document exists
but is stale? The point is that if implementations are to send "the
appropriate 4xx class response" this document needs to say what they
are. The end of 2.2 has a couple of things along these lines, perhaps
more could live there.

In 2.4, the 'session.connection.protocol.sip.headers' - have you
verified that the format of this associative array is compatible with
the syntax of all possible SIP headers? The syntactical limitation
listed at the very end of the section strikes me as probably only one of
many.

In 6.2, right after the table

   The 405 Method Not Allowed response can be used by the AS to
   gracefully decline bridge transfers

I'm not sure what this means. Nor am I clear, in the proceeding table,
what the 405 response to INVITE is supposed to signify.

Overall, the Sec Cons has quite a bit of "you SHOULD do this" sort of
language and little "you MUST implement this" sort of language. I'm sure
the Security Area reviewers will be much more interested in what the
mandatory-to-implement protocol mechanisms are. If "the VoiceXML Media
Server SHOULD authenticate and authorize requesting endpoints," how does
it do that? What mandatory-to-implement authentication mechanisms does
it share in common with endpoints? How do they pre-establish
credentials? Etc.

Downref is noted.

Anyway, let me know your thoughts.

- J

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 7 May 2008 19:07:14 +0100

[Chris Boulton] As a person who has been involved with many product
combinations of App Server/Media Server interactions I strongly support
the use of RFC 4240 and its fixed strings - if for nothing else the
extensive amount of interoperability that it has historically produced
(yes - a shock I know - something the IETF produced that has been widely
adopted and has strong interoperability).  While I agree that it's may
not be 'true to form' in using fixed user names I simply see this as an
extension to an existing 'working' mechanism.  Yes, it maybe standards
track in the case of this draft but it merely acts as closure on 4240 -
which is widely used.  My personal view that that use of fixed names is
in no way harmful to the internet in general and should be accepted. 

Chris