Subject: Re: [Ecrit] Re: [Geopriv] RFC 3205 & HELD

From: Cullen Jennings <[email-masked]>
Date: Sat, 3 Nov 2007 10:28:25 -0700

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
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 04 Nov 2007 17:22:29 +0100

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:
>>> 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:

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 8 Nov 2007 11:52:16 -0800

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.
>>
>>>> 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?
>>>>
>>>> may be mostly subsumed by previous discussions.  (Cross-posted  
>>>> to ECRIT)
>>>>
>>>> --RB
>>>>
>>>>
>>>>
>>>>
>>>> Hannes Tschofenig wrote:

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 9 Nov 2007 11:02:00 -0800

> PS: What is the value of WSDL in the HELD specification?

I always ask this question too and have yet to hear a good answer any  
time WSDL is proposed.  Just ran across James Snell's blog post  
(http://www.snellspace.com/wp/?p=798) today which backs up WSDL- 
skepticism with more experience:

"Those who are familiar with my history with IBM should know that I  
was once a *major* proponent of the WS-* approach. I was one of the  
original members of the IBM Emerging Technologies Toolkit team, I  
wrote so many articles on the subject during my first year with IBM  
that I was able to pay a down payment on my house without touching a  
dime of savings or regular paycheck, and I was involved in most of  
the internal efforts to design and prototype nearly all of the WS-*  
specifications. However, over the last two years I haven’t written a  
single line of code that has anything to do with WS-*. The reason for  
this change is simple: when I was working on WS-*, I never once  
worked on an application that solved a real business need. Everything  
I wrote back then were demos. Now that I’m working for IBM’s WebAhead  
group, building and supporting applications that are being used by  
tens of thousands of my fellow IBMers, I haven’t come across a single  
use case where WS-* would be a suitable fit."

And I'm even less optimistic about WSDL suitably solving a problem in  
a suite of standards protocols , than I am about it solving problems  
in enterprises with custom non-standard Web applications.

Lisa

---

From: "Mary Barnes" <[email-masked]>
Date: Sat, 10 Nov 2007 09:46:47 -0600

Hi Lisa,

I'm interpreting as a recommendation to remove the WSDL from the HELD
document.  If that's not the case, let me know, otherwise, I'll plan on
removing.

Mary. 

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 1:02 PM
To: Hannes Tschofenig
Cc: GEOPRIV
Subject: Re: [Geopriv] RFC 3205 & HELD

"Those who are familiar with my history with IBM should know that I was
once a *major* proponent of the WS-* approach. I was one of the original
members of the IBM Emerging Technologies Toolkit team, I wrote so many
articles on the subject during my first year with IBM that I was able to
pay a down payment on my house without touching a dime of savings or
regular paycheck, and I was involved in most of the internal efforts to
design and prototype nearly all of the WS-* specifications. However,
over the last two years I haven't written a single line of code that has
anything to do with WS-*. The reason for this change is simple: when I
was working on WS-*, I never once worked on an application that solved a
real business need. Everything I wrote back then were demos. Now that
I'm working for IBM's WebAhead group, building and supporting
applications that are being used by tens of thousands of my fellow
IBMers, I haven't come across a single use case where WS-* would be a
suitable fit."

And I'm even less optimistic about WSDL suitably solving a problem in a
suite of standards protocols , than I am about it solving problems in
enterprises with custom non-standard Web applications.

Lisa