Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00

From: "Mary Barnes" <[email-masked]>
Date: Fri, 2 Mar 2007 20:21:43 -0600

Hi Roni,

Thanks for the comments and I believe that your concerns have been reflected in the updated document (i.e., allowing users to join using SIP), per comments below [MB].  

Mary

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Sunday, December 03, 2006 9:15 AM
To: Lorenzo Miniero; [email-masked]
Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00

Hi,
I read the draft and my view is that the conference object identifier is an XCON entity, it may be used for defining the conference name (user part) for a signaling protocol like SIP but this is not mandatory. Even in the example the conference access using signaling may be done using a SIP URI or a Phone number.
The major purpose of the identifier is for the XCON conference object. I am not sre it saves something to have a pre-defined mapping since anyhow you list the conference call signaling access in the document itself.
[MB] We've clarified that the mapping proposal is an example or guideline for an implementation that chooses to do it that way, but it is not mandatory.  The text hopefully clarifies that users may join with SIP signaling and the the URI is required for the conferencing system (and needed by any user that wants to manipulate the conference object). [/MB]

Another point to consider is that the conference call signaling access (SIP URI, PSTN) may be the same for all conferences when using two stage dialing (IVR), it may get a unique identifier only after the conference is established but not when it is reserved. See RFC 4579 section 5.3 for such a flow for SIP systems. 
[MB] It is possible that some conferences will use the same blueprint or reservation (and thus the same XCON URI), but once the conference is active, there would be a unique XCON URI. [/MB]

Roni Even 

> -----Original Message-----
> From: Lorenzo Miniero [mailto:[email-masked]]
> Sent: Thursday, November 30, 2006 9:57 PM
> To: [email-masked]
> Subject: Re: [XCON] Feedback requested: draft-boulton-xcon-uri-00
> 
> Hi Mary,
> 
> > Per discussions at IETF-67, here's the reminder that we'd like feedback
> > on this draft:
> > http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt
> >
> > This document defines a URI scheme and syntax for the conference object
> > identifier, as defined in "A Framework and Data Model for Centralized
> > Conferencing".
> >
> > This identifier has been a fundamental concept in the XCON framework
> > from the beginning and seems quite necessary. I think this draft is
> > fairly complete and the identifier itself is already part of the data
> > model, as pointed out by Oscar.
> >
> > So, the questions would be how much more detail is necessary in this
> > document and can it be accepted as a WG document?
> >
> > Regards,
> > Mary
> >
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/xcon
> >
> 
> 
> I absolutely agree on the fact that such an identifier was needed in the
> framework, and I'm glad that it has been proposed. What I still don't
> understand after having the draft read, and I take advantage of this new
> draft proposal to repeat a question I made some weeks ago on this ML and
> got ignored: considering the conference joining matter, will this URI be
> directly used to join conferences using a message of the
> soon-to-come-CCP, or will only its unique token be used to compose
> signaling URIs to access conferences using the relative CSP (e.g.
> xcon:123@xxx --> sip:123@xxx)?
> I ask this since I consider the joining method matter very important in
> a framework that by definition will (should?) not depend upon a specific
> CSP for media, besides the fact that a running XCON conference could be
> text-only as well, which would make a CSP almost useless. I personally
> think (and I ask the opinion of you all about that) that it could very
> well be a message of the CCP, which would allow an user to join the
> conference as an 'abstract' object, with no set of resources accessed
> yet (e.g. still no audio/video/text/etc) until the user states its will
> to access one or more of them by means of the respective CSP (accessing
> the URIs as mapped in this draft), or with some resource always
> available by default upon joining (text, for example) and others that
> can be latterly requested and accessed.
> 
> Hope to hear from you soon, cheers,
> 
> Lorenzo
> 
> --
> Lorenzo Miniero, Junior Researcher
> Dipartimento di Informatica e Sistemistica
> Università degli Studi di Napoli "Federico II"
> Via Claudio 21 -- 80125 Napoli (Italy)
> Phone: +390817683821 - Fax: +390817683816
> Email: [email-masked]
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> 
> 
> 
> **************************************************************************
> **********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
> viruses.
> **************************************************************************
> **********
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 2 Mar 2007 20:21:52 -0600

