Subject: RE: [AAA-WG]: AAA URI syntax

From: <[email-masked]>
Date: Wed, 3 Mar 2004 08:55:43 +0200

Hi, 

RFC 2396 also says that only some URI schemes use this
"generic URI" syntax; each scheme can decide whether
it wants to use it or not. If the AAA URI scheme
does not use the "generic URI" syntax, we can have
whatever we want right of the "aaa:" part...

So IMHO the current syntax is OK from this point.

BR,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Pete McCann
> Sent: Tuesday, March 02, 2004 9:00 AM
> To: [email-masked]
> Subject: [AAA-WG]: AAA URI syntax
> 
> 
> 
> 
> Hi,
> 
> Following up to the point I raised at the meeting today:
> 
> According to my reading of RFC 2396 (Uniform Resource Identifiers
> (URI): Generic Syntax), the syntax given for the AAA URI in RFC 3588
> is broken.
> 
> See Appendix A of 2396.  Because we are using a //, the thing after
> the slash is a "hier_part".  In a "hier_part", we have an "authority"
> followed by an optional "abs_path".  The only way to get a ";" "path" 
> is to use an "abs_path", and an "abs_path" must begin with a /.  In
> the examples given in RFC 3588, there is no / before the parameters.
> 
> So, there seem to be two options here.  We could remove the // from
> our URI syntax, making it into scheme:opaque_part.  We can format the
> opaque_part however we would like.  Alternatively, we could add a /
> after the authority name before we add parameters.  This would mean:
> 
>     aaa://host.example.com/;transport=tcp
> 
> This would be the least amount of change; however, it looks a 
> little ugly.
> 
> -Pete
> 
> p.s. Thanks to Adam Costello for first noticing this and 
> pointing it out.
> 
> -Pete
> 
> 
> 
> 
>

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Mar 2004 05:27:03 -0600

Hi, Pasi,

Where do you read that in 2396?  I see the following text in the
abstract:

   This document defines a grammar that is a superset of all valid URI,
   such that an implementation can parse the common components of a URI
   reference without knowing the scheme-specific requirements of every
   possible identifier type. 

I interpret that to mean that all valid URI must fit the grammar,
i.e., the set of all strings defined by the grammar is strictly larger
than the set of all valid URI.

The URI definition in RFC 3588 does not fit the grammar.

Our URI begins with "aaa://", so we are not eligible to parse it as
"<scheme>:<opaque_part>".  "<opaque_part>" cannot begin with a "/"

-Pete

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 03 Mar 2004 13:44:39 +0200

Hi:

As I understand from RFC 2396, those URIs that contain the slashes "//" 
include a path that points to a resource stored in a hierarchical 
structure, such us a file system. Obvious examples are http and ftp 
resources. Having said that, I don't believe a AAA URI falls into this 
category.

The other big category of URIs belong to those that do not point to a 
hierarchical resource. Example of these URIs are SIP and mailto: URIs. I 
believe the AAA URI belongs to this category. An example of what I 
believe it should be a correct AAA URI is:

        aaa:server.example.com

I know that my words suggest to do a big change to the AAA URI defined 
in RFC 3588, but we should make an effort to make things right.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Mar 2004 06:59:54 -0600

That would at least be legal syntax, but there are advantages to
re-using some of the hierarchical URI syntax.  See:

http://www.w3.org/DesignIssues/ModelConsequences

Adding a '/' to the end of our URI before the parameters doesn't seem
like a big deal.  IMAP URIs seem to work this way; see RFC 2192:

  4. IMAP server

     An IMAP URL referring to an IMAP server has the following form:

         imap://<iserver>/

     A program interpreting this URL would issue the standard set of
     commands it uses to present a view of the contents of an IMAP
     server.  This is likely to be semanticly equivalent to one of the
     following URLs:

         imap://<iserver>/;TYPE=LIST
         imap://<iserver>/;TYPE=LSUB

     The program interpreting this URL SHOULD use the LSUB form if it
     supports mailbox subscriptions.

(thanks again to Adam Costello for pointing these references out to me)

-Pete

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 04 Mar 2004 03:53:25 +0200

Hi Pete:

Thanks for pointing out to the document. I believe this document is 
designed by the W3C with the idea in mind of W3C applications.

I am not really convinced about your proposal. IMAP, HTTP and FTP have 
the need to express hierarchical resources. For instance, IMAP needs to 
specify a mailbox of a particular use, HTTP a web page, FTP a file.

I haven't found this requirement in AAA protocols. As far as I know, 
Diameter and Radius do not have the requirement to express a 
hierarchical  resource. We just need to express the host name.

There are plenty of URIs out there that follow this approach, I 
mentioned SIP, there is also h.323, tel, mailto. None of them need to 
express a hierarchical resource, so they use the "anything goes" model. 
Are those wrong? I don't think so. Can't they be parsed? I don't think so.

I am therefore advocating for making the AAA URI to follow a model that 
fits the requirements. As we don't have the requirement to point to a 
hierarchical resource, I believe we should follow the opaque ("anything 
goes") model.

    Miguel

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Mar 2004 20:16:51 -0600

Hi, Miguel,

It's ok with me if we adopt the opaque syntax, as long as we drop the
// and conform to the grammar.  However, I would just point out one
last thing to think about: in the aaa:// case, we are definitely
talking about a host name (or IP address) after the //.  In the other
examples you pointed out (sip, tel, mailto) I think we always have
something else more akin to an NAI or an e-mail address after the
":".  So, there might be some value in keeping the // so that tools
can parse the following string as a host name, in which case we need
the trailing "/".

-Pete

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 04 Mar 2004 04:23:11 +0200

Not in the TEL URL (RFC 2806, there is a revision coming as an Internet 
draft). Example: tel:+1-555-2222-3333

/Miguel

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Mar 2004 21:50:42 -0600

Right, it's not an NAI or an e-mail address, but a phone number.

My point was that these other examples do not have host names
following the ":".  Our aaa: scheme does.

-Pete

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 04 Mar 2004 05:58:03 +0200

We have. A SIP URI can contain either a domain name (example.com) or a 
host name (host.example.com). For instance, the following URIs are valid 
  SIP URIs:

  sip:[email-masked]
  sip:server.example.com

I see that the second example has a lot of similarities with the aaa uri.

     Miguel