Re: R: R: a question about IETF draft location conveyance 09

RFC 2119 language aims to accomplish interoperability.
The MUST NOT in that sentence does not accomplish
interoperability.
It does not do harm for the proxy to still read it.

I would be fine with a sentence that indicates that it is
not useful for 
the proxy to read the location information if the recipient
parameter is 
set to "endpoint".

Ciao
Hannes

daniel grotti wrote:
> Hi all,
> so why don't emphasize this point in the next draft,
saying : "Proxy server MUST not read messages with
"recipient=endpoint" paramenter setted".
> This is my point of you.
>
> What do you think? James?
>
> Regards,
> Daniel
>
> ----------------------------------
>        Daniel  Grotti
> D.E.I.S. - University of Bologna
> ----------------------------------
>        Via Venezia, 52
>   47023 Cesena (FC) - ITALY
> ----------------------------------
> e-mail: daniel.grottiunibo.it
> ---------------------------------- 
>
>
>
> -----Messaggio originale-----
> Da: Hannes Tschofenig [mailto:Hannes.Tschofeniggmx.net]
> Inviato: gio 22/11/2007 18.35
> A: daniel grotti
> Cc: Ted Hardie; James M. Polk; IETF SIP List
> Oggetto: Re: R: [Sip] a question about IETF draft
location conveyance 09
>  
> Hi Daniel,
>
> daniel grotti wrote:
>   
>> I believe that if a UA puts
"recipient=routing-entity" paramenter into
locationValue, the location information should be read only
by Proxy Server for location-based routing. 
>> But if a UA wants its own location information to
be known and seen by endusers, then UA have to insert the
"recipient=endpoints" paramenter. In this case
Proxy server, from my view, should only forward the message
to the destination. UA would just like to bring its own
location to an endpoint, and    could not interested in
location-based routing.
>>
>> Does this make sense?
>>
>>   
>>     
>
> Correct and makes sense.
>
> The recipient parameter is just a hint for processing.
It does not have 
> security properties.
>
> Ciao
> Hannes
>
>
>
>   
>> Regards,
>> Daniel
>>
>>
>>
>>
>> -----------------------------
>>        Daniel  Grotti
>> DEIS - Universita' di Bologna
>> -----------------------------
>>        Via Venezia, 52
>>   47023 Cesena (FC) - ITALY
>> -----------------------------
>> email:daniel.grottiunibo.it
>> ----------------------------- 
>>
>>
>>
>> -----Messaggio originale-----
>> Da: Ted Hardie [mailto:hardiequalcomm.com]
>> Inviato: gio 11/22/2007 12:36
>> A: James M. Polk; daniel grotti; IETF SIP List
>> Oggetto: Re: [Sip] a question about IETF draft
location conveyance 09
>>  
>> At 4:18 PM -0600 11/21/07, James M. Polk wrote:
>>   
>>     
>>> 
>>> Ted -- This header parameter is for a PIDF-LO,
yes -- but it pertains to the SIP WG's expertise in knowing
and agreeing with SIP's ability to foresee the type of
topology from UAC to UAS, and each server (whether there
even is one) in between.  I'm not so sure the SIP WG agrees
that a UAC can make this determination, and am soliciting
their input here in a broad way.
>>>
>>> Can a UAC understand enough about the topology
of the Internet to understand where it is sending a request,
including how SIP servers may or may not act upon that
request?
>>>
>>> I believe, if the answer is no, the the
"recipient=" parameter is a flawed SIP header
parameter.
>>>
>>> If the answer is yes, then it stays with no
further arguments from me.
>>>     
>>>       
>> I think we have fundamentally different ideas of
how much understanding of the
>> topology this implies.  My view is that the header
as currently specified says
>> either "This is meant for the person answering
the call/taking the session" or
>> "This is meant to help get the call
through/get the session to the right responder".
>> Within the latter case, it requires no knowledge at
all of topology; it does
>> not distinguish among the many different routing
elements which might be
>> trying to make that happen. 
>>
>> A UA that does not care whether it is used for
routing can enter "both"
>> and all is well.  A UA that *wants* it to be used
this way can enter "routing-entity".
>> The availability of "endpoint" as a
separate possibility makes sure that
>> an endpoint can indicate that use by the routing
system is not intended. 
>> If the SIP community believes
"routing-entity" is too vague
>> and needs to be broken out, I do not see how the
GeoPRIV could object or
>> why it would want to; certainly this working group
should have the final word
>> on that.  But collapsing things so that entering
"endpoint" is
>> not an indicator to the routing entities that they
should just pass things along
>> would find opposition (at the very least from me). 
That would break a pretty
>> fundamental assumption that users are in control of
the pidf-lo distributions.
>>
>> Hope you have a great Thanksgiving,
>> 				Ted
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
>>   
>>     
>
>   

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Re: R: R: a question about IETF draft location conveyance 09

Thread: Re: R: R: a question about IETF draft location conveyance 09