Subject: [Geopriv] Your suggestions regarding draft-ietf-geopriv-dhcp-lbyr-uri-option-00

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 May 2008 23:40:04 +0300

Hi Lisa,

a few days ago I reviewed draft-ietf-geopriv-dhcp-lbyr-uri-option-00 
again and I was wondering about 2 things:
* the need to register URI schemes. I suggested not to register them at 
all.
* the missing URI scheme that makes use of HELD dereferencing (see HELD 
draft)

Why do you think that these restrictions make sense for the document?

Ciao
Hannes

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 May 2008 16:10:51 -0500

>* the missing URI scheme that makes use of HELD dereferencing (see HELD

BTW - Hannes (yeah, I got it right this time), wouldn't HELD be the 
only protocol used, which makes relying upon, or necessitating DHCP 
conformance to the HTTPS-URI registration a non-issue?

In other words, why would DHCP return a HELD scheme URI (HTTPS-URI) 
instead of HELD returning the HELD scheme URI (HTTPS-URI)?  Why would 
DHCP be used in this case?  I really don't believe it would be.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 19 May 2008 15:35:50 -0700

On May 19, 2008, at 1:40 PM, Hannes Tschofenig wrote:

> * the need to register URI schemes. I suggested not to register them  
> at all.
> * the missing URI scheme that makes use of HELD dereferencing (see  
> HELD draft)
>

I think I know what issue you're referring to: I've seen  
interoperability problems in other protocols when fields can contain  
absolutely any kind of URI and yet the URI is expected to have some  
consistent meaning ( not just an identifier).  The stellar example of  
this is the PHOTO field in VCARD.  Since I was doing an early review  
of the LbyR stuff, I pointed out this general issue appeared in LbyR  
as well.

There are number of ways of solving this general issue.  The most  
common approach is to restrict the field to certain well-known URI  
schemes -- and possibly even to restrict the content types or other  
"features" of the URI appearing in the field.  E.g. to fix the photo  
issue in VCard, one might require the field to contain http or https  
URIs only, and these URIs, if successfully dereferenced, MUST return  
image/jpg or image/png content types.

I checked the draft to see how James proposes to resolve this issue,  
and it now talks about creating a registry for acceptable location-URI  
types.  Since the registry can only be extended through a Standards  
Track RFC, this doesn't do much for making it easier to add acceptable  
location-URI types than simply updating the document that defines the  
DHC option in the first place -- but it does make it easier to find  
the list in one place.   	While I'm doing a partial re-review, I'd  
like to point out that the registry alone still leaves a lot of  
potential scope for problems.  Can the registry be supplemented by  
some information about what features the SIP end point appearing in a  
Location URI will support?  SIP is turning into a generic URI scheme  
like HTTP, it might be a person, it might be a phone, it might be a  
list, it might be a service.    It may be that this is already covered  
but I have missed it.

OK, so that's some of the context, but now I'm a little at a loss as  
to what specific stuff in the draft you think should be different, and  
why James thinks it can't be different because of AD requirements.

Can you be more specific what you propose?  Do you propose that there  
be no registry?  Do you propose some other way of dealing with the  
interoperability pitfalls here?

thx,
Lisa