RE: [Geopriv] URI restrictions in location conveyance, was Does Location-Conveyance have an HTTP dereferencemechanism defined
"Brian Rosen" <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]] > 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 > > 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:[email protected]] > 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 > 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) > name-addr = [ display-name ] LAQUOT addr-spec RAQUOT > addr-spec = SIP-URI / SIPS-URI / absoluteURI > > Let's settle on the words first. The ABNF will follow. > > Brian > > > -----Original Message----- > > From: Dawson, Martin [mailto:[email protected]] > > Sent: Monday, July 31, 2006 6:48 PM > > To: Rosen, Brian; Winterbottom, James; IETF SIP List > > Cc: GEOPRIV > > Subject: RE: [Geopriv] URI restrictions in location conveyance,was > Does > > Location-Conveyance have an HTTP dereferencemechanism defined > > > > Just using absoluteuri seems like the complete simplification... > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:[email protected]] > > > Sent: Tuesday, 1 August 2006 8:44 AM > > > To: Winterbottom, James; IETF SIP List > > > Cc: GEOPRIV > > > Subject: RE: [Geopriv] URI restrictions in location conveyance,was > > Does > > > Location-Conveyance have an HTTP dereferencemechanism defined > > > > > > Can't let go can you? I changed the subject line to start a > different > > > thread. I'd still like the answer to the original thread. > > > > > > There are two separable issues with respect to the ABNF. The > > syntactic > > > and the semantic. > > > > > > The syntactic issues could be dealt with by saying: > > > > > > location-param = LAQUOT loc-URI RAQUOT *( SEMI loc-param ) > > > ;cid-url from RFC2392, SIP/SIPS-URI from RFC3261, PRES-URI from > > RFC3859 > > > ;Absolute URI from RFC3261 > > > loc-URI = cid-uri / SIP-URI / SIPS-URI / PRES-URI / AbsoluteURI > > > > > > This answers Henning and Jeroen's objection to strictly limiting the > > > ABNF. > > > The alternative is to just use AbsoluteURI. > > > > > > I guess the question is, what does the text say? I can make the ABNF > > > match what the text says. > > > > > > Does the text say: any URI can appear in the location header, > entities > > > must use some undefined mechanism to maintain interoperability. > > > > > > Does it say: location dereferencing is a "using protocol" as defined > > in > > > geopriv requirements. Any URI found in the location header MUST > meet > > > the requirements of a using protocol. > > > > > > Does it say: This document describes the use of SIP and SIPS as a > > > dereferencing protocol (and the use of a pres: uri if the resolution > > of > > > the pres: scheme in the referenced domain is to a presence service > > using > > > the sip/sips protocol). All entities using the Location header MUST > > > support SIP dereferencing. > > > > > > Does it say (if the paragraph immediately above is there): Other > > > protocols used for dereferencing MUST have a (?standards track?) RFC > > > defining how to dereference. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:[email protected]] > > > > Sent: Monday, July 31, 2006 6:19 PM > > > > To: Rosen, Brian; IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > 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. > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Rosen, Brian [mailto:[email protected]] > > > > Sent: Mon 31/07/2006 5:05 PM > > > > To: Winterbottom, James; IETF SIP List > > > > Cc: GEOPRIV > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > dereferencemechanism defined > > > > > > > > > > > > > > > > Please don't change the subject, I understand the controversy on > > > > constraining the ABNF. I tried (apparently without success) to > > > separate > > > > those issues. > > > > > > > > I'm asking if anyone objects to NOT mentioning HTTP in any way > with > > > > respect to dereferencing URIs carried by the Location header. > That > > is > > > > the only question I asked. > > > > > > > > I'm not trying to evade the constrained ABNF issue, and I'm not > > > implying > > > > anything tricky. I simply want to know if it's okay if we leave > > > > anything that deals specifically with HTTP and the Location header > > URI > > > > to another document. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:[email protected]] > > > > > Sent: Monday, July 31, 2006 5:55 PM > > > > > To: Rosen, Brian; IETF SIP List > > > > > Cc: GEOPRIV > > > > > Subject: RE: [Geopriv] Does Location-Conveyance have an HTTP > > > > > dereferencemechanism defined > > > > > > > > > > Brian, > > > > > > > > > > Your second paragraph re-opens the sore I am afraid. > > > > > A large number of people have agreed with Henning's statements > and > > > > these > > > > > are clear: > > > > > 1) Do not constrain the ABNF > > > > > 2) Provide minimal description of the reference function. > > > > > > > > > > If you insist on saying then that the ABNF will be restricted if > > > there > > > > is > > > > > not matching text, then I think it unlikely that you will reach > a > > > > > consensus. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > ________________________________ > > > > > > > > > > From: Rosen, Brian [mailto:[email protected]] > > > > > Sent: Mon 31/07/2006 8:38 AM > > > > > To: IETF SIP List > > > > > Cc: GEOPRIV > > > > > Subject: [Geopriv] Does Location-Conveyance have an HTTP > > > > > dereferencemechanism defined > > > > > > > > > > > > > > > > > > > > I have lost track of where we stand on whether the only > mentioned > > > URI > > > > > schemes in location-conveyance are sip/sips/pres. I "think" we > > have > > > > > agreed that an HTTP/HTTPS dereference is in a separate document, > > but > > > > I'm > > > > > not sure. > > > > > > > > > > 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). > > > > > > > > > > If you think location-conveyance DOES have HTTP dereference text > > in > > > > it, > > > > > please say so, and please explain why you would not be satisfied > > if > > > > > there were a separate draft on the subject. > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > [email protected] > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > 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] > > > > > > _______________________________________________ > > > Geopriv mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > 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] > > > > -------------------------------------------------------------------------- > ---------------------- > 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] > > _______________________________________________ > 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