Subject: RE: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 12 Mar 2006 17:27:31 -0600

Good comment.

A generic URI should be sufficient for "Location" (see RFC 2392).  In which case, the line that you propose:

  locationURI =  SIP-URI / SIPS-URI / absoluteURI / cidURI

...can be reduced to:

  locationURI =  absoluteURI ; c.f. RFC 4986

...by virtue of SIP-URI, SIPS-URI and cidURI being subsets of absoluteURI.

The requirement for "Proxy-Required-Body" is different.  In this case only content-ID is permitted (or useful).  The form suggested is almost consistent with parameters in RFC 2387:

   Content-Type: Multipart/Related; boundary=example-2;
             start="<[email-masked]>"
             type="Text/x-Okie"

   Proxy-Required-Body: ss1.atlanta.example.com;
                        cid=[email-masked]

Personally, I would prefer a cid: URI for this parameter as well. 

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Monday, 13 March 2006 10:00 AM
> To: Cullen Jennings; Dean Willis; [email-masked]
> Cc: Allison Mankin
> Subject: Re: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt
> 
> A remark on consistency across drafts: Both
> http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-
> 02.txt
> and http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt are
> using content-id to refer to a body contained in the same request.
> However,
> their ABNF is very different:
> 
> Proxy-Required-Body   = "Proxy-Required-Body" HCOLON required-proxy
>                            SEMI target-body
>    required-proxy        = host
>    target-body           = cid-param *(COMMA cid-param)
>    cid-param             = "cid" EQUAL content-id
>    content-id            = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
>    dot-atom              = atom *( "." atom )
>    atom                  = 1*( alphanum / "-" / "!" / "%" / "*" /
>                            "_" / "+" / "'" / "`" / "~"   )versus
> 
> Location           =  "Location" HCOLON Location-value *(COMMA
>                          Location-value)
>    location-value     =  (addr-spec / option-tag / token)
>    addr-spec          =  cid-url / absoluteURI
>    option-tag         =  string
>    token              =  token / quoted-string
>    cid-url            =  "cid" ":" content-id /
>    absoluteURI        =  SIP or SIPS-URI
>    content-id         =  url-addr-spec
>    url-addr-spec      =  addr-spec ; URL encoding of RFC 822 addr-spec(I
> sent a private comment to the authors proposing to change the latter into
> Location           =  "Location" HCOLON ( status-token / (locationURI
> *(COMMA locationURI)))status-token       =  "Unknown" / tokenlocationURI
> =  SIP-URI / SIPS-URI / absoluteURI / cidURIcidURI             =  "cid:"
> content-idcontent-id         =  addr-spec ; URL encoding of RFC3261
> addr-spec)In any case, these things look very similar - should we agree on
> a
> common syntax at least for the content-id part?
> 
> Regards,
> 
> Jeroen
> 
> 
> > On 3/9/06 1:32 PM, "Dean Willis" <[email-masked]> wrote:
> >
> >>
> >> On Dec 16, 2005, at 1:36 PM, Dean Willis wrote:
> >>
> >>>
> >>> Just so you folks don't think they're nothing to keep you busy over
> >>> the holidays, I'd like to start working group last call of the End
> >>> to Middle draft:
> >>>
> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt
> >>>
> >>> I'd also like to request additional-cross area review from the
> >>> Security area on this document.
> >>>
> >>> Given the cross-area review, I'd like to conclude the WGLC by
> >>> January 20, 2006.
> >>>
> >>
> >>
> >> Okay, kids. I haven't seen a single response to this WGLC, and Kumiko
> >> tells me she hasn't either. This means one of several things:
> >>
> >> 1) You ate so much over the holidays that you forgot all about it.
> >>
> >> 2) The draft is perfect and ready to send to the IETF.
> >>
> >> 3) We just haven't thought about it enough to have an opinion.
> >>
> >> 4) We're waiting on the security review before we form our own
> >> opinion because security is complicated and scary and the
> >> practitioners have interesting hair.
> >>
> >> 5) You replied, but a GRUU ate your email.
> >>
> >> So which is it?
> >>
> >> --
> >
> > Uh, for me 1,3, and 4.
> >
> > Perhaps at this meeting we could ask for a group of people to provide
> > careful review.
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] 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 [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

------------------------------------------------------------------------------------------------
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip