headers
Rosen, Brian | 1 Aug 2006 01:01
Favicon

RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined

Sure, and so does: "Any URI can be used".  That isn't necessarily a good
thing.

If the text is like the "this document describes how you use
sip/sips/pres" then the ABNF I suggested is more appropriate.

Any ABNF can be significantly reduced if the only thing you are trying
to convey with it is strict syntactic compliance.  No significant
document with large hunks of ABNF in the IETF does that.  We almost
always try to make the ABNF show as much of the semantic meaning as is
reasonable.  If you follow the SIP threads, there are several messages a
month whose answer starts:
"you can't look at the ABNF alone, you have to read the text".  To me,
this is a document failure, unless the ABNF was has to be so ugly to be
completely correct it fails to communicate.  Alas, that happens.  But if
it is possible to simply communicate the semantics in the ABNF, then it
is appropriate to do so.

You can use the "token" construction a whole lot more than we do if all
you want is syntax checking.

Lots of examples in 3261:
Priority        =  "Priority" HCOLON priority-value
priority-value  =  "emergency" / "urgent" / "normal"
                   / "non-urgent" / other-priority
other-priority  =  token

Contact        =  ("Contact" / "m" ) HCOLON
                  ( STAR / (contact-param *(COMMA contact-param)))
contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Winterbottom, James | 1 Aug 2006 01:08

RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined

Brian,

So the two things are linked then?

It is my belief that the consensus is in favour of what Henning suggested, and that is what I would like.
Perhaps you would like to include precisely that position in your next quest for consensus, rather than
trying to re-word it and losing the intent.

Cheers
James

________________________________

From: Rosen, Brian [mailto:Brian.Rosen <at> neustar.biz]
Sent: Mon 31/07/2006 6:01 PM
To: Dawson, Martin; Winterbottom, James; IETF SIP List
Cc: GEOPRIV
Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does Location-Conveyance have an
HTTP dereferencemechanism defined

Sure, and so does: "Any URI can be used".  That isn't necessarily a good
thing.

If the text is like the "this document describes how you use
sip/sips/pres" then the ABNF I suggested is more appropriate.

Any ABNF can be significantly reduced if the only thing you are trying
to convey with it is strict syntactic compliance.  No significant
document with large hunks of ABNF in the IETF does that.  We almost
always try to make the ABNF show as much of the semantic meaning as is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Rosen | 1 Aug 2006 01:24

RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined

No James, the two threads are not linked.  The first asks if there is any
reference to HTTP use in dereferencing.  The other discusses what the text,
and the resulting ABNF says about dereferencing in general.

Note in the message below, the token "http" does not appear, yet the text is
readable.

IF we were to include an http based dereferencing protocol in location
conveyance AND we were to have a more semantically correct ABNF, THEN you
would see HTTP in the list of protocols.  However, you can answer the
questions independently without any problem.

Henning said we should not syntactically limit the ABNF.  The "more
specific" ABNF directly addresses that concern, and Jeroen's concern about
diagnostics by including AbsoluteURI as an alternative.  I'm bowing to list
consensus on strictly limiting the ABNF.  

Let's get back to the question, which in this thread is "what does the text
say about what can appear in the Location URI?"

Brian

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom <at> andrew.com]
> Sent: Monday, July 31, 2006 7:09 PM
> To: Rosen, Brian; Dawson, Martin; IETF SIP List
> Cc: GEOPRIV
> Subject: RE: [Geopriv] URI restrictions in location conveyance,was Does
> Location-Conveyance have an HTTP dereferencemechanism defined
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Newton | 1 Aug 2006 03:03
Picon

Re: RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined


On Jul 31, 2006, at 6:19 PM, Winterbottom, James wrote:

> Not true
>
> "> This is NOT the discussion of what the ABNF of the location header
> looks
>> like (although it would NOT have http/https in it for sure if we  
>> agree
>> that an HTTP dereference protocol is a separate draft)."
>
> This is a discussion on ABNF and what the document contains, and to  
> that extent they are not separable.
> The consensus has been, do not restrict the ABNF, keep the  
> discussion in the document about references limited. I am failing  
> to understand why you can't accept that.

Brian is right.  They are not the same issue, atleast they do not  
have to be.

 From where I sit, I think the consensus is:
   - do not constrain the ABNF
   - HTTP goes in another document

Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP document.

-andy

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
(Continue reading)

Permalink | Reply | 0 comments |
headers
Winterbottom, James | 1 Aug 2006 03:11

RE: RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined

Hi Andy,

That is all I have asked for, do not constrain the ABNF. If "how I use HTTP as a reference" goes in a different
document that is fine providing the ABNF is not constrained in the conveyance specification. This is not
how I read Brian's statement below:

"This is NOT the discussion of what the ABNF of the location header looks
like (although it would NOT have http/https in it for sure if we agree
that an HTTP dereference protocol is a separate draft)."

Which to me clearly says the ABNF will be restrict to exclude HTTP/HTTPS if there is agreement that the
conveyance draft doesn't have specific text on how to deference an HTTP reference.

Cheers
James

________________________________

From: Andrew Newton [mailto:andy <at> hxr.us]
Sent: Mon 31/07/2006 8:03 PM
To: Winterbottom, James
Cc: Rosen, Brian; IETF SIP List; GEOPRIV
Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined

On Jul 31, 2006, at 6:19 PM, Winterbottom, James wrote:

> Not true
>
> "> This is NOT the discussion of what the ABNF of the location header
> looks
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Newton | 1 Aug 2006 03:14
Picon

Re: RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined


On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote:

