RE: Allowing sip: in location header not good

I think that ship has sailed.  PIDF-LO is precisely defined in presence, and
we don't need any documents that further describe how location is conveyed
in a presence subscription.  All this document would do is describe how you
might go about specifying a presence uri that would be a little less general
(provide less information) than the one you would get by using the "From:"
URI.  The ruleset for this presence uri would be different from the more
general uri.  

Now, it does occur to me that if we allow sip/sips/pres, then we have a
minimal resolution protocol for location by reference.  It might be then
acceptable to drop the whole raw GET idea completely, and leave that to the
L7 protocol.  I kind of like that idea, because the raw GET is really
defining a whole new protocol and I don't think we want to, or need to, do
that in this document.  We brought it up because without at least a minimal
dereference solution, the mechanism does not meet the requirements.  A
presence subscription would do that, with no need for more.

And if we do that, we could drop the resolution-protocol parameter and
registry, because sip/sips/pres doesn't need it.

Brian

> -----Original Message-----
> From: Thomson, Martin [mailto:[email protected]]
> Sent: Thursday, July 20, 2006 7:56 PM
> To: James M. Polk; Brian Rosen; [email protected]; [email protected]
> Subject: RE: [Sip] Allowing sip: in location header not good
> 
> I don't think that you need to preclude the use of SIP here, but there are
> a lot of things that need to be considered before SUB/NOT are allowed.
> 
> That is to say - the location conveyance document doesn't cover its use,
> and nothing else does...yet.  When someone does a using-protocol
> specification for SUB/NOT, then we have a place to describe how to use
> sip[s]: in the Location header.
> 
> Fact is - I don't think that we have ANY using-protocol defined, hence the
> problems we are having in deciding what goes in the header.
> 
> 
> >                  (and I'm not so sure about 'pres')
> 
> A pres: URI is in effect a sip[s]: URI for these purposes.
> 
> 
> Cheers,
> Martin
> --------------------------------------------------------------------------
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------------------
> ----------------------
> [mf2]


_______________________________________________
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