Subject: [Simple] Message Sessions: msrp: URI issues

From: Adam Roach <[email-masked]>
Date: Mon, 7 Apr 2003 18:47:59 -0500

On the topic of DNS resolution: I would propose using
AAAA and A records for resolution of msrp URIs into IP
addresses. It might help to specify that multiple
A records returned for a name are tried at random,
and that a failure to connect to one will result
in an attempt to connect to another one selected
at random (and so on until the list is exhausted).

I would also propose that msrp URIs always include
port numbers. Keep in mind that msrp URIs aren't
typically meant for human consumption (except possibly
during device/software configuration -- procedures
typically performed exactly onec). Including port
numbers as mandatory saves you the trouble of
specifying comparison and resolution rules that
vary depending on the presence of a port. If it's
not there, the URI is simply invalid.

I'll further add that use of the
"scheme:userportion@hostportion:port" format makes
sense for SIP because we're addressing actual users.
In the msrp case, though, we're really talking about
a token identifying a resource. In particular,
the userportion doesn't really identify a user as
much as it does a session. For that type of setup,
I might propose that a more appropriate format
might be:

  msrp://relay.example.com:41234/cme304klA

That is:

  MSRP-URI = "msrp://" host ":" port "/" token

Or, if we want to allow simple password exchanges for
client authentication over TLS connections during BIND
operations:

  MSRP-URI = "msrp://" [ userinfo ] host ":" port "/" opaque-part

Given such a format, I would propose the following matching
rules:

- host is compared case-insensitive.
- opaque-part is compared case-sensitive.
- userinfo, if present, is not considered for matching.

  msrp://host.domain.tld:port/resource
         ^^^^^^^^^^^^^^^      ^^^^^^^^
         Case Insensitive     Case Sensitive

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Apr 2003 17:35:44 -0700

Hi Adam,
	You may not be aware that Roy Fielding is currently
working on an update to 2396, which is the current document
describing URI generic syntax.  You may want to review
his draft: draft-fielding-uri-rfc2396bis-01.txt, as it clarifies
a number of issues with the previous document.
	There is also a fairly long history around how to
react when you get multiple RRs back to a query in
the DNS.  I'd suggest starting with RFC 1794, which
has a good description of the ways in which the DNS
does and does not support predictive ordering. In general,
though, it's probably good to be aware that some systems
are configured to load balance by shifting the response
order.
				regards,
						Ted Hardie

---

From: Ben Campbell <[email-masked]>
Date: 07 Apr 2003 20:35:32 -0500

> not there, the URI is simply invalid.

The only concern I have is, as you mention, the endpoint configuration
case, where a user may have to tell the endpoint about a relay. There
might be some advantage here to allowing the endpoint to discover the
relay from the domain name, using a NAPTR/SRV/A series. Of course, that
seems rather heavy weight for use in session negotiation.

Thoughts from others?