> Hi Andy,
>
> That is all I have asked for, do not constrain the ABNF. If "how I  
> use HTTP as a reference" goes in a different document that is fine  
> providing the ABNF is not constrained in the conveyance  
> specification. This is not how I read Brian's statement below:
>
> "This is NOT the discussion of what the ABNF of the location header  
> looks
> like (although it would NOT have http/https in it for sure if we agree
> that an HTTP dereference protocol is a separate draft)."
>
> Which to me clearly says the ABNF will be restrict to exclude HTTP/ 
> HTTPS if there is agreement that the conveyance draft doesn't have  
> specific text on how to deference an HTTP reference.
>
> Cheers
> James

Please keep in mind that this does not stop the draft from using MUST/ 
SHOULD language from stipulating "the URI MUST be a GEOPRIV standards  
track using protocol."

-andy

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dawson, Martin | 1 Aug 2006 07:14

RE: RE: [Geopriv] Does Location-Conveyance have an HTTPdereferencemechanism defined

I'm OK as long as the ABNF includes the AbsoluteURI option and the text
does not say anything specifically about excluding HTTP (or any other
form of URI).

I've attempted to point out previously that the URI doesn't actually
convey anything about whether the geopriv rules are going to be
respected or not. It's actually a geopriv rule that those rules be
respected so it's superfluous, and out of scope, to also require the
statement in a SIP conveyance document.

AbsoluteURI as a generic form, encompasses sip etc. anyway, so it's also
superfluous to include those in the ABNF. However, it's also a harmless
waste of space. If Brian is keen to include them for some reason, and as
long as neither the text nor the ABNF bias the specification toward
those forms in any way, then there are certainly better things to lose
sleep over.

Cheers,
Martin

> -----Original Message-----
> From: Andrew Newton [mailto:andy <at> hxr.us]
> Sent: Tuesday, 1 August 2006 11:15 AM
> To: Winterbottom, James
> Cc: IETF SIP List; Rosen, Brian; GEOPRIV
> Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an
> HTTPdereferencemechanism defined
> 
> 
> On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jesske, R | 1 Aug 2006 07:25

AW: updated acr code draft

In this Draft is described that:
The request contained a Privacy header field whose value was 'id'
      [3] or 'user'.  This explicitly excludes the 'header' and
      'session' privacy services, since those do not directly convey the
      identity of the requestor.

Why the value 'header ' is exluded? 

In RFC3323 is described that header:
      header: The user requests that a privacy service obscure those
      headers which cannot be completely expunged of identifying
      information without the assistance of intermediaries (such as Via
      and Contact).  Also, no unnecessary headers should be added by the
      service that might reveal personal information about the
      originator of the request.

So from my understanding 'id' is a subset of 'header' because the P-Asserted-Identity can only be deleted
by untermediarities.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com] 
Gesendet: Montag, 31. Juli 2006 22:31
An: IETF SIP List
Betreff: [Sip] updated acr code draft

I've submitted a minor update to the ACR code draft. Until it appears,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cullen Jennings | 1 Aug 2006 07:59
Picon
Favicon
Gravatar

Re: Comments on rosenberg-sip-identity-coexistence


Keep in mind a B2BUA always breaks end to end security because the  
B2BUA is the end. If C is only a proxy and does not have a b2bua,  
everything seems to work find between B and D. I think I am missing  
what the problem is here. I perfectly willing to believe there is a  
problem - I just think that I am not clear yet on the scenario you  
are thinking about.

Cullen

On Jul 11, 2006, at 10:42 PM, Hadriel Kaplan wrote:

>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffy <at> cisco.com]
>>
>> Ok, I am done't think I am manging to explaim myself. Say A has a
>> contract with B and B has a crontract with C. Now a call arrives at
>> C, it seem that C wants a assertion to be made by B. Anything A says
>> to C is clsoe to useless because C has no clue who A even is. I guese
>> I feel like we need to sort out the requirements for what we want in
>> a transit case and then we might be able to figure out a solution.
>
> One of the problems with the idea of a b2bua re-signing it is how  
> to trust
> the b2bua.  I.e., if the domain the b2bua is in is not the same as the
> From's, then you have to somehow trust the different domain.  I  
> agree with
> you there's a common model of "I trust the domain connected to me  
> directly".
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cullen Jennings | 1 Aug 2006 07:59
Picon
Favicon
Gravatar

Re: draft-ietf-sip-outbound and STUN keepalives


Yep - I think the intention was to do as Jonathan said.

On Jul 21, 2006, at 11:19 AM, Jonathan Rosenberg wrote:

> Right. I mentioned this in the behave meeting. The idea is that  
> rfc3489bis formally defines the usage, and calls out additional  
> things that an actual protocol that uses it, would have to say.  
> Then sip-outbound says those things.
>
> -Jonathan R.
>
> Christer Holmberg (JO/LMF) wrote:
>
>> Hi Keith,
>> I am ok with the proposal.
>> In the "STUN keep-alive: Where to document it?" thread (http:// 
>> www1.ietf.org/mail-archive/web/sip/current/msg15227.html) it is  
>> discussed where different things related to STUN keep-alive should  
>> be documented. Some things MAY have to be documented in 3489bis.
>> Regards,
>> Christer
>>  -----Original Message-----
>> From: Drage, Keith (Keith) [mailto:drage <at> lucent.com] Sent: 20.  
>> heinäkuuta 2006 15:11
>> To: 'sip <at> ietf.org'
>> Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives
>> (As WG chair)
>> Previous mails on the SIP list have expressed the view that the  
>> STUN keepalive mechanism should be documented separately as it is
(Continue reading)

Permalink | Reply | 0 comments |

Gmane