Srivatsa,

Thanks for the feedback.  Detailed responses embedded below [MB]. 

Mary

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]] 
Sent: Wednesday, January 03, 2007 2:28 AM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00

Hi Mary and Chris,

Sorry for the late comments. Overall, the idea of having a separate
identifier to identify the conference object resource sounds useful. Was
there a reason for using a new scheme based URI instead of a simple
unique identifier? Some text in the introduction to make the motivation
clear would help. Also, do you foresee the XCON URI to be a routable
entity in the future? Perhaps some normative text there regarding its
use would be beneficial?

[MB] I'm not sure we've totally addressed your first concern in the
updated -01, but hopefully the updated document is more complete in
terms of clarifying the usage by the expanded text in section 6.   I
think the idea of using a URI is that it could be routable depending
upon a conferencing system implementation and it seems reasonable to use
a URI from that perspective.  I guess we could add a statement somewhere
in section 3 to explicit state this. [/MB]

More comments follow.

>From Section 3
  " Editors Note: Part of the extension to the Conference Package for
   XCON? "

[SS] The data model and conference package for XCON should have text
describing where an XCON URI may appear in the document. It's usage
should however be specified in this document, the framework and the
conference control protocol if I understand correctly.

[MB] Agreed - we've deleted that Editor's note. [/MB]

>From Section 3.1
"   The left hand side of the URI (to the left of the '@') represents
the
   unique token.  This token can be used by any protocol wishing to gain
   access to functionality associated with a specific conference object.
   For example, when used to construct a SIP INVITE request, the token
   would be used to populate the 'user' part of the SIP URI - as defined
   in RFC 3261[2].  The right hand side of the URI, as with any URI,
   provides domain level information ('example.com' in previous
   example).  So continuing the previous example, the SIP URI domain
   part would be equal to this domain information."

[SS] Is the above text implying that, given an XCON URI, a
client/implementation can construct an equivalent SIP URI by just
parsing out sections from the XCON URI and forming the SIP URI? I think
giving normative detail here with respect to the mapping is quite
unnecessary and may in fact cause inter-op issues (if implemented
incorrectly). Inclusion of these terms should not prevent an
implementation from using SIP URI's instead of XCON URI's all over the
place (in the data model) without breaking normative behavior, correct?

[MB] Hopefully, with the updated text this is clear that this mapping
isn't normative and it's an implementation detail as to how a
conferncing system logically maps things. [/MB]

Srivatsa.

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Thursday, November 30, 2006 9:25 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [XCON] Feedback requested: draft-boulton-xcon-uri-00
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 05 Mar 2007 12:14:21 +0100

Hi Mary,

> Hi Lorenzo,
> 
> Thanks for the feedback.  Hopefully, your concerns have been addressed in the updated document, per my comments below [MB].  If not, let us know.
> 
> Mary

I'm glad my doubts have helped you in improving the document.
My comment is inline [LM].

> [MB] I think it is possible to use this URI to directly join a conference (e.g., moderator sets up
> the conference and sends the URI in a link for others to join the conference).  Although, per Roni's comments the more normal case (at least initially) would be for users to join using one of the signaling protocols. Hopefully, the updated text reflects both options. [/MB]

[LM] Yes, I agree with you. About the mapping not to be mandatory, as 
Roni pointed out, I agree with him as well, but it should however be a 
recommended behaviour (i.e. a guideline, as the text correctly suggests) 
to avoid confusion and potential URI conflicts.

> [MB] I fully agree with what you're saying and hopefully you can agree that the updated document reflects this sort of functionality (e.g., the whole reservation concept matches this idea of an 'abstract' object if I understand correctly).  If not, please propose text so that we can ensure that it is clear [In my mind, it's infinitely clear based on the FW, but it's still possible we don't have 
> enough words in this document]. [/MB]

[LM] Yes, I've seen you've added a lot of text for this in the section 
regarding the conference object identifier creation and distribution, 
which I completely agree with. I think it will be even clearer as soon 
as your promising draft on the CCMP will progress. Until then, limiting 
the join matter exclusively to CSP is fine.

Cheers,
Lorenzo

Email: [email-masked]