Subject: [Sipping] draft-melanchuk-sipping-msml-00.txt

From: "Chris Boulton" <[email-masked]>
Date: Mon, 4 Aug 2003 10:43:44 +0100

Garland,Tim,
 
I finally had the opportunity to review the draft
'draft-melanchuk-sipping-msml-00.txt' - very impressive. This certainly
seems a flexible and powerful approach to media server control in
conjunction with 'draft-melanchuk-sipping-moml-00.txt'.  Please find
enclosed a couple of questions raised during my review as well as a
couple of minor 'nits'.
 
Questions
 
- Would any benefit be gained from including an optional 'order'
attribute on primitive elements so that when 'pipe' is used, the order
is determined explicitly rather than following a logical path?
 
- Was there a reason that JOIN/UNJOIN were limited to id1 + id2.  Could
it not have just been id, that was forced to appear at least twice?
This would allow you to join >2 media streams in one transaction.
 
- <result> element should say that the response code corresponds to the
SIP response code received for the transaction.
 
- P17 - Media objects may be defined using MOML or other suitable media 
   resource description languages. A media server which supports 
   <insert> and <remove> must support MOML and may support other 
   languages. Those languages must support the ability to identify the 
   left hand and right hand streams of full duplex objects.
Should this be a 'MUST' or is it not possible to only use another
'suitable media resource description language' with MSML?
 
Nits
 
From Abstract:-
Clients can use it define how media sessions interact on a media server
and to apply services to individual or groups of users.
Should read:-
Clients can use it to define how media sessions interact on a media
server and to apply services to individual or groups of users.
 
2.2 reads:-
Future references to that object must use that name in a structured
format as defined below.
Should:-
Make reference to explicit section/table.
 
2.2 reads:-
Terms may be either an object class or an object class followed by a
colon ':' followed by qualifier which identifies an object within the
class.
Should read:-
Terms may be either an object class or an object class followed by a
colon ':', followed by a qualifier which identifies an object within the
class.
 
2.2 reads:-
Dialogs contexts, and object instances of application defined classes,
have identifiers relative to a connection or conference.
Should read:-
Dialog contexts, and object instances of application defined classes,
have identifiers relative to a connection or conference.
 
4.0 reads:-
Transaction results are returned as part of the SIP request response.
Should read:-
Transaction results are returned as part of the SIP request/response
model.
 
The Document Footer reads:-
Media Sessions Markup Language (MOML)
Should read:-
Media Sessions Markup Language (MSML)
 
5.8 - The <dialogend> example does not have an id attribute BUT it is
mandatory.
 
A number of MAY, MUST etc have not been capitalised throughout the
document e.g. section 5.9. 

HTH,
 
Best Regards,
 
Chris.

------------------------------------------------
Chris Boulton
Ubiquity Software
 
Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601 
------------------------------------------------

---

From: Tim Melanchuk <[email-masked]>
Date: Wed, 06 Aug 2003 17:43:03 -0700

thanks for your review and comments! nits will be reflected in the
next revision. responses to questions are inline below.

cheers,
timm

Chris Boulton wrote:

 > - Would any benefit be gained from including an optional ‘order’
 > attribute on primitive elements so that when ‘pipe’ is used, the order
this question is related to MOML. the goal was to provide several simple
topology schemas to cover the common use cases. i think that explicit
control of topology (i.e. as in mpcp) may be useful. i'm not sure that
explicit ordering in this case would have benefit and may introduce
additional error cases. did you have any specific benefits in mind?

 > This would allow you to join >2 media streams in one transaction.
simplicity. msml already allows multiple <join> elements to be present
in a single transaction. allowing multiple streams to be identified in
a single join introduces more complexity and makes failure handling
more difficult.

 > SIP response code received for the transaction.
i'm not quite sure what you mean here. the response attribute in <result>
is for the msml transaction. it just happens to be carried in the response
to the sip message which conveyed the msml transaction. however msml is
designed to be neutral to the transport mechanism and this correlation
may not exist in all cases.

 > from MSML: Media objects may be defined using MOML or other suitable media
 >    languages.
 > Should this be a ‘MUST’ or is it not possible to only use another
 > ‘suitable media resource description language’ with MSML?
 >
a media resource description language is required. the "must" requires
that there be at least one common language to insure interoperability.
it does not preclude that other languages are supported.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP