Subject: Re: [Simple] Re: MSRP URLs

From: Adam Roach <[email-masked]>
Date: Wed, 15 Dec 2004 13:49:55 -0600

Miguel Garcia wrote:

> Ben Campbell wrote:
>
>>>
>>> 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?
>
>
> I don't have such requirement. I just wanted to check that was a 
> decision taken on purpose, not an oversight.

The only thing I can think of that might make us want to reconsider this 
would be the fact that relays may choose to do some kind encoding of 
session state in the session identifier. One logical (and, for many 
environments, trivial) encoding of such identifiers would be using 
base64 -- which includes the "+", "/", and "=" characters. So, we may 
want to relax the restriction to '1*( unreserved / "+" / "=" / "/" )'. 
I'll note that we *do* want to make sure that ";" isn't valid in the 
session identifiers. On the other hand, implementors can simply take the 
suggestions from RFC3548 section 4 instead, in which case the only 
accommodation we would need to make is the equals sign.

/a

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Dec 2004 16:36:55 -0600

On Dec 15, 2004, at 1:49 PM, Adam Roach wrote:

> The only thing I can think of that might make us want to reconsider 
> this would be the fact that relays may choose to do some kind encoding 
> of session state in the session identifier. One logical (and, for many 
> session identifiers. On the other hand, implementors can simply take 
> the suggestions from RFC3548 section 4 instead, in which case the only 

considering that we treat the session identifier as opaque, it seems to 
me that the construction you describe would still not require escaping. 
Is this correct?

---

From: Adam Roach <[email-masked]>
Date: Fri, 17 Dec 2004 17:02:05 -0600

Ben Campbell wrote:

>> this would be the fact that relays may choose to do some kind 
>> encoding of session state in the session identifier. One logical 
>> (and, for many environments, trivial) encoding of such identifiers 
>> would be using base64 -- which includes the "+", "/", and "=" 
>> characters. So, we may want to relax the restriction to '1*( 
>> unreserved / "+" / "=" / "/" )'. I'll note that we *do* want to make 
>> sure that ";" isn't valid in the session identifiers. On the other 
>> hand, implementors can simply take the suggestions from RFC3548 
>> section 4 instead, in which case the only accommodation we would need 
>> to make is the equals sign.
>>
>
> considering that we treat the session identifier as opaque, it seems 
> to me that the construction you describe would still not require 
> escaping. Is this correct?

That is my understanding.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Dec 2004 13:00:13 -0800

I'm lost on this thread - do I need to got fix any text?

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 19 Dec 2004 09:15:21 -0800

Just fixed Rohan's email address on this thread - pleaser reply to this one.

---

From: Adam Roach <[email-masked]>
Date: Sun, 19 Dec 2004 13:36:51 -0600

>I'm lost on this thread - do I need to got fix any text?

Not in the relay draft, no. The only impacts I would see would be in the 
base draft. I assume that, if there are no objections, Ben will modify 
the list of allowed characters to include +, /, and =.

/a