Subject: [Simple] Re: MSRP URLs

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Oct 2004 16:26:35 -0500

On Sep 21, 2004, at 5:17 AM, Miguel Garcia wrote:

> Hi:
>
> A few comments about section 5 of the MSRP draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-simple-message- 
> sessions-08.txt
>
> 1) The draft should describe the type of resources that are identified  
> by an MSRP URL. So I would suggest to add an introductory paragraph at  
> the beginning of section 5 that says something on the following lines:
>
>    The MSRP and MSRPS URL schemes are used to designate a session of
>    instant messages at a particular host computer.
>
>   Question: is this definition also applicable to relays?
>

I think if we say at a particular MSRP device, then it applies to both  
relays and endpoints. Or more precisely, it describes either an MSRP  
service, or an MSRP session hosted at a particular service.

> 2) RFC 2396 is under revision, nowadays  
> draft-fielding-uri-rfc2396bis-06.txt. I am not sure if you still want  
> to refer to RFC 2396 or the revision of it. I guess this depends of  
> which draft makes it first to the IESG.
>
> Among other things, in case you want to refer to rfc2396bis, this  
> draft has removed the definition of "hostport". Now it is just "host  
> [: port]"

Does anyone know the status of 2396bis? I want to avoid all the  
normative references to works in progress that we can. There are too  
many hoops to jump as it is.

>
> 3) The current definition of an MSRP URL includes a "resource" part,  
> when actually it is a "path" or "session-id", because a "resource" is  
> the the whole MSRP URL, including the URI scheme and the hostname.
>
> So I would suggest to replace the current definition:
>
>     MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/"
>       resource] ";" transport
>       resource = 1*unreserved
>
> with this other one:
>
>     MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/"
>       path] ";" transport
>       resource = 1*unreserved

I am okay with "sessionid" or "session". I don't like path, as I think  
it implies things we don't mean. On the other hand, does resource  
conflict with something in the abnf? It's just a variable name, and it  
does not seem useful to get too bogged down in the semantic meaning of  
abnf identifier choices.

>
> 4) According to rfc2396bis, "unrerved" is defined as:
>
> unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
>
> On purpose "unreserved" does not include "sub-delims", which is  
> defined as:
>
>     sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
>                   / "*" / "+" / "," / ";" / "="
>
> I guess it is OK for MSRP that the path is formed of unreserved  
> characters, not including sub-delims. But I would like to point this  
> out in case someone feels the path needs to include sub-delims.

If I recall correctly, we consciously chose to use unreserved on all of  
this to avoid escaping. Does anyone see a requirement to use other  
characters here than cannot be achieved with unreserved characters?

>
> 5) I find a contradiction that we, on one hand, allow to have a  
> "userinfo" part in the MSRP URL including a reference to RFC 2396, and  
> on the other hand we restrict the "userinfo" definition in RFC 23964  
> to unreserved characters.
>
> RFC 2396 (and 2396bis) allow to have escaped characters in the  
> userinfo. However, MSRP does not, but still refers to 2396 for the  
> definition of userinfo.
>
> So, if the "userinfo" defined in the MSRP URL is different from (or a  
> subset of) the "userinfo" defined in RFC 2396, then I would suggest to  
> change the name (perhaps "unescaped-userinfo"), and avoid the  
> reference to RFC 2396.
>

Again, I don't think we want to bring in unescaped characters unless   
we find a problem with not allowing them. But I am okay with changing  
the construction name.

> 6) Section 5.1 reads on the second bullet point:
>
>    2.  If the hostpart contains an eplicit IP address, and/or port,
>        these are compared numerically.  Otherwise, hostpart is compared
>        as a case insensitive character string.
>
> I was wondering in the how to treat zeros in either IPv4 or IPv6 (IPv6  
> uses this quite oftenly). The missleading word is "numerically", since  
> I am not sure if the "::" should be normalized by adding trailing and  
> leading zeros or not.
>
> Is it the intention that the following two URLs are equivalent and  
> MSRP endpoints should detect it?
>
>    msrp://[1080:0:0:0:8:800:200C:417A]/aodisfa;tcp
>    msrp://[1080::8:800:200C:417A]/aodisfa;tcp
>
> A clarification should be written.
>

I don't know enough about IPv6 to address that. Are the two addresses  
equivalent? We had a suggestion to try to avoid treating URLS  
differently if they had the same address with slight encoding  
differences. But if this becomes a complex issue, I propose we just go  
back to a text comparison.

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

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

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 02 Oct 2004 12:07:46 +0300

Ben:

Thanks for the reply. Inline comments.

Ben Campbell wrote:
>> 1) The draft should describe the type of resources that are 
>> identified  by an MSRP URL. So I would suggest to add an introductory 
>> paragraph at  the beginning of section 5 that says something on the 
>> following lines:
>>

Good definition, I like it.

> many hoops to jump as it is.

The I-D tracker indicates that this draft is currently under IESG 
evaluation, heading towards standard track RFC. Ted Hardie is the 
shepherding AD. Maybe you want to ask advice from Ted.

> does not seem useful to get too bogged down in the semantic meaning of  

I don't think "resource" conflicts with anything in the ABNF, it is just 
a missleading term, as well as "path" as you suggested. I would be happy 
to go for "session" or "sessionid".

> characters here than cannot be achieved with unreserved characters?

I don't have such requirement. I just wanted to check that was a 
decision taken on purpose, not an oversight.

>> "userinfo" part in the MSRP URL including a reference to RFC 2396, 
>> and  on the other hand we restrict the "userinfo" definition in RFC 
>> 23964  to unreserved characters.
>>
>> subset of) the "userinfo" defined in RFC 2396, then I would suggest 
>> to  change the name (perhaps "unescaped-userinfo"), and avoid the  
>> reference to RFC 2396.
>>
> 

ok

>> I was wondering in the how to treat zeros in either IPv4 or IPv6 
>> (IPv6  uses this quite oftenly). The missleading word is 
>> "numerically", since  I am not sure if the "::" should be normalized 
>> by adding trailing and  leading zeros or not.
>>

At least in IPv6 the examples above represent the same IPv6 address. RFC 
3513 indicates the three forms to represent an IPv6 address. I guess 
there should be a discussion on the equivalency of this kind of addresses.

- Miguel

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Oct 2004 08:21:06 +0200

> there should be a discussion on the equivalency of this kind of addresses.

My read is that the text "compared numerically" was meant to imply that
1080:0:0:0:8:800:200C:417A does match 1080::8:800:200C:417A - we should
clarify