Re: msrp and msrps URI scheme review

Reading through the definition, I am particularly concerned that we get
comments on the drafts' discussions of escaping.  As it stands now, the
draft says:

>
> If a userinfo component exists, it
>   MUST be constructed only from "unreserved" characters, to avoid a
>   need for escape processing.  Escaping MUST NOT be used in an MSRP
>   URI.  Furthermore, a userinfo part MUST NOT contain password
>   information.
>
>      The limitation of userinfo to unreserved characters is an
>      additional restriction to the userinfo definition in RFC3986.
>      That version allows reserved characters.  The additional
>      restriction is to avoid the need for escaping.
>
>   The following is an example of a typical MSRP URI:
>
>      msrp://host.example.com:8493/asfd34;tcp
>

RFC 3986 changed most instances of "escaped" to percent-encoded,
so it is probably better to use that language.    There are also a couple
of questions which come up.  RFC 3986 allows percent-encoding to be
used in reg-name,  so that it can be used to represent a host using
characters outside of the ASCII range:

  host        = IP-literal / IPv4address / reg-name
 reg-name    = *( unreserved / pct-encoded / sub-delims )

Does the MSRP spec intend to forbid this usage of percent encoding, as
well as that in the userinfo portion?

Further, the document is limiting the characters such that no characters
are used which would *require* percent encoding.  It is possible, however, to
apply percent encoding to unreserved characters.  I believe it may be
necessary to describe the appropriate behavior when encountering
a percent encoded character which is within the permitted range.

			regards,
				Ted Hardie

>We will be requesting registration of the msrp and msrps schemes
>defined in the following Internet Draft, section 15.5:
>
>http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-18.txt
>

>As part of the procedure, we are required to request a review for the
>schemes. Please review the schemes and send comments back to folk on
>the CC list no later than January 14th, 2007.
>
>I realise the the review overlaps with the holiday reason, but given
>that this protocol has
>been discussed within the IETF, the comment period requested may be
>sufficient if there is early positive feedback. If not, the review
>period can be extended.
>
>Looking forward to your comments.
>
>Thanks,
>Hisham Khartabil
>SIMPLE WG Co-chair

Received on Tuesday, 19 December 2006 20:00:47 UTC