BCP 56 gets a worse rap than it deserves.  It's quite right that with  
great power (the flexibility in HTTP) comes great danger.  We don't  
always define new ports and schemes for new applications transported  
over HTTP, but that's because convenience is trumping security  
caution in most of those cases.

The danger of arbitrary URLs and HTTP URLs in particular came up  
recently in SIEVE notifications, a case which I'll explain has some  
relevance for Geopriv scenarios.

In the SIEVE notification framework, an email can trigger a  
notification over some other protocol.  It would be useful if the  
notification had a link to the email that triggered it.  Then the  
client can jump straight from the notification to the important  
email.  Naturally, this will be a URL in the notification body or  
headers.

But what kind of URL?  It should not be a "mailto:" or "tel:" style  
URL because there's nothing sensible the client can do with that.  It  
should not be allowed to be a "data:" URL that contains the whole  
email, some script instructions, or arbitrary other crap which might  
even be dangerous if it were used too trustingly.  It should of  
course be allowed to be an IMAP or POP URL (in fact, we should  
recommend to clients that support these notifications that they be  
able to handle IMAP or POP URLs).

But what about HTTP or Web mail?  Can these notifications contain  
HTTP URLs which may be direct pointers to the triggering email?   
Since Web mail systems are so common of course this would be useful.   
Unfortunately, it's potentially one of the most dangerous kinds of  
URLs we commonly see.  Clicking on an HTTP URL can lead to 404 Not  
Found; even though "cool URLs don't change", many do in practice.  It  
can be useless because although it retrieves a resource, that  
resource is a MIME type like PDF or PNG that the client doesn't know  
what to do with.  It can lead to a fancy HTML page with frames and  
scripts and logos and buttons: again, a rich client doesn't know what  
to do with this so it gets handed off to a fully capable browser.   
Hello phishing platform -- a handy way for a phisher to draw a user  
neatly through a familiar process in which they provide their email  
password to an attacker.

Since Geopriv is also contemplating HTTP URLs, this will be a similar  
issue.  Perhaps Geopriv can do a little better because the resource  
to be found at a location URL has a better defined content type than  
non-standardized Web mail does.

In general:
  - Fields that can contain arbitrary URLs are bad for interoperability
  - Fields that can contain HTTP URLs without clear expectations on  
what kind of resource must be at the URL, can also be bad for  
interoperability
  - These can both be bad for security and privacy

Lisa


On Nov 4, 2007, at 8:22 AM, Hannes Tschofenig wrote:

> Yep; I think so too.
>
> I personally think it is much simpler not to change port numbers  
> even for non-Web browsing applications.
> However, I got the impression that these issues might come up  
> during IETF Last Call / IESG processing given that there is this  
> BCP document that talks about this subject.
>
> Ciao
> Hannes
>
>
> Cullen Jennings wrote:
>>
>> This was one of the topics where I think Lisa as a technical  
>> advisor for the group can come in very helpful.
>>
>> On Oct 28, 2007, at 7:22 AM, Hannes Tschofenig wrote:
>>
>>> RFC 3205 essentially says: If you use HTTP for things other than  
>>> webbrowsing then you should register a new URI scheme and use a  
>>> different port number.
>>>
>>> I was wondering what people think about that idea.
>>>
>>>
>>> Richard Barnes wrote:
>>>> It's also worth noting that RFC 3205 is just a set of  
>>>> recommendations, not anything binding.  Since the document  
>>>> doesn't make a general requirement for ALL http-based protocols  
>>>> to have a different URI scheme and port number, was there  
>>>> something in particular about HELD that led you to those  
>>>> requirements?
>>>>
>>>> We should probably have this same debate about LoST, although it  
>>>> may be mostly subsumed by previous discussions.  (Cross-posted  
>>>> to ECRIT)
>>>>
>>>> --RB
>>>>
>>>>
>>>>
>>>>
>>>> Hannes Tschofenig wrote:
>>>>> I have read RFC 3205 and my impression is that for HELD we have to
>>>>> * define a new URI scheme, and
>>>>> * use a different port number.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> PS: What is the value of WSDL in the HELD specification?
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv



_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv