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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 12:48:30 +0300

Sorry for my late response. Your mail got lost in my inbox.

I was trying to understand the interoperatiblity problems that may occur.

The case we have here is maybe a bit different:

The DHCP server returns one or more URIs. The DHCP client is quite often 
the one that does not dereference the URI.
The Location Recipient receives the URI(s) and it will then have to 
decide which URI it picks for derefencing.

I cannot see how a registr
Ciao
Hannes

Lisa Dusseault wrote:
>
> On May 19, 2008, at 1:40 PM, Hannes Tschofenig wrote:
>
>> 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?
>
> 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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jul 2008 12:49:20 +0300

I cannot see how a registry is going to help.

Ciao
Hannes