Subject: [Uri-review] Request for Review of xcon and xcon-userid URI Schemes

From: Alan Johnston <[email-masked]>
Date: Mon, 01 Mar 2010 12:10:51 -0600

All,

On behalf of the Centralized Conferencing (XCON) Working Group, we
request review of the xcon and xcon-userid URI schemes.

For background on XCON, see:

     http://www.ietf.org/dyn/wg/charter/xcon-charter.html

The registration is defined in:

     http://www.ietf.org/id/draft-ietf-xcon-common-data-model-18.txt

which has completed WGLC but has not been publication requested yet.

Here is the registration information from the draft:

9.3. Conference Object Identifier Registration

  The IANA is requested to register the following URI scheme
  under the Permanent URI Schemes register.

 XCON-URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ]

  conf-object-id = 1*( unreserved / "+" / "=" / "/" )

  host, port, and unreserved are defined in RFC3986[RFC3986]

  Subject: Request for XCON-URI Registration
  Person & email address to contact for further information:
         Oscar Novo <oscar novo_at_ericsson.com>
  Specification: RFC XXXX
  Author/Change Controller: IESG
  Comments:     Identifies the Conference

9.4.  Conference User Identifier Registration

   The IANA is requested to register the following URI scheme
    under the Permanent URI Schemes register.

    XCON-USERID = "xcon-userid" ":" conf-user-id

    conf-user-id = 1*(unreserved)

   unreserved is defined in RFC3986[RFC3986]

    Subject: Request for XCON-USERID Registration
    Person & email address to contact for further information:
         Oscar Novo <oscar novo_at_ericsson.com>
    Specification: RFC XXXX
    Author/Change Controller: IESG
    Comments:
        Identifies the User in the conference

Thanks in advance!

- Alan -
co-chair XCON

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Mar 2010 11:51:09 -0800

Hi Alan,

Thanks for your note.  A quick read of the data-model document (and I
do mean quick!)
seems to indicate that at least one way in which these are generated
has a specific
form, the 32 bit identifier from the binary floor control protocol
(see section 4.5.1).  The
way that is written seems to indicate that there is 1:1 mapping
between that identifer
and the URI.  Am I right in thinking this is actually a 1:1 mapping to
conf-object-id rather
than the whole URI?  If so, re-phrasing might be useful.

Is there a general expectation of a limit to conf-object-ids?  The
current ABNF is unbounded
for size; is this the intent?

Also, I am a little curious about whether you have text somewhere on comparing
the URIs.  Since URIs may include encoded characters, the process of comparison
maybe a bit trickier that string comparison.  If, for example, "+" is encoded as
%43, will systems match a URI where it is not encoded?

regards,

Ted Hardie

On Mon, Mar 1, 2010 at 10:10 AM, Alan Johnston
<[email-masked]> wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Oscar Novo <[email-masked]>
Date: Tue, 2 Mar 2010 09:28:13 +0100

Hello Ted,

To get a better understanding of the XCON-URI/XCON-USERID identifiers, I recommend you to read section 3.3 for the XCON-URI and section 4.6.5 for the XCON-USERID. They are not too long sections.

The ABNF is expected to be unbounded.

Regarding the comparison of the URIs, we don't have any text for the comparison of the URIs. Is it fine if we add some text that force the identifiers to be only encoded identifiers?

Cheers,

Oscar

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: 1. maaliskuuta 2010 21:51
To: Alan Johnston
Cc: [email-masked]; Richard Barnes; [email-masked]
Subject: Re: [Uri-review] Request for Review of xcon and xcon-userid URI Schemes

Hi Alan,

Thanks for your note.  A quick read of the data-model document (and I do mean quick!) seems to indicate that at least one way in which these are generated has a specific form, the 32 bit identifier from the binary floor control protocol (see section 4.5.1).  The way that is written seems to indicate that there is 1:1 mapping between that identifer and the URI.  Am I right in thinking this is actually a 1:1 mapping to conf-object-id rather than the whole URI?  If so, re-phrasing might be useful.

Is there a general expectation of a limit to conf-object-ids?  The current ABNF is unbounded for size; is this the intent?

Also, I am a little curious about whether you have text somewhere on comparing the URIs.  Since URIs may include encoded characters, the process of comparison maybe a bit trickier that string comparison.  If, for example, "+" is encoded as %43, will systems match a URI where it is not encoded?

regards,

Ted Hardie