Re: [stir] WGLC: draft-ietf-stir-messaging-02

[Christer Holmberg <[e-mail]>]

Hi Jon,

Please see inline.

---
    
Q1:
    
>>    General:
>>    
>>    Some times the document talks about "telephone calls", and sometimes about "SIP calls". 
>>    
>>    RFC 8224 is about SIP, and the messaging mechanisms mentioned in the draft are SIP-based, so why do we need to talk about something else?
>
> STIR is not SIP-specific, as all of the discussion about out-of-band has demonstrated. STIR has potential applicability to non-SIP messaging as well as SIP messaging. 
> That much said, since STIR implementation has historically been built on top of SIP, that's a focus here - just not an exclusive focus.
    
I think the document would be easier to read, and implement, if it was exclusively focused on SIP. 

Then, IF someone wants to define usage for a non-SIP mechanism, that can be done in a separate draft. After all, you would probably anyway need further specifications if you wanted to standardize for a non-SIP mechanism.

---
    
Q2:
    
>>    Section 3 says:
>>    
>>    "first, a PASSporT could be used to securely negotiate a session over which messages will be exchanged;"
>>    
>>    How do you use a PASSporT to securely negotiate a session? 
>>    
>>    I assume that what you want to say is that, for session-based messaging, a PASSporT can be used to attest the identity of the caller.
>
> As SIPBRANDY (RFC 862) demonstrates, and the existence of "mky" in RFC8225 long foretold, a PASSporT can be used for purposes beyond attesting the identity of the caller, and as a
> bootstrap for exchanging secure media keys during session negotiation. I don't feel this language mischaracterizes that.

Then I suggest that you add a reference to RFC 8862, because as far as I remember there is no text about securing a session in "core" STIR.

---
    
Q3:
    
>>    Section 3.1 says:
>>    
>>    "For the first case, where SIP negotiates a session where the media will be text messages,"
>>    
>>    What is "text message" in the context of SIP? I don't consider MSRP a "text message".
>>    
>>    I assume that you want to talk about cases where a SIP session is established, and within that session media is then sent in some form of messages.
>
> I'm not sure I see a very meaningful distinction here, but I do agree that MSRP (as RFC4975) defines "a 'message' as a complete unit of MIIME or text content", so we should tweak the text here to be clearer about that.
   
I suggest saying something like "where SIP negotiates a session to exchange text-based media".

I did see that version -03 now says "text messages or MIME content" which I think is even more confusing, as a text message can be MIME content :)
 
 ---
    
Q4:
    
>>    I suggest to scope section 3.1 to MSRP, section 3.2 to SIP MESSAGE, and say that other SIP-based messaging mechanisms are outside the scope of the document. 
>>    
>>    Because, most of the text is about MSRP and SIP MESSAGE, and trying to make the sections generic only makes the text more confusing, in my opinion.
>>    
>>    Yes, section 3.2.1 talks about some other mechanisms, but we do we need to cover those in a SIP-based framework? 
>    
> STIR is not a SIP-exclusive framework. 

Correct, but again: that does not prevent us from producing specs that focus on SIP.

Then, again: if you want to do STIR for non-SIP and/or non-MSRP/MESSAGE, you will STILL have to specify more detailed text for those mechanisms for doing that. The "generic" text in the current specs won't take you very far :)

---
    
Q5:
    
>> Section 3.2 says:
>>    
>>    ""msgi" MUST NOT appear in PASSporTs with a type other than "msg","
>>    
>>    I don't think we should use "MUST NOT appear in" language. There is no way to enforce that.
>
> I kind of don’t know how to respond to that, except to say that normative statements in the IETF describe the conditions under which interoperability between implementations can be tested, and indeed, a protocol conformance
> test could determine an implementation is non-compliant if it generated a non-"msg" PASSporT with "msgi" in it.

We should define what information sending entities MUST/MUST NOT insert in a message, and what information in a message receivers need to process. Other information can by default be discarded.

If we want to say "MUST NOT appear" then we should also say what problems it will cause.

 ---
    
Q6:
    
>> Section 3.2 says:
>>    
>>    "A "msgi" message digest is computed over the entire MIME body of a
>>     SIP message, which per [RFC3428] may any sort of MIME body, including
>>     a multipart body in some cases"
>>    
>    In case of a multipart body, does "entire MIME body" include the delimiters etc?
>
> Yes.
>>    
>>    What does "in some cases" mean? Isn't the digest always computed over the entire MIME body?
>
> Well, the sentence there does need some repair: it should be "per [RFC3428] may be any sort of MIME body". But with that fix, what it means that in some
> cases a MIME body can be multipart. The final clause of that sentence modifies the object of the previous clause.
   
Ok, I noted that you have clarified that in version -03, and it looks fine.
 
---
    
Q7:
    
>>    Section 3.2 defines a new PASSporT type and a new claim, but that is not mentioned in the Abstract or Introduction. The A&I only talks about "considering" and "exploring" the usage of STIR for messaging.
>
> I can add that to the Intro, sure.
   
Thanks!

---
    
Q8:
    
>>    Section 4 says:
>>    
>>    "As the "orig" and "dest" field of PASSporTs may contain URIs
>>    containing SIP URIs without telephone numbers, the STIR for messaging
>>    mechanism contained in this specification is not inherently
>>    restricted to the use of telephone numbers.  This specification
>>    offers no guidance on certification authorities who are appropriate
>>    to sign for non-telephone number "orig" values."
>>    
>>    How is this specific to messaging?
>
> This text is just stating that this (often overlooked) general point in RFC8224 applies here to messaging as well. 

Ok.

---

Regards,

Christer

    _______________________________________________
    stir mailing list
    [e-mail]