Re: R: R: [Sip] a question about IETF draft location conveyance 09

["James M. Polk" <[e-mail]>]

At 01:27 PM 11/22/2007, Hannes Tschofenig wrote:
>RFC 2119 language aims to accomplish interoperability.
>The MUST NOT in that sentence does not accomplish interoperability.

which is one of my main points

>It does not do harm for the proxy to still read it.

I'm sure not everyone agrees with this


>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".

I have no problems writing this into the doc, if this is agreeable. 
Should something like, "and a LbyR URI (MUST NOT/SHOULD NOT) to be 
dereferenced"


>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: [e-mail]
>>----------------------------------
>>
>>
>>-----Messaggio originale-----
>>Da: Hannes Tschofenig [mailto:[e-mail]]
>>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:[e-mail]
>>>-----------------------------
>>>
>>>
>>>-----Messaggio originale-----
>>>Da: Ted Hardie [mailto:[e-mail]]
>>>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://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use [e-mail] for questions on current sip
>>>Use [e-mail] for new developments on the application of sip
>>>
>>>
>>
>>


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