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:[email protected]]
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
>> 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



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