Re: [Geopriv] Teasing apart: constraints on dereference URI

At 10:25 AM 7/27/2006 -0400, Andrew Newton wrote:
>There have been many conversations regarding constraining the URI in the 
>Location header.  There have been many positions taken on this subject, 
>and this email is intended to understand the various opinions.
>
>Is there anybody who believes that the type of URI in the Location header 
>should not be constrained in any way?  In other words, any URI scheme may 
>be valid and there should be no attempt to specify the URI scheme or 
>associated protocol for dereferencing location.  And if so, do you believe 
>location will only be dereferenced via a user clicking on a link or by 
>automatic software action?  If the latter, how do you see software 
>adapting to multiple URI schemes and their associated protocols?
>
>Is there anybody who believes that the dereference URI should be 
>restricted to a specific set of schemes, enforced via ABNF, XML Schema, or 
>other grammar specification and re-enforced with MUST/SHOULD 
>language?  The intent here being that the set would be definitive or at 
>the very least require major effort to update.

Andy - I vote for the scheme be defined within the using protocol's 
(general) area.

For example, if a SIP document defines SIP and a Geopriv using protocol, 
then it should define one or more schemas near SIP (SIP, SIMPLE, 
MMUSIC).  This does result in sip/sips/pres/cid being in the SIP using 
protocol doc.

If there were an HTTP document promoting HTTP being a Geopriv using 
protocol, that document should be the one defining HTTP area schemas, 
meaning http/https.

and so on for other protocols


>Finally, how many people desire a middle ground?  Perhaps where the ABNF, 
>XML Schema or other grammar specification allows for any URI scheme but 
>there is an IANA registry listing the allowed dereference URI schemes and 
>associated protocols?

I think any IANA Registry here will point back to a Standards Track RFC 
that defined the usage and semantics, which your question is not 
allowing.  Therefore, for what you have immediately above, I disagree.


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip